Update version to 3.1

spec/src/main/asciidoc/ServerPages.adoc

@@ -7,7 +7,7 @@
 :jsp-chapter: 0
 
 :sectnums!:
-== Jakarta Server Pages Specification, Version 3.0
+== Jakarta Server Pages Specification, Version 3.1
 
 Copyright (c) 2013, 2020 Oracle and/or its affiliates and others.
 All rights reserved.
@@ -24,13 +24,13 @@ Comments to: jsp-dev@eclipse.org
 === Preface
 
 This is the Jakarta Server Pages specification
-version 3.0, developed by the Jakarta Server Pages Team under the Eclipse
+version 3.1, developed by the Jakarta Server Pages Team under the Eclipse
 Foundation Specification Process. References in this document to JSP refer
 to Jakarta Server Pages unless otherwise noted.
 
 ==== Who Should Read This Document
 
-This document is the authoritative JSP 3.0
+This document is the authoritative JSP 3.1
 specification. It is intended to provide requirements for
 implementations of JSP page processing, and support by web containers in
 web servers and application servers. As an authoritative document, it
@@ -321,7 +321,7 @@ this class of user:
 * Appendices <<Packaging JSP Pages>>, <<Changes>>, and <<Glossary>>
 
 Advanced page authors may also wish to look at the Javadoc for the
-`jakarta.servlet.jsp` package and the XML schema for the JSP 3.0
+`jakarta.servlet.jsp` package and the XML schema for the JSP 3.1
 deployment descriptor.
 
 ===== Tag Library Developers
@@ -401,7 +401,7 @@ The chapters of this part are:
 == Core Syntax and Semantics{counter2:jsp-chapter}
 
 This chapter describes the core syntax
-and semantics for the Jakarta Server Pages 3.0 specification (JSP 3.0).
+and semantics for the Jakarta Server Pages 3.1 specification (JSP 3.1).
 
 === What Is a JSP Page
 
@@ -622,7 +622,7 @@ time.
 ===== JSP Page Packaging
 
 When a JSP page implementation class depends
-on support classes in addition to the JSP 3.0 and Servlet 5.0 classes,
+on support classes in addition to the JSP 3.1 and Servlet 5.0 classes,
 the support classes are included in the packaged WAR, as defined in the
 Servlet 5.0 specification, for portability across JSP containers.
 
@@ -642,7 +642,7 @@ implementation class for that page.
 In the past debugging tools provided by
 development environments have lacked a standard format for conveying
 source map information allowing the debugger of one vendor to be used
-with the JSP container of another. JSP 3.0 containers must
+with the JSP container of another. JSP 3.1 containers must
 support the Jakarta Debugging Support for Other Languages Specification.
 Details can be found in <<Debugging Requirements>>.
 
@@ -674,7 +674,7 @@ servlets, and other resources used in the web application. The
 deployment descriptor is described in detail in the Servlet 5.0
 specification.
 
-JSP 3.0 requires that these resources be
+JSP 3.1 requires that these resources be
 implicitly associated with and accessible through a unique
 `ServletContext` instance available as the implicit `application` object
 (see <<Objects>>).
@@ -688,7 +688,7 @@ semantics of the following elements:
 * The `jsp:include` action element (see <<jsp:include>>).
 * The `jsp:forward` action (see<<jsp:forward>>).
 
-JSP 3.0 supports portable packaging and
+JSP 3.1 supports portable packaging and
 deployment of web applications through the Servlet 5.0 specification.
 The Jakarta Server Pages specification inherits from the servlet
 specification the concepts of applications, `ServletContexts`,
@@ -2099,7 +2099,7 @@ written to it will be passed directly through to the `ServletResponse`
 output stream.
 
 A JSP page can also describe what should
-happen when some specific events occur. In JSP 3.0, the only events that
+happen when some specific events occur. In JSP 3.1, the only events that
 can be described are the initialization and the destruction of the page.
 These events are described using “well-known method names” in
 declaration elements. (See <<JSP Container>>).
@@ -2436,7 +2436,7 @@ The details of the attributes are as follows:
 the scriptlets, expression scriptlets, and declarations within the body
 of the translation unit (the JSP page and any files included using the
 `include` directive below). +
