View Old View New View Both View Only Previous Next

This draft contains only sections that have differences from the version that it modified.

W3C

XSLT and XQuery Serialization 4.0

W3C Editor's Draft 218 February 2026

This version:
https://www.w3.org/TR/2000/REC-xslt-xquery-serialization-40-20000101/
Latest version of XSLT and XQuery Serialization 4.0:
https://www.w3.org/TR/xslt-xquery-serialization-40/
Most recent version of XSLT and XQuery Serialization 4:
https://www.w3.org/TR/xslt-xquery-serialization-4/
Most recent version of XSLT and XQuery Serialization:
https://www.w3.org/TR/xslt-xquery-serialization/
Most recent Recommendation of XSLT and XQuery Serialization:
https://www.w3.org/TR/xslt-xquery-serialization-31/
Editors:
Andrew Coleman, IBM Hursley Laboratories <andrew_coleman@uk.ibm.com>
C. M. Sperberg-McQueen, Black Mesa Technologies <http://blackmesatech.com/>

Please check the errata for any errors or issues reported since publication.

See also translations.

This document is also available in these non-normative formats: XML.


Abstract

This document defines serialization of an instance of the data model as defined in [XQuery and XPath Data Model (XDM) 4.0] into a sequence of octets. Serialization is designed to be a component that can be used by other specifications such as [XSL Transformations (XSLT) Version 4.0] or [XQuery 4.0: An XML Query Language].

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document is governed by the 1 March 2017 W3C Process Document.

This is a Recommendation of the W3C. It was jointly developed by the W3C XSLT Working Group and the W3C XML Query Working Group, each of which is part of the XML Activity.

This Editor's Draft specifies XSLT and XQuery Serialization version 4.0, a fully compatible extension of Serialization version 3.1.

This specification is designed to be referenced normatively from other specifications defining a host language for it; it is not intended to be implemented outside a host language. The implementability of this specification has been tested in the context of its normative inclusion in host languages defined by the XQuery 3.1 and XSLT 3.0 specifications; see the XQuery 3.1 implementation report (and, in the future, the WGs expect that there will also be an XSLT 3.0 implementation report) for details.

No substantive changes have been made to this specification since its publication as a Proposed Recommendation.

Please report errors in this document using W3C's public Bugzilla system (instructions can be found at https://www.w3.org/XML/2005/04/qt-bugzilla). If access to that system is not feasible, you may send your comments to the W3C XSLT/XPath/XQuery public comments mailing list, public-qt-comments@w3.org. It will be very helpful if you include the string “[SER40]” in the subject line of your report, whether made in Bugzilla or in email. Please use multiple Bugzilla entries (or, if necessary, multiple email messages) if you have more than one comment to make. Archives of the comments and responses are available at https://lists.w3.org/Archives/Public/public-qt-comments/.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

This document was produced by groups operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures (W3C XML Query Working Group) and a public list of any patent disclosures (W3C XSLT Working Group) made in connection with the deliverables of each group; these pages also include instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Dedication

The publications of this community group are dedicated to our co-chair, Michael Sperberg-McQueen (1954–2024).


1 Introduction

Changes in 4.0 

  1. Use the arrows to browse significant changes since the 3.1 version of this specification.

  2. Sections with significant changes are marked Δ in the table of contents.

This document defines serialization of the W3C XQuery and XPath Data Model 4.0 (XDM), which is the data model of at least [XML Path Language (XPath) 4.0], [XSL Transformations (XSLT) Version 4.0], and [XQuery 4.0: An XML Query Language], and any other specifications that reference it.

In this document, examples and material labeled as “Note” are provided for explanatory purposes and are not normative.

Serialization is the process of converting an instance of the [XQuery and XPath Data Model (XDM) 4.0] into a sequence of octets.

[Definition: The XDM value supplied as input to the serializer is referred to as the input value.] Some serialization methods apply only to certain types of input value.

Note:

Where serialization is used to process the result of an XQuery evaluation or an XSLT transformation, the input value of the serializer corresponds to the output from XQuery or XSLT.