-In JSP 3.0, the only defined and required
+In JSP 3.1, the only defined and required
 scripting language value for this attribute is `java` (all lowercase,
 case-sensitive). +
 This specification only describes the
@@ -2774,7 +2774,7 @@ for mixed syntax includes are described in
 
 A JSP container can include a mechanism for
 being notified if an included file changes, so the container can
-recompile the JSP page. However, the JSP 3.0 specification does not have
+recompile the JSP page. However, the JSP 3.1 specification does not have
 a way of directing the JSP container that included files have changed.
 
 The `<jsp:directive.include>` element (<<The jsp:directive.include Element>>)
@@ -2811,13 +2811,13 @@ The semantics for mixed syntax includes are described in
 ==== Including Data in JSP Pages
 
 Including data is a significant part of the
-tasks in a JSP page. Accordingly, the JSP 3.0 specification has two
+tasks in a JSP page. Accordingly, the JSP 3.1 specification has two
 include mechanisms suited to different tasks. A summary of their
-semantics is shown in <<_Summary_of_Include_Mechanisms_in_JSP_3.0>>.
+semantics is shown in <<_Summary_of_Include_Mechanisms_in_JSP_3.1>>.
 
 [caption='*Table JSP.{jsp-chapter}-{counter:table-number}* ']
-[[_Summary_of_Include_Mechanisms_in_JSP_3.0]]
-.Summary of Include Mechanisms in JSP 3.0
+[[_Summary_of_Include_Mechanisms_in_JSP_3.1]]
+.Summary of Include Mechanisms in JSP 3.1
 [cols="28,15,12,25,20",options="header"]
 |===
 