[Definition: In general the output of the serializer will represent the items actually present in the input value, together with other items that are reachable from these, for example (in the case of nodes) their descendants. The complete set of items that are represented in the output of the serializer is referred to (without loss of generality) as the input tree.]

1.1 Terminology

Changes in 4.0  

  1. The term atomic value has been replaced by atomic item.   [Issue 1337  2 August 2024]

In this specification, where they are rendered in small capitals, the words must, must not, should, should not, may, required, and recommended are to be interpreted as described in [RFC2119].

[Definition: As is indicated in 12 Conformance, conformance criteria for serialization are determined by other specifications that refer to this specification. A serializer is software that implements some or all of the requirements of this specification in accordance with such conformance criteria.] A serializer is not required to directly provide a programming interface that permits a user to set serialization parameters or to provide an input sequence for serialization. In this document, material labeled as "Note" and examples are provided for explanatory purposes and are not normative.

Certain aspects of serialization are described in this specification as implementation-defined or implementation-dependent.

[Definition: Implementation-defined indicates an aspect that may differ between serializers, but whose actual behavior must be specified either by another specification that sets conformance criteria for serialization (see 12 Conformance) or in documentation that accompanies the serializer.]

[Definition: Implementation-dependent indicates an aspect that may differ between serializers, and whose actual behavior is not required to be specified either by another specification that sets conformance criteria for serialization (see 12 Conformance) or in documentation that accompanies the serializer.]

[Definition: In some instances, the input tree cannot be successfully converted into a sequence of octets given the set of serialization parameter (3 Serialization Parameters) values specified. A serialization error is said to occur in such an instance.] In some cases, a serializer is required to raise such an error. What it means to raise a serialization error is determined by the relevant conformance criteria (12 Conformance) to which the serializer conforms. In other cases, there is an implementation-defined choice between raising a serialization error and performing a recovery action. Such a recovery action will allow a serializer to produce a sequence of octets that might not fully reflect the usual requirements of the parameter settings that are in effect.

[Definition: Where this specification indicates that two strings are to be compared without regard to case, the serializermust translate any characters in the range U+0041 (LATIN CAPITAL LETTER A, A) through U+005A (LATIN CAPITAL LETTER Z, Z) inclusive, to the corresponding lower-case letters in the range U+0061 (LATIN SMALL LETTER A, a) through U+007A (LATIN SMALL LETTER Z, z) only for the purposes of making the comparison. The comparison succeeds if the two strings are the same length and the code point of each character in the first string is equal to the code point of the character in the corresponding position in the second string.]

Many terms used in this document are defined in the XPath specification [XML Path Language (XPath) 4.0] or the Data Model specification [XQuery and XPath Data Model (XDM) 4.0]. Particular attention is drawn to the following:

Where this specification indicates that an XSLT instruction is evaluated, the behavior is as specified by [XSL Transformations (XSLT) Version 4.0]. Where it indicates that an XQuery expression is evaluated, the behavior is as specified by [XQuery 4.0: An XML Query Language].

2 Sequence Normalization

The input value is a sequence. Prior to serializing a sequence using any of the output methods whose behavior is specified by this document (3 Serialization Parameters), with the exception of the JSON and Adaptive output methods, the serializermust first compute a normalized sequence for serialization; it is the normalized sequence that is actually serialized. [Definition: The purpose of sequence normalization is to create a sequence that can be serialized as a well-formed XML document or external general parsed entity, that also reflects the content of the input sequence to the extent possible.] [Definition: The result of the sequence normalization process is a result tree.]

The normalized sequence for serialization is constructed by applying all of the following rules in order, with the input value being input to the first step, and the sequence that results from any step being used as input to the subsequent step. For any implementation-defined output method, it is implementation-defined whether this sequence normalization process takes place. For the JSON and Adaptive output methods, sequence normalization must not take place.

Where the process of converting the input sequence to a normalized sequence indicates that a value must be cast to xs:string, that operation is defined in Section 22.1.223.1.2 Casting to xs:stringFO of [XQuery and XPath Functions and Operators 4.0]. Where a step in the sequence normalization process indicates that a node should be copied, the copy is performed in the same way as an XSLT xsl:copy-of instruction that has a validation attribute whose value is preserve and has a select attribute whose effective value is the node, as described in Section 11.9.2 Deep CopyXT of [XSL Transformations (XSLT) Version 4.0], or equivalently in the same way as an XQuery content expression as described in Step 1e of Section 4.12.1.3 ContentXQ of [XQuery 4.0: An XML Query Language], where the construction mode is preserve. Let S0 be the sequence that is input to serialization. The steps in computing the normalized sequence are:

  1. Create a new sequence S1 from S0 as follows. For each item in S0, if the item is a JNode, copy the ¶value property of the item; otherwise, copy the item itself.

  2. Create a new sequence S12 from S01 as follows. For each item in S01, if the item is an array, copy the results of passing the item into the function array:flatten(); otherwise, copy the item itself. If S01 is empty, let S12 consist of a zero-length string.

  3. Create a new sequence S23 from S12 as follows. For each item in S13, if the item is atomic, copy to S23 only the lexical representation resulting from casting the item to an xs:string, otherwise, copy the item to S23.

  4. Create a new sequence S34 from S23 as follows. If the item-separator serialization parameter is present, then copy each item in S23 to S34, inserting between each pair of items a string whose value is equal to the value of the item-separator parameter. If the item-separator serialization parameter is not present, then first maximally group the items in S23 into subsequences of xs:string items and non-xs:string items. For each group of items, if the group is a subsequence of non-xs:string items, copy the subsequence to S34; if the group is a subsequence of xs:string items, copy to S34 the results of passing to fn:string-join() the subsequence and the value of item-separator as the function’s two parameters.

  5. Create a new sequence S45 from S34 as follows. For each item in S34, if the item is a string, copy to S45 a text node whose string value is equal to the string; otherwise, copy the item to S45.

  6. Create a new sequence S56 from S45 as follows. For each item in S45, if the item is a document node, copy its children to S56; otherwise, copy the item to S56.

  7. Create a new sequence S67 from S56 as follows. First, remove any text nodes with values of zero length from S56, then maximally group the results into groups of text nodes and non-text nodes. For each group of items, if the group is a subsequence of text nodes, copy to S67 a single text node whose value is equal to the concatenated values of the subsequence; if the group is a subsequence of non-text nodes, copy the subsequence of items to S67. It is a serialization error [err:SENR0001] if any item in S67 is an attribute node, a namespace node, or a function.

  8. Create a new sequence S78 from S67 as follows. Let S78 be a single document node. Copy sequence S67 to the document node as its children.

S78 is the normalized sequence.

The result tree rooted at the document node that is created by the final step of this sequence normalization process is the value to which the rules of the appropriate output method are applied. If the sequence normalization process results in a serialization error, the serializermust raise the error.

Note:

If the item-separator serialization parameter is absent, the sequence normalization process for a sequence $seq is equivalent to constructing a document node using the XSLT instruction:

<xsl:document>
  <xsl:copy-of select="$seq" validation="preserve"/>
</xsl:document>

or the XQuery expression:

declare construction preserve;

document { $seq }

If the item-separator serialization parameter is present, the sequence normalization process for a sequence $seq is equivalent to constructing a document node using the XSLT instruction:

<xsl:document>
  <xsl:for-each select="$seq">
    <xsl:sequence select="if (position() gt 1) 
                          then $sep 
                          else ()"/>

    <xsl:choose>
      <xsl:when test=". instance of node()">
        <xsl:sequence select="."/>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="."/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:for-each>
</xsl:document>

or the XQuery expression:

declare construction preserve; 

document {
  for $item at $pos in $seq
  let $node := 
    if ($item instance of node()) then 
      $item 
    else 
      text { $item }
  return
    if ($pos eq 1) then
      $node
    else
      ($sep, $node)  
}

where the value of the sep variable is a string whose value is equal to the value of the item-separator serialization parameter.

This process results in a serialization error [err:SENR0001] if $seq contains functions, attribute nodes or namespace nodes.

5 XML Output Method