@@ -2937,7 +2937,7 @@ element in the web.xml deployment descriptor (see
 There are three other classes of scripting
 elements: declarations, scriptlets and expressions. The scripting
 language used in the current page is given by the value of the
-`language` directive (see <<The `page` Directive>>). In JSP 3.0, the only
+`language` directive (see <<The `page` Directive>>). In JSP 3.1, the only
 value defined is `java`.
 
 Declarations are used to declare scripting
@@ -3137,7 +3137,7 @@ may be applicable; the rules for them are described in
 <<Type Conversions>>.
 
 Many values are fixed translation-time
-values, but JSP 3.0 also provides a mechanism for describing values that
+values, but JSP 3.1 also provides a mechanism for describing values that
 are computed at request time, the rules are described in
 <<Request Time Attribute Values>>.
 
@@ -3302,8 +3302,8 @@ document must be followed.
 :table-number: 0
 == Expression Language{counter2:jsp-chapter}
 
-Please consult the Jakarta Expression Language 4.0 specification document
-for details on the Expression Language supported by JSP 3.0.
+Please consult the Jakarta Expression Language 5.0 specification document
+for details on the Expression Language supported by JSP 3.1.
 
 The addition of the EL to the JSP technology
 facilitates the writing of scriptless JSP pages. These pages can
@@ -3315,7 +3315,7 @@ The EL is available in attribute values for
 standard and custom actions and within template text.
 
 This chapter describes how the expression
-language is integrated within the JSP 3.0 environment.
+language is integrated within the JSP 3.1 environment.
 
 === Syntax of Expressions in JSP Pages: ${} vs #{}
 
@@ -3812,7 +3812,7 @@ This chapter describes the JSP
 configuration information, which is specified in the Web Application
 Deployment Descriptor in `WEB-INF/web.xml`. For Servlet 5.0, the Web
 Application Deployment Descriptor is defined using XML Schema, and
-imports the elements described in the XML Schema for JSP 3.0 Deployment
+imports the elements described in the XML Schema for JSP 3.1 Deployment
 Descriptor. See the XML Schema for the details on how to specify JSP
 configuration information in a Web Application.
 
@@ -4556,7 +4556,7 @@ Combinations of these approaches also make sense.
 == Standard Actions{counter2:jsp-chapter}
 
 This chapter describes the standard
-actions of Jakarta Server Pages 3.0 (JSP 3.0). Standard actions are
+actions of Jakarta Server Pages 3.1 (JSP 3.1). Standard actions are
 represented using XML elements with a prefix of `jsp` (though that
 prefix can be redefined in the XML syntax). A translation error will
 result if the JSP prefix is used for an element that is not a standard
@@ -5032,7 +5032,7 @@ the property is obtained.
 
 A `<jsp:include \.../>` action provides for
 the inclusion of static and dynamic resources in the same context as the
-current page. See <<Summary of Include Mechanisms in JSP 3.0>> for a summary of include facilities.
+current page. See <<Summary of Include Mechanisms in JSP 3.1>> for a summary of include facilities.
 
 Inclusion is into the current value of `out`. The resource is specified
 using a `relativeURLspec` that is
@@ -5800,7 +5800,7 @@ has a special meaning when used in the body of `<jsp:element>`. See
 
 |`name`
 |(required) The value of name is that of the
-element generated. The name can be a QName; JSP 3.0 places no
+element generated. The name can be a QName; JSP 3.1 places no
 constraints on this value: it is accepted as is. A request-time
 attribute value may be used for this attribute.
 
@@ -5883,7 +5883,7 @@ The `jsp:output` action can only be used in
 JSP documents and in tag files in XML syntax, and a translation error
 must result if used in a standard syntax JSP or tag file. This action is
 used to modify some properties of the output of a JSP document or a tag
-file. In JSP 3.0 there are four properties that can be specified, all of
+file. In JSP 3.1 there are four properties that can be specified, all of
 which affect the output of the XML prolog.
 
 The `omit-xml-declaration` property allows
@@ -6161,7 +6161,7 @@ The _XML view of a JSP page_ is an XML
 document that is derived from the JSP page following a mapping defined
 later in this chapter. The XML view of a JSP page is intended to be used
 for validating the JSP page against some description of the set of valid
-pages. Validation of the JSP page is supported in the JSP 3.0
+pages. Validation of the JSP page is supported in the JSP 3.1
 specification through a `TagLibraryValidator` class associated with a
 tag library. The validator class acts on a PageData object that
 represents the XML view of the JSP page (see, for example,
@@ -6218,12 +6218,12 @@ See <<Tag Files in XML Syntax>> for details on identifying tag files in XML synt
 
 A JSP document may or not have a `<jsp:root>`
 as its top element; `<jsp:root>` was mandatory in JSP 1.2, but we expect
-most JSP documents in JSP 3.0 not to use it.
+most JSP documents in JSP 3.1 not to use it.
 
 JSP documents identify standard actions
 through the use of a well-defined URI in its namespace; although in this
 chapter the prefix `jsp` is used for the standard actions, any prefix is
-valid as long as the correct URI identifying JSP 3.0 standard actions is
+valid as long as the correct URI identifying JSP 3.1 standard actions is
 used. Custom actions are identified using the URI that identifies their
 tag library; `taglib` directives are not required and cannot appear in a
 JSP document.
@@ -6338,7 +6338,7 @@ must be validated by the container in the translation phase. Validation
 errors must be handled the same way as any other translation phase
 errors, as described in <<Translation Time Processing Errors>>.
 
-JSP 3.0 requires only DTD validation for JSP
+JSP 3.1 requires only DTD validation for JSP
 Documents; containers should not perform validation based on other types
 of schemas, such as XML schema.
 
@@ -6471,7 +6471,7 @@ jsp:root is the version of the JSP specification used:
 
 |`version`
 |(required) The version of the JSP specification used in this page.
-Valid values are "1.2", "2.0", "2.1", "2.2", "2.3" and "3.0".
+Valid values are "1.2", "2.0", "2.1", "2.2", "2.3", "3.0" and "3.1".
 It is a translation error if the container does not support the specified version.
 
 |===
@@ -6727,7 +6727,7 @@ custom action, then the elements so effected would be interpreted as
 invocations on custom actions or tags.
 
 Although the JSP container understands that
-this document is a namespace-aware document, the JSP 3.0 container does
+this document is a namespace-aware document, the JSP 3.1 container does
 not really understand that the generated content is a well-formed XML
 document and, as the next example shows, a JSP document can generate
 other types of content.
@@ -6867,7 +6867,7 @@ versions of the JSP specification.
 
 ==== Generating XML Content Natively
 
-All JSP 3.0 content is textual, even when
+All JSP 3.1 content is textual, even when
 using JSP documents to generate XML content. This is quite acceptable,
 and even ideal, for some applications, but in some other applications
 XML documents are the main data type being manipulated. For example, the
@@ -7954,7 +7954,7 @@ development group may want to constrain the way some features are used.
 
 Validation can be done either at
 translation-time or at request-time. In general translation-time
-validation provides a better user experience, and the JSP 3.0
+validation provides a better user experience, and the JSP 3.1
 specification provides a very flexible translation-time validation
 mechanism.
 
@@ -10104,7 +10104,7 @@ from the JSP page implementation object to the client.
 The JSP page describes how to create a
 response object from a request object for a given protocol, possibly
 creating and/or using some other objects in the process . A JSP page may
-also indicate how some events are to be handled. In JSP 3.0 only `init`
+also indicate how some events are to be handled. In JSP 3.1 only `init`
 and `destroy` events are allowed events.
 
 The JSP container must render a JSP page for the HTTP methods GET and POST
@@ -10145,7 +10145,7 @@ in <<Scripting>>.
 
 The contract also describes how a JSP author
 can indicate what actions will be taken when the `init` and `destroy`
-methods of the page implementation occur. In JSP 3.0 this is done by
+methods of the page implementation occur. In JSP 3.1 this is done by
 defining methods with the names `jspInit` and `jspDestroy` in a
 declaration scripting element in the JSP page. The `jspInit` method, if
 present, will be called to prepare the page before the first request is
@@ -10496,7 +10496,7 @@ can still be used in a scriptlet in a `.jsp` file, by invoking
 === Precompilation
 
 A JSP page that is using the HTTP protocol
-will receive HTTP requests. JSP 3.0 compliant containers must support a
+will receive HTTP requests. JSP 3.1 compliant containers must support a
 simple precompilation protocol, as well as some basic reserved parameter
 names. Note that the precompilation protocol is related but not the same
 as the notion of compiling a JSP page into a `Servlet` class
@@ -10551,7 +10551,7 @@ the JSP Compiler with a standard format to convey source map debugging
 information to tools such as debuggers. See
 `https://jakarta.ee/specifications/debugging/2.0/` for details.
 
-JSP 3.0 containers are required to provide debugging support for JSP pages
+JSP 3.1 containers are required to provide debugging support for JSP pages
 and tag files written in either standard or XML syntax.
 
 The JSP compiler must produce `.class` files
@@ -10697,13 +10697,13 @@ This appendix shows two simple examples
 of packaging a JSP page into a WAR for delivery into a Web container. In
 the first example, the JSP page is delivered in source form. This is
 likely to be the most common example. In the second example the JSP page
-is compiled into a servlet that uses only Servlet 5.0 and JSP 3.0 API
+is compiled into a servlet that uses only Servlet 5.0 and JSP 3.1 API
 calls; the servlet is then packaged into a WAR with a deployment
 descriptor such that it looks as the original JSP page to any client.
 
 This appendix is non normative. Actually,
 strictly speaking, the appendix relates more to the Servlet 5.0
-capabilities than to the JSP 3.0 capabilities. The appendix is included
+capabilities than to the JSP 3.1 capabilities. The appendix is included
 here as this is a feature that JSP page authors and JSP page authoring
 tools are interested in.
 
@@ -10740,7 +10740,7 @@ compile the JSP page into a servlet class to run in a JSP container.
 
 The JSP page is compiled into a servlet with
 some implementation dependent name `com.acme._jsp_HelloWorld_XXX_Impl`.
-The servlet code only depends on the JSP 3.0 and Servlet 5.0 APIs, as
+The servlet code only depends on the JSP 3.1 and Servlet 5.0 APIs, as
 follows:
 
 ....
@@ -11002,6 +11002,10 @@ described in appendix F.1 of the XML 1.0 specification.
 This appendix lists the changes in the
 Jakarta Server Pages specification. This appendix is non-normative.
 
+=== Changes between JSP 3.1 and JSP 3.0
+
+
+
 === Changes between JSP 3.0 and JSR 245
 
 * The API has moved from the `javax.servlet.jsp` package to the