The XML output method serializes the normalized sequence as an XML entity that must satisfy the rules for either a well-formed XML document entity, a well-formed XML external general parsed entity, or both. A serialization error [err:SERE0003] results if the serializer is unable to satisfy those rules, except for content modified by the character expansion phase of serialization, as described in 4 Phases of Serialization. The effects of the character expansion phase could result in the serialized output being not well-formed, but will not result in a serialization error. If a serialization error results, the serializermust raise the error.

If the document node of the normalized sequence has a single element node child and no text node children, then the serialized output is a well-formed XML document entity, and the serialized output must conform to the appropriate version of the XML Namespaces Recommendation [XML Names] or [XML Names 1.1]. If the normalized sequence does not take this form, then the serialized output is a well-formed XML external general parsed entity, which, when referenced within a trivial XML document wrapper like this:

<?xml version="version"?>
<!DOCTYPE doc [
<!ENTITY e SYSTEM "entity-URI">
]>
<doc>&e;</doc>

where entity-URI is a URI for the entity, and the value of the version pseudo-attribute is the value of the version parameter, produces a document which must itself be a well-formed XML document conforming to the corresponding version of the XML Namespaces Recommendation [XML Names] or [XML Names 1.1].

[Definition: A reconstructed tree may be constructed by parsing the XML document and converting it into an document node as specified in [XQuery and XPath Data Model (XDM) 4.0].] The result of serialization must be such that the reconstructed tree is the same as the result tree except for the following permitted differences:

A consequence of this rule is that certain characters must be output as character references, to ensure that they survive the round trip through serialization and parsing. Specifically:

For example, an attribute with the value "x" followed by "y" separated by a newline will result in the output "x&#xA;y" (or with any equivalent character reference). The XML output cannot be "x" followed by a literal newline followed by a "y" because after parsing, the attribute value would be "x y" as a consequence of the XML attribute normalization rules.

Note:

XML 1.0 did not permit an XML processor to normalize U+0085 (NEXT LINE, NEL) or U+2028 (LINE SEPARATOR) characters to a U+000A (NEWLINE) character. However, if a document entity that specifies version 1.1 invokes an external general parsed entity with no text declaration or a text declaration that specifies version 1.0, the external parsed entity is processed according to the rules of XML 1.1. For this reason, U+0085 (NEXT LINE, NEL) and U+2028 (LINE SEPARATOR) characters in text and attribute nodes must always be escaped using character references, regardless of the value of the version parameter.

XML 1.0 permitted control characters in the range U+007F (DELETE) through U+009F (APC) to appear as literal characters in an XML document, but XML 1.1 requires such characters, other than U+0085 (NEXT LINE, NEL) , to be escaped as character references. An external general parsed entity with no text declaration or a text declaration that specifies a version pseudo-attribute with value 1.0 that is invoked by an XML 1.1 document entity must follow the rules of XML 1.1. Therefore, the non-whitespace control characters in the ranges U+0001 (SOH) through U+001F (IS1) and U+007F (DELETE) through U+009F (APC) must always be escaped, regardless of the value of the version parameter.

It is a serialization error [err:SEPM0004] to specify the doctype-system parameter, or to specify the standalone parameter with a value other than omit, if the input tree contains text nodes or multiple element nodes as children of the root node. The serializermust either raise the error, or recover by ignoring the request to output a document type declaration or standalone parameter.

9 JSON Output Method

Changes in 4.0  

  1. Added the escape-solidus parameter for JSON serialization.   [Issue 530 PR 534 6 June 2023]

  2. Added the json-lines parameter for JSON serialization.   [Issue 1471  15 October 2024]

  3. The serialization of maps retains the order of entries.   [Issue 1651 PR 1703 14 January 2025]

  4. A JNode is replaced by its ¶value property.   [Issue 2025 PR 2031 29 May 2025]

The JSON output method serializes the input tree using the JSON syntax defined in [RFC 7159], or (if the json-lines parameter is set to true) the json-lines syntax defined at [JSON Lines]. Sequence normalization is not performed for this output method. The effect of the json-lines parameter is explained at 9.1 JSON Lines.

If json-lines is set to false, then:

An individual item is serialized as follows:

[Definition: Whenever a value is serialized to a JSON string, the following procedure is applied to the supplied string:

  1. Any character in the string for which character mapping is defined (see 11 Character Maps) is substituted by the replacement string defined in the character map.

  2. Any other character in the input string (but not a character produced by character mapping) is a candidate for Unicode Normalization if requested by the normalization-form parameter, and JSON escaping. JSON escaping replaces the characters quotation mark, backspace, form-feed, newline, carriage return, tab, or reverse solidus by the corresponding JSON escape sequences \", \b, \f, \n, \r, \t, or \\ respectively, and any other codepoint in the range 1-31 or 127-159 by an escape in the form \uHHHH where HHHH is the hexadecimal representation of the codepoint value. Escaping further replaces the solidus character (/) by the escape sequence \/ if the escape-solidus parameter is set to true, but not if it is set to false. Escaping is also applied to any characters that cannot be represented in the selected encoding.

  3. The resulting string is enclosed in double quotation marks.

]

Finally, encoding, as controlled by the encoding parameter, converts the character stream produced by the preceding rules into an octet stream.

10 Adaptive Output Method

Changes in 4.0  

  1. The serialization of maps retains the order of entries.   [Issue 1651 PR 1703 14 January 2025]

  2. The output of QNames reflects the new syntax for QName literals.   [Issue 2059 PR TODO 23 June 2025]

  3. A JNode is replaced by its ¶value property.   [Issue 2025 PR 2031 29 May 2025]

The Adaptive output method serializes the input tree into a human readable form for the purposes of debugging query results. The intention of this is to allow any input value to be serialized without raising a serialization error. Sequence normalization is not performed for this output method.

Each item in the supplied sequence is serialized individually as follows, with an occurrence of the chosen item-separator between successive items.

Character maps are applied (a) when nodes are serialized using the XML output method, and (b) to any value represented as a string enclosed in quotation marks.

Optionally, in all the above constructs, characters whose visual representation is ambiguous (for example tab or non-breaking-space) may be represented in the form of an XML numeric character reference (for example &#x9; or &#xa0;)

Note:

In many cases the serialization of an item conforms to the syntax of an XQuery expression whose result is that item. There are exceptions, however. For example, the syntax will not be valid XQuery in the case of free-standing attribute or namespace nodes, or QName values, or anonymous functions; and where it is valid XQuery, the result of evaluating the expression will not necessarily be identical to the original: for example, the distinction between strings and untypedAtomic items is lost.

If any value cannot be output because doing so would cause a serialization error, the behavior is implementation-defined.

If the output is sent to a destination that allows hyperlinks to be included in the generated text, then the serializer may include implementation-dependent hyperlinks to provide additional information for example:

E Glossary (Non-Normative)

array item

The term array item is defined in Section 7.38.3 Array ItemsDM.

atomize

The term atomization is defined in Section 2.5.3 AtomizationXP.

character

The term character is defined in Section 4.1.5 XML and XSD VersionsDM.

codepoint

The term codepoint is defined in Section 4.1.5 XML and XSD VersionsDM.

content

The term content has the same meaning as the term ContentXML defined in Section 3.1 Start-Tags, End-Tags, and Empty-Element TagsXML of [XML10].

EMPTY

The following XHTML elements have an EMPTY content model: area, base, br, col, embed, hr, img, input, link, meta, basefont, frame, isindex, and param.

expanded QName

The term expanded QName is defined in Section 2 BasicsXP. An expanded QName consists of an optional namespace URI and a local name. An expanded QName also retains its original namespace prefix (if any), to facilitate casting the expanded QName into a string.

expected-empty

An element node is expected to be empty if it is recognized as an HTML element and:

function item

The term function item is defined in Section 7.18.1 Function ItemsDM.

host language

A host language is another specification that includes, by reference, this specification and all of its requirements. A host language might be a programming language such as [XSL Transformations (XSLT) Version 4.0] or [XQuery 4.0: An XML Query Language], or it might be an application programming interface (API) intended to be used by programs written in some other high-level programming language. The use of the term language is not intended to preclude the possibility that this specification might be referenced outside the context of a programming language specification.

immediate content

The immediate content of an element is the part of the content of the element that is not also in the content of a child element of that element.

implementation-defined

Implementation-defined indicates an aspect that may differ between serializers, but whose actual behavior must be specified either by another specification that sets conformance criteria for serialization (see 12 Conformance) or in documentation that accompanies the serializer.

implementation-dependent

Implementation-dependent indicates an aspect that may differ between serializers, and whose actual behavior is not required to be specified either by another specification that sets conformance criteria for serialization (see 12 Conformance) or in documentation that accompanies the serializer.

input tree

In general the output of the serializer will represent the items actually present in the input value, together with other items that are reachable from these, for example (in the case of nodes) their descendants. The complete set of items that are represented in the output of the serializer is referred to (without loss of generality) as the input tree.

input value

The XDM value supplied as input to the serializer is referred to as the input value.

map item

The term map item is defined in Section 7.28.2 Map ItemsDM.

MathML namespace

the MathML namespace namespace, https://www.w3.org/1998/Math/MathML.

node

The term node is defined as part of [TITLE OF DM40 SPEC, TITLE OF Node SECTION]DM40. There are seven kinds of nodes in the data model: document, element, attribute, text, namespace, processing instruction, and comment.

non-null namespace URI

An element or attribute that does not have a null namespace URI, is referred to as having a non-null namespace URI

null namespace URI

An expanded-QName whose namespace part is an empty sequence, or an element or attribute whose name expands to such an expanded-QName, is referred to as having a null namespace URI

Output declaration namespace

the Output declaration namespace, https://www.w3.org/2010/xslt-xquery-serialization

parameter document

An output:serialization-parameters element node used to hold the settings of serialization parameters is referred to as a parameter document

prefix normalization

During prefix normalization, any element node in the input tree that is in one of the XHTML namespace, the SVG namespace or the MathML namespace has its name replaced by the local part of its name. Such an element node is given a default namespace node whose value is the element’s namespace URI. Any namespace node for any of those three namespaces that was previously present on any element node in the input tree is also removed, unless the prefix that that namespace node declared is used as the prefix on the name of an attribute on that element or an ancestor of that element.

prior to HTML5

The term prior to HTML5 is used in this specification to qualify rules that apply only when the effective version of the html-version serialization parameter is less than 5.0.

recognized as an HTML element

An element node is recognized as an HTML element by the XHTML output method if either of the following conditions is true:

reconstructed tree

A reconstructed tree may be constructed by parsing the XML document and converting it into an document node as specified in [XQuery and XPath Data Model (XDM) 4.0].

requested HTML version

The requested HTML version is the value of the html-version serialization parameter if present; otherwise the value of the version serialization parameter if present; otherwise 5.0.

result tree

The result of the sequence normalization process is a result tree.

sequence

The term sequence is defined in Section 2 BasicsXP. A sequence is an ordered collection of zero or more items.

sequence normalization

The purpose of sequence normalization is to create a sequence that can be serialized as a well-formed XML document or external general parsed entity, that also reflects the content of the input sequence to the extent possible.

serialization error

In some instances, the input tree cannot be successfully converted into a sequence of octets given the set of serialization parameter (3 Serialization Parameters) values specified. A serialization error is said to occur in such an instance.

serialized as an HTML element

An element node is serialized as an HTML element if

serializer

As is indicated in 12 Conformance, conformance criteria for serialization are determined by other specifications that refer to this specification. A serializer is software that implements some or all of the requirements of this specification in accordance with such conformance criteria.

string

The term string is defined in Section 4.1.5 XML and XSD VersionsDM.

string value

The term string value is defined in Section 6.7.127.5.12 string-value AccessorDM. Every node has a string value. For example, the string value of an element is the concatenation of the string values of all its descendant text nodes.

SVG namespace

the SVG namespace, https://www.w3.org/2000/svg

to a JSON string

Whenever a value is serialized to a JSON string, the following procedure is applied to the supplied string:

  1. Any character in the string for which character mapping is defined (see 11 Character Maps) is substituted by the replacement string defined in the character map.

  2. Any other character in the input string (but not a character produced by character mapping) is a candidate for Unicode Normalization if requested by the normalization-form parameter, and JSON escaping. JSON escaping replaces the characters quotation mark, backspace, form-feed, newline, carriage return, tab, or reverse solidus by the corresponding JSON escape sequences \", \b, \f, \n, \r, \t, or \\ respectively, and any other codepoint in the range 1-31 or 127-159 by an escape in the form \uHHHH where HHHH is the hexadecimal representation of the codepoint value. Escaping further replaces the solidus character (/) by the escape sequence \/ if the escape-solidus parameter is set to true, but not if it is set to false. Escaping is also applied to any characters that cannot be represented in the selected encoding.

  3. The resulting string is enclosed in double quotation marks.

Unicode Normalization

Unicode Normalization is the process of removing alternative representations of equivalent sequences from textual data, to convert the data into a form that can be binary-compared for equivalence, as specified in [UAX #15: Unicode Normalization Forms]. For specific recommendations for character normalization on the World Wide Web, see [Character Model for the World Wide Web 1.0: Normalization].

URI attribute values

The values of attributes listed in D List of URI Attributes are URI attribute values. Attributes are not considered to be URI attributes simply because they are namespace declaration attributes or have the type annotation xs:anyURI.

URI Escaping

URI escaping consists of the following three steps applied in sequence to the content of URI attribute values:

void

The void elements of HTML5 are area, base, br, col, embed, hr, img, input, keygen, link, meta, param, source, track and wbr.

whitespace character

A space character, TAB character, CR character or NL character is referred to as a whitespace character.

with HTML5

The term with HTML5 is used in this specification to qualify rules that apply only when the effective version of the html-version serialization parameter is 5.0.

without regard to case

Where this specification indicates that two strings are to be compared without regard to case, the serializermust translate any characters in the range U+0041 (LATIN CAPITAL LETTER A, A) through U+005A (LATIN CAPITAL LETTER Z, Z) inclusive, to the corresponding lower-case letters in the range U+0061 (LATIN SMALL LETTER A, a) through U+007A (LATIN SMALL LETTER Z, z) only for the purposes of making the comparison. The comparison succeeds if the two strings are the same length and the code point of each character in the first string is equal to the code point of the character in the corresponding position in the second string.

XHTML namespace

the XHTML namespace namespace, https://www.w3.org/1999/xhtml

XML Island

The portion of the serialized document representing the result of serializing an element that is not to be serialized as an HTML element is known as an XML Island.

XML namespace

the XML namespace, https://www.w3.org/XML/1998/namespace

G Change Log (Non-Normative)

This appendix lists changes made in version 4.0 of this specification.

  1. Use the arrows to browse significant changes since the 3.1 version of this specification.

    See 1 Introduction

  2. Sections with significant changes are marked Δ in the table of contents.

    See 1 Introduction

  3. The term atomic value has been replaced by atomic item.

    See 1.1 Terminology

  4. Added the json-lines parameter for JSON serialization.

    See 3 Serialization Parameters

    See 9 JSON Output Method

  5. PR TODO 

    The output of QNames reflects the new syntax for QName literals.

    See 10 Adaptive Output Method

  6. PR 342 

    In the HTML and XHTML output methods, the rules for adding and replacing meta elements have been revised to take account of the new HTML5 syntax, for example <meta charset="utf-8">.

    See 6 XHTML Output Method

    See 7 HTML Output Method

  7. PR 534 

    Added the escape-solidus parameter for JSON serialization.

    See 3 Serialization Parameters

    See 9 JSON Output Method

    See 10.1 The Influence of Serialization Parameters upon the Adaptive Output Method

  8. PR 1703 

    The serialization of maps retains the order of entries.

    See 9 JSON Output Method

    See 10 Adaptive Output Method

  9. PR 1977 

    The default HTML version is now 5. This may result in changes to the serialized output in cases where no explicit HTML version is requested.

    See 6 XHTML Output Method

    See 7 HTML Output Method

  10. PR 2031 

    A JNode is replaced by its ¶value property.

    See 9 JSON Output Method

    See 10 Adaptive Output Method