Extensible Markup Language (XML) 1.1 (Second Edition) code { font-family: monospace; }
div.constraint, div.issue, div.note, div.notice { margin-left: 2em; }
ol.enumar { list-style-type: decimal; } ol.enumla { list-style-type: lower-alpha; } ol.enumlr { list-style-type: lower-roman; } ol.enumua { list-style-type: upper-alpha; } ol.enumur { list-style-type: upper-roman; }
div.exampleInner pre { margin-left: 1em; margin-top: 0em; margin-bottom: 0em} div.exampleOuter {border: 4px double gray; margin: 0em; padding: 0em} div.exampleInner { background-color: #d5dee3; border-top-width: 4px; border-top-style: double; border-top-color: #d3d3d3; border-bottom-width: 4px; border-bottom-style: double; border-bottom-color: #d3d3d3; padding: 4px; margin: 0em } div.exampleWrapper { margin: 4px } div.exampleHeader { font-weight: bold; margin: 4px}
em.rfc2119 { text-transform: lowercase; font-variant: small-caps; font-style: normal; } This version: http://www.w3.org/TR/2006/REC-xml11-20060816 Latest version: http://www.w3.org/TR/xml11 Previous version: http://www.w3.org/TR/2006/PER-xml11-20060614 Editors: Tim Bray, Textuality and Netscape <[email protected]> Jean Paoli, Microsoft <[email protected]> C. M. Sperberg-McQueen, W3C <[email protected]> Eve Maler, Sun Microsystems, Inc. <[email protected]> François Yergeau John Cowan <[email protected]> Please refer to the errata The previous errata See also translations This document is also available in these non-normative formats: XML XHTML with color-coded revision indicators Copyright W3C ® MIT ERCIM Keio liability trademark document use The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML. 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 This document specifies a syntax created by subsetting an existing, widely used international text processing standard (Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected) for use on the World Wide Web. It is a product of the XML Core Working Group XML Activity On 29 September 2006 this document was edited in place to remove a number of spurious and potentially misleading spaces. The English version of this specification is the only normative version. However, for translations of this document, see http://www.w3.org/2003/03/Translations/byTechnology?technology=xml11 This document is a W3C Recommendation not http://www.w3.org/XML/xml-V11-1e-errata First Edition of XML 1.1, dated 4 February 2004 [IETF RFC 2119] [IETF RFC 2119] W3C Recommendation of 4 February 2004 Please report errors in this document to the public [email protected] archives XHTML version with color-coded revision indicators errata list http://www.w3.org/XML/xml-V11-2e-errata An implementation report is available at http://www.w3.org/XML/2006/06/xml11-2e-implementation.html Test Suite 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 is governed by the 24 January 2002 CPP W3C Patent Policy Transition Procedure public list of any patent disclosures Essential Claim(s) section 6 of the W3C Patent Policy 1 Introduction Origin and Goals Terminology Rationale and list of changes for XML 1.1 Documents Well-Formed XML Documents Characters Common Syntactic Constructs Character Data and Markup Comments Processing Instructions CDATA Sections Prolog and Document Type Declaration Standalone Document Declaration White Space Handling End-of-Line Handling Language Identification Normalization Checking Logical Structures Start-Tags, End-Tags, and Empty-Element Tags Element Type Declarations Element Content Mixed Content Attribute-List Declarations Attribute Types Attribute Defaults Attribute-Value Normalization Conditional Sections Physical Structures Character and Entity References Entity Declarations Internal Entities External Entities Parsed Entities The Text Declaration Well-Formed Parsed Entities Character Encoding in Entities Version Information in Entities XML Processor Treatment of Entities and References Not Recognized Included Included If Validating Forbidden Included in Literal Notify Bypassed Included as PE Error Construction of Entity Replacement Text Predefined Entities Notation Declarations Document Entity Conformance Validating and Non-Validating Processors Using XML Processors Notation A References Normative References Other References Definitions for Character Normalization Expansion of Entity and Character References Deterministic Content Models Autodetection of Character Encodings Detection Without External Encoding Information Priorities in the Presence of External Encoding Information W3C XML Working Group W3C XML Core Working Group Production Notes Suggestions for XML Names Extensible Markup Language, abbreviated XML, describes a class of data objects called XML documents [ISO 8879] XML documents are made up of storage units called entities characters character data markup [ Definition XML processor Definition application XML was developed by an XML Working Group (originally known as the SGML Editorial Review Board) formed under the auspices of the World Wide Web Consortium (W3C) in 1996. It was chaired by Jon Bosak of Sun Microsystems with the active participation of an XML Special Interest Group (previously known as the SGML Working Group) also organized by the W3C. The membership of the XML Working Group is given in an appendix. Dan Connolly served as the Working Group's contact with the W3C. The design goals for XML are: XML shall be straightforwardly usable over the Internet. XML shall support a wide variety of applications. XML shall be compatible with SGML. It shall be easy to write programs which process XML documents. The number of optional features in XML is to be kept to the absolute minimum, ideally zero. XML documents should be human-legible and reasonably clear. The XML design should be prepared quickly. The design of XML shall be formal and concise. XML documents shall be easy to create. Terseness in XML markup is of minimal importance. This specification, together with associated standards (Unicode [Unicode] [ISO/IEC 10646] [IETF RFC 3066] [ISO 639] [ISO 3166] This version of the XML specification may be distributed freely, as long as all text and legal notices remain intact. The terminology used to describe XML documents is defined in the body of this specification. The key words MUST MUST NOT REQUIRED SHALL SHALL NOT SHOULD SHOULD NOT RECOMMENDED MAY OPTIONAL EMPHASIZED [IETF RFC 2119] error [ Definition MUST REQUIRED MUST NOT SHALL SHALL NOT MAY MAY fatal error [ Definition XML processor MUST MAY MAY MAY MUST NOT MUST NOT at user option [ Definition MAY MUST MUST validity constraint [ Definition valid MUST validating XML processors well-formedness constraint [ Definition well-formed fatal errors match [ Definition are [VC: Element Valid for compatibility [ Definition for interoperability [ Definition The W3C's XML 1.0 Recommendation was first issued in 1998, and despite the issuance of many errata culminating in a Third Edition of 2004, has remained (by intention) unchanged with respect to what is well-formed XML and what is not. This stability has been extremely useful for interoperability. However, the Unicode Standard on which XML 1.0 relies for character specifications has not remained static, evolving from version 2.0 to version 4.0 and beyond. Characters not present in Unicode 2.0 may already be used in XML 1.0 character data. However, they are not allowed in XML names such as element type names, attribute names, enumerated attribute values, processing instruction targets, and so on. In addition, some characters that should have been permitted in XML names were not, due to oversights and inconsistencies in Unicode 2.0. The overall philosophy of names has changed since XML 1.0. Whereas XML 1.0 provided a rigid definition of names, wherein everything that was not permitted was forbidden, XML 1.1 names are designed so that everything that is not forbidden (for a specific reason) is permitted. Since Unicode will continue to grow past version 4.0, further changes to XML can be avoided by allowing almost any character, including those not yet assigned, in names. In addition, XML 1.0 attempts to adapt to the line-end conventions of various modern operating systems, but discriminates against the conventions used on IBM and IBM-compatible mainframes. As a result, XML documents on mainframes are not plain text files according to the local conventions. XML 1.0 documents generated on mainframes must either violate the local line-end conventions, or employ otherwise unnecessary translation phases before parsing and after generation. Allowing straightforward interoperability is particularly important when data stores are shared between mainframe and non-mainframe systems (as opposed to being copied from one to the other). Therefore XML 1.1 adds NEL (#x85) to the list of line-end characters. For completeness, the Unicode line separator character, #x2028, is also supported. Finally, there is considerable demand to define a standard representation of arbitrary Unicode characters in XML documents. Therefore, XML 1.1 allows the use of character references to the control characters #x1 through #x1F, most of which are forbidden in XML 1.0. For reasons of robustness, however, these characters still cannot be used directly in documents. In order to improve the robustness of character encoding detection, the additional control characters #x7F through #x9F, which were freely allowed in XML 1.0 documents, now must also appear only as character references. (Whitespace characters are of course exempt.) The minor sacrifice of backward compatibility is considered not significant. Due to potential problems with APIs, #x0 is still forbidden both directly and as a character reference. Finally, XML 1.1 defines a set of constraints called "full normalization" on XML documents, which document creators SHOULD SHOULD A new XML version, rather than a set of errata to XML 1.0, is being created because the changes affect the definition of well-formed documents. XML 1.0 processors must continue to reject documents that contain new characters in XML names, new line-end conventions, and references to control characters. The distinction between XML 1.0 and XML 1.1 documents is indicated by the version number information in the XML declaration at the start of each document. [ Definition XML document well-formed In addition, the XML document is valid Each XML document has both a logical and a physical structure. Physically, the document is composed of units called entities may refer document entity MUST 4.3.2 Well-Formed Parsed Entities [ Definition well-formed Taken as a whole, it matches the production labeled document It meets all the well-formedness constraints given in this specification. Each of the parsed entities well-formed document ::= ( prolog element Misc ) ( Char RestrictedChar Char ) Matching the document It contains one or more elements [ Definition root content start-tag end-tag [ Definition C P C P P P parent C C child P [ Definition text characters Definition character [ISO/IEC 10646] A.1 Normative References MUST Char Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ RestrictedChar ::= [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] | [#x86-#x9F] The mechanism for encoding character code points into bit patterns may MUST [Unicode] 4.3.3 Character Encoding in Entities Note: Document authors are encouraged to avoid "compatibility characters", as defined in Unicode [Unicode] [#x1-#x8], [#xB-#xC], [#xE-#x1F], x x x x x x x x x x x x x x x x This section defines some symbols used widely in the grammar. S S ::= (#x20 | #x9 | #xD | #xA)+ Note: The presence of #xD in the above production is maintained purely for backward compatibility with the First Edition 2.11 End-of-Line Handling [ Definition Name xml (('X'|'x') ('M'|'m') ('L'|'l')) Note: The Namespaces in XML Recommendation [XML Names] An Nmtoken The first character of a Name MUST MUST I Suggestions for XML Names Document authors are encouraged to use names which are meaningful words or combinations of words in natural languages, and to avoid symbolic or white space characters in names. Note that COLON, HYPHEN-MINUS, FULL STOP (period), LOW LINE (underscore), and MIDDLE DOT are explicitly permitted. The ASCII symbols and punctuation marks, along with a fairly large group of Unicode symbol characters, are excluded from names because they are more useful as delimiters in contexts where XML names are used outside XML documents; providing this group gives those contexts hard guarantees about what cannot NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF] NameChar ::= NameStartChar Name ::= NameStartChar NameChar Names ::= Name Name Nmtoken ::= ( NameChar Nmtokens ::= Nmtoken Nmtoken Note: The Names Nmtokens 3.3.1 Attribute Types Literal data is any quoted string not containing the quotation mark used as a delimiter for that string. Literals are used for specifying the content of internal entities ( EntityValue AttValue SystemLiteral SystemLiteral EntityValue ::= '"' ([^%&"] | PEReference Reference | "'" ([^%&'] | PEReference Reference AttValue ::= '"' ([^<&"] | Reference | "'" ([^<&'] | Reference SystemLiteral ::= ('"' [^"]* '"') | ("'" [^']* "'") PubidLiteral ::= '"' PubidChar PubidChar PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%] Note: Although the EntityValue < <!ENTITY mylt "<"> Text character data Definition Markup start-tags end-tags empty-element tags entity references character references comments CDATA section document type declarations processing instructions XML declarations text declarations [ Definition character data The ampersand character (&) and the left angle bracket (<) MUST NOT comment processing instruction CDATA section MUST escaped numeric character references & < may > MUST for compatibility > ]]> CDATA section In the content of elements, character data is any string of characters which does not contain the start-delimiter of any markup or the CDATA-section-close delimiter, " ]]> To allow attribute values to contain both single and double quotes, the apostrophe or single-quote character (') may ' " CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*) [ Definition Comments may markup may character data MAY For compatibility -- MUST NOT MUST NOT Comment ::= '<!--' (( Char Char An example of a comment: <!-- declarations for <head> & <body> --> Note that the grammar does not allow a comment ending in ---> not <!-- B+, B, or B---> [ Definition Processing instructions PI ::= '<?' PITarget S Char Char Char PITarget ::= Name PIs are not part of the document's character data MUST PITarget XML xml Notation may MUST NOT [ Definition CDATA sections may <![CDATA[ ]]> CDSect ::= CDStart CData CDEnd CDStart ::= '<![CDATA[' CData ::= ( Char Char Char CDEnd ::= ']]>' Within a CDATA section, only the CDEnd < & An example of a CDATA section, in which " <greeting> </greeting> character data markup <![CDATA[<greeting>Hello, world!</greeting>]]> [ Definition MUST XML declaration well-formed valid <?xml version="1.1"?> <greeting>Hello, world!</greeting> but the following is an XML 1.0 document because it does not have an XML declaration: <greeting>Hello, world!</greeting> The function of the markup in an XML document is to describe its storage and logical structure and to associate attribute name-value pairs with its logical structures. XML provides a mechanism, the document type declaration Definition valid The document type declaration MUST element prolog ::= XMLDecl Misc doctypedecl Misc XMLDecl ::= '<?xml' VersionInfo EncodingDecl SDDecl S VersionInfo ::= S Eq VersionNum VersionNum Eq ::= S S VersionNum ::= '1.1' Misc ::= Comment PI S [ Definition document type declaration markup declarations DTD external entity [ Definition markup declaration element type declaration attribute-list declaration entity declaration notation declaration may parameter entities 4 Physical Structures doctypedecl ::= '<!DOCTYPE' S Name S ExternalID S intSubset S [VC: Root Element Type] [WFC: External Subset] DeclSep ::= PEReference S [WFC: PE Between Declarations] intSubset ::= ( markupdecl DeclSep markupdecl ::= elementdecl AttlistDecl EntityDecl NotationDecl PI Comment [VC: Proper Declaration/PE Nesting] [WFC: PEs in Internal Subset] Note that it is possible to construct a well-formed document containing a doctypedecl The markup declarations may replacement text parameter entities elementdecl AttlistDecl after included Parameter entity references are recognized anywhere in the DTD (internal and external subsets and external parameter entities), except in literals, processing instructions, comments, and the contents of ignored conditional sections (see 3.4 Conditional Sections Validity constraint: Root Element Type The Name MUST root element Validity constraint: Proper Declaration/PE Nesting Parameter-entity replacement text MUST markupdecl parameter-entity reference MUST Well-formedness constraint: PEs in Internal Subset In the internal DTD subset, parameter-entity references MUST NOT may Well-formedness constraint: External Subset The external subset, if any, MUST extSubset Well-formedness constraint: PE Between Declarations The replacement text of a parameter entity reference in a DeclSep MUST extSubsetDecl Like the internal subset, the external subset and any external parameter entities referenced in a DeclSep MUST markupdecl parameter-entity references may conditional section extSubset ::= TextDecl extSubsetDecl extSubsetDecl ::= ( markupdecl conditionalSect DeclSep The external subset and external parameter entities also differ from the internal subset in that in them, parameter-entity references within between An example of an XML document with a document type declaration: <?xml version="1.1"?> <!DOCTYPE greeting SYSTEM "hello.dtd"> <greeting>Hello, world!</greeting> The system identifier hello.dtd The declarations can also be given locally, as in this example: <?xml version="1.1" encoding="UTF-8" ?> <!DOCTYPE greeting [ <!ELEMENT greeting (#PCDATA)> ]> <greeting>Hello, world!</greeting> If both the external and internal subsets are used, the internal subset MUST If a document is well-formed or valid XML 1.0, and provided it does not contain any control characters in the range [#x7F-#x9F] other than as character escapes, it may be made well-formed or valid XML 1.1 respectively simply by changing the version number. Markup declarations can affect the content of the document, as passed from an XML processor may document entity Definition external markup declaration SDDecl ::= S Eq [VC: Standalone Document Declaration] In a standalone document declaration, the value "yes" indicates that there are no external markup declarations declarations entities If there are no external markup declarations, the standalone document declaration has no meaning. If there are external markup declarations but there is no standalone document declaration, the value "no" is assumed. Any XML document for which standalone="no" Validity constraint: Standalone Document Declaration The standalone document declaration MUST attributes with default entities (other than amp lt gt apos quot references attributes with tokenized types, where the attribute appears in the document with a value such that normalization element types with element content An example XML declaration with a standalone document declaration: <?xml version="1.1" standalone='yes'?> In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, "significant" white space that should be preserved in the delivered version is common, for example in poetry and source code. An XML processor MUST validating XML processor MUST element content A special attribute xml:space may MUST declared MUST enumerated type <!ATTLIST poem xml:space (default|preserve) 'preserve'> <!ATTLIST pre xml:space (preserve) #FIXED 'preserve'> The value "default" signals that applications' default white-space processing modes are acceptable for this element; the value "preserve" indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space xml:space MAY MAY The root element XML parsed entities To simplify the tasks of applications XML processor MUST the two-character sequence #xD #xA the two-character sequence #xD #x85 the single character #x85 the single character #x2028 any #xD character that is not immediately followed by #xA or #x85. The characters #x85 and #x2028 cannot be reliably recognized and translated until an entity's encoding declaration (if present) has been read. Therefore, it is a fatal error to use them within the XML declaration or text declaration. In document processing, it is often useful to identify the natural or formal language in which the content is written. A special attribute xml:lang may MUST declared [IETF RFC 3066] Tags for the Identification of Languages may (Productions 33 through 38 have been removed.) For example: <p xml:lang="en">The quick brown fox jumps over the lazy dog.</p> <p xml:lang="en-GB">What colour is it?</p> <p xml:lang="en-US">What color is it?</p> <sp who="Faust" desc='leise' xml:lang="de"> <l>Habe nun, ach! Philosophie,</l> <l>Juristerei, und Medizin</l> <l>und leider auch Theologie</l> <l>durchaus studiert mit heißem Bemüh'n.</l> </sp> The language specified by xml:lang applies (including the values of its attributes), and to all elements in its content another xml:lang xml:lang xml:lang xml:lang Applications determine which of an element's attribute values and which parts of its character content, if any, are treated as language-dependent values described by xml:lang Note: Language information may also be provided by external transport protocols (e.g. HTTP or MIME). When available, this information may be used by XML applications, but the more local information provided by xml:lang A simple declaration for xml:lang xml:lang CDATA #IMPLIED but specific default values may xml:lang <!ATTLIST poem xml:lang CDATA 'fr'> <!ATTLIST gloss xml:lang CDATA 'en'> <!ATTLIST note xml:lang CDATA 'en'> All XML parsed entities document entities SHOULD fully normalized B Definitions for Character Normalization The replacement text parsed entities All text matching, in context, one of the following productions: CData CharData content Name Nmtoken However, a document is still well-formed even if it is not fully normalized SHOULD fully normalized SHOULD certified B Definitions for Character Normalization The verification of full normalization MUST include-normalized B Definitions for Character Normalization composing character B Definitions for Character Normalization MUST Note: The composing character composing character If, while verifying full normalization, a processor encounters characters for which it cannot determine the normalization properties (i.e., characters introduced in a version of Unicode [Unicode] MAY SHOULD NOT XML processors MUST NOT fully normalized SHOULD fully normalized fully normalized The purpose of this section is to strongly encourage XML processors to ensure that the creators of XML documents have properly normalized them, so that XML applications can make tests such as identity comparisons of strings without having to worry about the different possible "spellings" of strings which Unicode allows. When entities are in a non-Unicode encoding, if the processor transcodes them to Unicode, it SHOULD [ Definition XML document elements start-tags end-tags empty empty-element tag may name value element ::= EmptyElemTag | STag content ETag [WFC: Element Type Match] [VC: Element Valid] This specification does not constrain the application (('X'|'x')('M'|'m')('L'|'l')) Well-formedness constraint: Element Type Match The Name MUST Validity constraint: Element Valid An element is valid if there is a declaration matching elementdecl Name The declaration matches EMPTY content The declaration matches children child elements Misc S S The declaration matches Mixed , character data (including CDATA sections comments PIs child elements The declaration matches ANY , CDATA sections comments PIs child elements [ Definition start-tag STag ::= '<' Name S Attribute S [WFC: Unique Att Spec] Attribute ::= Name Eq AttValue [VC: Attribute Value Type] [WFC: No External Entity References] [WFC: No < in Attribute Values] The Name type Definition Name AttValue attribute specifications Definition Name attribute name Definition AttValue ' " attribute value Well-formedness constraint: Unique Att Spec An attribute name MUST NOT Validity constraint: Attribute Value Type The attribute MUST MUST 3.3 Attribute-List Declarations Well-formedness constraint: No External Entity References Attribute values MUST NOT Well-formedness constraint: No < The replacement text MUST NOT < An example of a start-tag: <termdef id="dt-dog" term="dog"> [ Definition MUST end-tag ETag ::= '</' Name S An example of an end-tag: </termdef> [ Definition text content content ::= CharData element Reference CDSect PI Comment CharData [ Definition content empty Definition empty-element tag EmptyElemTag ::= '<' Name S Attribute S [WFC: Unique Att Spec] Empty-element tags may EMPTY For interoperability SHOULD SHOULD Examples of empty elements: <IMG align="left" src="http://www.w3.org/Icons/WWW/w3c_home" /> <br></br> <br/> The element XML document may validation content Element type declarations often constrain which element types can appear as children MAY [ Definition element type declaration elementdecl ::= '<!ELEMENT' S Name S contentspec S [VC: Unique Element Type Declaration] contentspec ::= 'EMPTY' | 'ANY' | Mixed children where the Name Validity constraint: Unique Element Type Declaration An element type MUST NOT Examples of element type declarations: <!ELEMENT br EMPTY> <!ELEMENT p (#PCDATA|emph)* > <!ELEMENT %name.para; %content.para; > <!ELEMENT container ANY> [ Definition type element content MUST child S Definition content model cp children ::= ( choice seq cp ::= ( Name choice seq choice ::= '(' S cp S S cp S [VC: Proper Group/PE Nesting] seq ::= '(' S cp S S cp S [VC: Proper Group/PE Nesting] where each Name may child may element content MUST element content + * ? MUST The content of an element matches a content model if and only if it is possible to trace out a path through the content model, obeying the sequence, choice, and repetition operators and matching each element in the content against an element type in the content model. For compatibility D Deterministic Content Models Validity constraint: Proper Group/PE Nesting Parameter-entity replacement text MUST choice seq Mixed parameter entity MUST For interoperability choice seq Mixed SHOULD SHOULD | , Examples of element-content models: <!ELEMENT spec (front, body, back?)> <!ELEMENT div1 (head, (p | list | note)*, div2*)> <!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*> [ Definition type mixed content may child may Mixed ::= '(' S S S Name S | '(' S S [VC: Proper Group/PE Nesting] [VC: No Duplicate Types] where the Name #PCDATA Validity constraint: No Duplicate Types The same name MUST NOT Examples of mixed content declarations: <!ELEMENT p (#PCDATA|a|ul|b|i|em)*> <!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* > <!ELEMENT b (#PCDATA)> Attributes elements MUST NOT start-tags empty-element tags 3.1 Start-Tags, End-Tags, and Empty-Element Tags may To define the set of attributes pertaining to a given element type. To establish type constraints for these attributes. To provide default values [ Definition Attribute-list declarations AttlistDecl ::= '<!ATTLIST' S Name AttDef S AttDef ::= S Name S AttType S DefaultDecl The Name AttlistDecl MAY Name AttDef When more than one AttlistDecl For interoperability, may MAY XML attribute types are of three kinds: a string type, a set of tokenized types, and enumerated types. The string type may take any literal string as a value; the tokenized types are more constrained 3.3.3 Attribute-Value Normalization AttType ::= StringType TokenizedType EnumeratedType StringType ::= 'CDATA' TokenizedType ::= 'ID' [VC: ID] [VC: One ID per Element Type] [VC: ID Attribute Default] | 'IDREF' [VC: IDREF] | 'IDREFS' [VC: IDREF] | 'ENTITY' [VC: Entity Name] | 'ENTITIES' [VC: Entity Name] | 'NMTOKEN' [VC: Name Token] | 'NMTOKENS' [VC: Name Token] Validity constraint: ID Values of type ID MUST Name MUST NOT MUST Validity constraint: One ID per Element Type An element type MUST NOT Validity constraint: ID Attribute Default An ID attribute MUST #IMPLIED #REQUIRED Validity constraint: IDREF Values of type IDREF MUST Name IDREFS MUST Names Name MUST IDREF MUST Validity constraint: Entity Name Values of type ENTITY MUST Name ENTITIES MUST Names Name MUST unparsed entity DTD Validity constraint: Name Token Values of type NMTOKEN MUST Nmtoken NMTOKENS MUST Nmtokens [ Definition Enumerated attributes have a list of allowed values in their declaration They MUST attribute EnumeratedType ::= NotationType Enumeration NotationType ::= 'NOTATION' S S Name S S Name S [VC: Notation Attributes] [VC: One Notation Per Element Type] [VC: No Notation on Empty Element] [VC: No Duplicate Tokens] Enumeration ::= '(' S Nmtoken S S Nmtoken S [VC: Enumeration] [VC: No Duplicate Tokens] A NOTATION notation Validity constraint: Notation Attributes Values of this type MUST notation MUST Validity constraint: One Notation Per Element Type An element type MUST NOT NOTATION Validity constraint: No Notation on Empty Element For compatibility NOTATION MUST NOT EMPTY Validity constraint: No Duplicate Tokens The notation names in a single NotationType NmToken Enumeration MUST Validity constraint: Enumeration Values of this type MUST Nmtoken For interoperability, Nmtoken SHOULD NOT An attribute declaration REQUIRED DefaultDecl ::= '#REQUIRED' | '#IMPLIED' | (('#FIXED' S AttValue [VC: Required Attribute] [VC: Attribute Default Value Syntactically Correct] [WFC: No < in Attribute Values] [VC: Fixed Attribute Default] [WFC: No External Entity References] In an attribute declaration, #REQUIRED MUST #IMPLIED Definition #REQUIRED #IMPLIED AttValue default #FIXED MUST MUST Validity constraint: Required Attribute If the default declaration is the keyword #REQUIRED MUST Validity constraint: Attribute Default Value Syntactically Correct The declared default value MUST That is, the default value of an attribute: of type IDREF or ENTITY must match the Name of type IDREFS or ENTITIES must match the Names of type NMTOKEN must match the Nmtoken of type NMTOKENS must match the Nmtokens of an enumerated type NOTATION enumeration Note that only the syntactic constraints of the type are required here; other constraints (e.g. that the value be the name of a declared unparsed entity, for an attribute of type ENTITY) will be reported by a validating parser only if an element without a specification for this attribute actually occurs Validity constraint: Fixed Attribute Default If an attribute has a default value declared with the #FIXED MUST Examples of attribute-list declarations: <!ATTLIST termdef id ID #REQUIRED name CDATA #IMPLIED> <!ATTLIST list type (bullets|ordered|glossary) "ordered"> <!ATTLIST form method CDATA #FIXED "POST"> Before the value of an attribute is passed to the application or checked for validity, the XML processor MUST All line breaks MUST 2.11 End-of-Line Handling Begin with a normalized value consisting of the empty string. For each character, entity reference, or character reference in the unnormalized attribute value, beginning with the first and continuing to the last, do the following: For a character reference, append the referenced character to the normalized value. For an entity reference, recursively apply step 3 of this algorithm to the replacement text of the entity. For a white space character (#x20, #xD, #xA, #x9), append a space character (#x20) to the normalized value. For another character, append the character to the normalized value. If the attribute type is not CDATA, then the XML processor MUST Note that if the unnormalized attribute value contains a character reference to a white space character other than space (#x20), the normalized value contains the referenced character itself (#xD, #xA or #x9). This contrasts with the case where the unnormalized value contains a white space character (not a reference), which is replaced with a space character (#x20) in the normalized value and also contrasts with the case where the unnormalized value contains an entity reference whose replacement text contains a white space character; being recursively processed, the white space character is replaced with a space character (#x20) in the normalized value. All attributes for which no declaration has been read SHOULD CDATA It is an error if an attribute value reference Following are examples of attribute normalization. Given the following declarations: <!ENTITY d "
"> <!ENTITY a "
"> <!ENTITY da "
"> the attribute specifications in the left column below would be normalized to the character sequences of the middle column if the attribute a NMTOKENS a CDATA Attribute specification a is NMTOKENS a is CDATA a=" xyz" x y z #x20 #x20 x y z a="&d;&d;A&a; &a;B&da;" A #x20 B #x20 #x20 A #x20 #x20 #x20 B #x20 #x20 a= "

A

B
" #xD #xD A #xA #xA B #xD #xA #xD #xD A #xA #xA B #xD #xA Note that the last example is invalid (but well-formed) if a NMTOKENS [ Definition Conditional sections document type declaration external subset conditionalSect ::= includeSect ignoreSect includeSect ::= '<![' S S extSubsetDecl [VC: Proper Conditional Section/PE Nesting] ignoreSect ::= '<![' S S ignoreSectContents [VC: Proper Conditional Section/PE Nesting] ignoreSectContents ::= Ignore ignoreSectContents Ignore Ignore ::= Char Char Char Validity constraint: Proper Conditional Section/PE Nesting If any of the " <![ [ ]]> MUST Like the internal and external DTD subsets, a conditional section may contain one or more complete declarations, comments, processing instructions, or nested conditional sections, intermingled with white space. If the keyword of the conditional section is INCLUDE MUST processed as IGNORE MUST NOT INCLUDE IGNORE MUST MUST [ <![ ]]> MUST NOT If the keyword of the conditional section is a parameter-entity reference, the parameter entity MUST An example: <!ENTITY % draft 'INCLUDE' > <!ENTITY % final 'IGNORE' > <![%draft;[ <!ELEMENT book (comments*, title, body, supplements?)> ]]> <![%final;[ <!ELEMENT book (title, body, supplements?)> ]]> [ Definition entities content document entity external DTD subset name document entity XML processor Entities may be either parsed or unparsed. [ Definition parsed entity replacement text text [ Definition unparsed entity text notation Parsed entities are invoked by name using entity references; unparsed entities by name, given in the value of ENTITY ENTITIES [ Definition General entities entity Definition Parameter entities [ Definition character reference CharRef ::= '&#' [0-9]+ ';' | '&#x' [0-9a-fA-F]+ ';' [WFC: Legal Character] Well-formedness constraint: Legal Character Characters referred to using character references MUST Char If the character reference begins with " &#x ; &# ; [ Definition entity reference Definition & ; Definition Parameter-entity references % ; Reference ::= EntityRef CharRef EntityRef ::= '&' Name [WFC: Entity Declared] [VC: Entity Declared] [WFC: Parsed Entity] [WFC: No Recursion] PEReference ::= '%' Name [VC: Entity Declared] [WFC: No Recursion] [WFC: In DTD] Well-formedness constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with " standalone='yes' Name MUST match entity declaration amp lt gt apos quot MUST Note that non-validating processors are not obligated to standalone='yes' Validity constraint: Entity Declared In a document with an external subset or parameter entity references standalone='no' Name MUST match entity declaration SHOULD amp lt gt apos quot 4.6 Predefined Entities MUST MUST Well-formedness constraint: Parsed Entity An entity reference MUST NOT unparsed entity attribute values ENTITY ENTITIES Well-formedness constraint: No Recursion A parsed entity MUST NOT Well-formedness constraint: In DTD Parameter-entity references MUST NOT DTD Examples of character and entity references: Type <key>less-than</key> (<) to save options. This document was prepared on &docdate; and is classified &security-level;. Example of a parameter-entity reference: <!-- declare the parameter entity "ISOLat2"... --> <!ENTITY % ISOLat2 SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" > <!-- ... now reference it. --> %ISOLat2; [ Definition EntityDecl ::= GEDecl PEDecl GEDecl ::= '<!ENTITY' S Name S EntityDef S PEDecl ::= '<!ENTITY' S S Name S PEDef S EntityDef ::= EntityValue ExternalID NDataDecl PEDef ::= EntityValue ExternalID The Name entity reference ENTITY ENTITIES MAY [ Definition EntityValue internal entity literal entity value replacement text 4.5 Construction of Entity Replacement Text An internal entity is a parsed entity Example of an internal entity declaration: <!ENTITY Pub-Status "This is a pre-release of the specification."> [ Definition external entity ExternalID ::= 'SYSTEM' S SystemLiteral | 'PUBLIC' S PubidLiteral S SystemLiteral NDataDecl ::= S S Name [VC: Notation Declared] If the NDataDecl unparsed entity Validity constraint: Notation Declared The Name MUST notation [ Definition SystemLiteral system identifier [IETF RFC 3986] # document entity external DTD subset external parameter entity may Location: System identifiers (and other XML strings meant to be used as URI references) may [IETF RFC 3986] unwise MUST SHOULD MUST Each character to be escaped is represented in UTF-8 [Unicode] The resulting bytes are escaped with the URI escaping mechanism (that is, converted to % HH The original character is replaced by the resulting character sequence. [ Definition may public identifier may MUST MUST MUST Examples of external entity declarations: <!ENTITY open-hatch SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml"> <!ENTITY open-hatch PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN" "http://www.textuality.com/boilerplate/OpenHatch.xml"> <!ENTITY hatch-pic SYSTEM "../grafix/OpenHatch.gif" NDATA gif > External parsed entities SHOULD text declaration TextDecl ::= '<?xml' VersionInfo EncodingDecl S The text declaration MUST MUST NOT replacement text The document entity is well-formed if it matches the production labeled document extParsedEnt Note: Only parsed entities that are referenced directly or indirectly within the document are required to be well-formed. extParsedEnt ::= ( TextDecl content ) ( Char RestrictedChar Char ) An internal general parsed entity is well-formed if its replacement text matches the production labeled content A consequence of well-formedness in general entities is that the logical and physical structures in an XML document are properly nested; no start-tag end-tag empty-element tag element comment processing instruction character reference entity reference Each external parsed entity in an XML document may MUST Entities encoded in UTF-16 MUST MAY [ISO/IEC 10646] [Unicode] MUST Although an XML processor is required to read only entities in the UTF-8 and UTF-16 encodings, it is recognized that other encodings are used around the world, and it may be desired for XML processors to read entities that use them. In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 MUST 4.3.1 The Text Declaration EncodingDecl ::= S Eq EncName EncName EncName ::= [A-Za-z] ([A-Za-z0-9._] | '-')* /* Encoding name contains only Latin characters */ In the document entity XML declaration EncName In an encoding declaration, the values " UTF-8 UTF-16 ISO-10646-UCS-2 ISO-10646-UCS-4 SHOULD ISO-8859-1 ISO-8859-2 ISO-8859- n n SHOULD ISO-2022-JP Shift_JIS EUC-JP SHOULD RECOMMENDED charset [IANA-CHARSETS] SHOULD SHOULD SHOULD In the absence of information provided by an external transport protocol (e.g. HTTP or MIME), it is a fatal error It is a fatal error TextDecl It is a fatal error fatal error [Unicode] fatal error Examples of text declarations containing encoding declarations: <?xml encoding='UTF-8'?> <?xml encoding='EUC-JP'?> Each entity, including the document entity If an entity (including the document entity) is not labeled with a version number, it is treated as if labeled as version 1.0. The table below summarizes the contexts in which character references, entity references, and invocations of unparsed entities might appear and the REQUIRED XML processor Reference in Content as a reference anywhere after the start-tag end-tag content Reference in Attribute Value as a reference within either the value of an attribute in a start-tag attribute declaration AttValue Occurs as Attribute Value as a Name ENTITY ENTITIES Reference in Entity Value as a reference within a parameter or internal entity's literal entity value EntityValue Reference in DTD as a reference within either the internal or external subsets of the DTD EntityValue AttValue PI Comment SystemLiteral PubidLiteral 3.4 Conditional Sections . Entity Type Character Parameter Internal General External Parsed General Unparsed Reference in Content Not recognized Included Included if validating Forbidden Included Reference in Attribute Value Not recognized Included in literal Forbidden Forbidden Included Occurs as Attribute Value Not recognized Forbidden Forbidden Notify Not recognized Reference in EntityValue Included in literal Bypassed Bypassed Error Included Reference in DTD Included as PE Forbidden Forbidden Forbidden Forbidden Outside the DTD, the % content [ Definition included replacement text may character data markup MUST AT&T; AT&T; included When an XML processor recognizes a reference to a parsed entity, in order to validate MUST include MAY MUST This rule is based on the recognition that the automatic inclusion provided by the SGML and XML entity mechanism, primarily designed to support modularity in authoring, is not necessarily appropriate for other applications, in particular document browsing. Browsers, for example, when encountering an external parsed entity reference, might choose to provide a visual indication of the entity's presence and retrieve it for display only on demand. The following are forbidden, and constitute fatal errors the appearance of a reference to an unparsed entity EntityValue the appearance of any character or general-entity reference in the DTD except within an EntityValue AttValue a reference to an external entity in an attribute value. When an entity reference replacement text MUST MUST MUST NOT <!ENTITY % YN '"Yes"' > <!ENTITY WhatHeSaid "He said %YN;" > while this is not: <!ENTITY EndAttr "27'" > <element attribute='a-&EndAttr;> When the name of an unparsed entity ENTITY ENTITIES MUST system public notation When a general entity reference appears in the EntityValue MUST Just as with external parsed entities, parameter entities need only be included if validating replacement text MUST MUST NOT 4.4.5 Included in Literal It is an error EntityValue In discussing the treatment of entities, it is useful to distinguish two forms of the entity's value. [ Definition literal entity value EntityValue Definition literal entity value Definition replacement text Definition replacement text The literal entity value as given in an internal entity declaration ( EntityValue may MUST included included in literal MUST replacement text MUST MUST <!ENTITY % pub "Éditions Gallimard" > <!ENTITY rights "All rights reserved" > <!ENTITY book "La Peste: Albert Camus, © 1947 %pub;. &rights;" > then the replacement text for the entity " book La Peste: Albert Camus, © 1947 Éditions Gallimard. &rights; The general-entity reference " &rights; &book; These simple rules may have complex interactions; for a detailed discussion of a difficult example, see C Expansion of Entity and Character References [ Definition may escape amp lt gt apos quot may MUST < & may < & All XML processors MUST For interoperability SHOULD lt amp MUST REQUIRED gt apos quot MUST OPTIONAL <!ENTITY lt "&#60;"> <!ENTITY gt ">"> <!ENTITY amp "&#38;"> <!ENTITY apos "'"> <!ENTITY quot """> [ Definition Notations unparsed entities processing instruction [ Definition Notation declarations NotationDecl ::= '<!NOTATION' S Name S ExternalID PublicID S [VC: Unique Notation Name] PublicID ::= 'PUBLIC' S PubidLiteral Validity constraint: Unique Notation Name A given Name MUST NOT XML processors MUST MAY system identifier [ Definition document entity XML processor Conforming XML processors Validating and non-validating processors alike MUST document entity parsed entities [ Definition Validating processors MUST DTD MUST Non-validating processors are REQUIRED document entity Definition REQUIRED process not MUST normalize include default attribute values standalone="yes" MUST NOT process entity declarations attribute-list declarations standalone="yes" MUST Note that when processing invalid documents with a non-validating processor the application may not be presented with consistent information. For example, several requirements for uniqueness within the document may not be met, including more than one element with the same id, duplicate declarations of elements or notations with the same name, etc. In these cases the behavior of the parser with respect to reporting such information to the application is undefined. XML 1.1 processors MUST SHOULD The behavior of a validating XML processor is highly predictable; it must read every piece of a document and report all well-formedness and validity violations. Less is required of a non-validating processor; it need not read any part of the document other than the document entity. This has two effects that may be important to users of XML processors: Certain well-formedness errors, specifically those that require reading external entities, may fail to be detected by a non-validating processor. Examples include the constraints entitled Entity Declared Parsed Entity No Recursion forbidden 4.4 XML Processor Treatment of Entities and References The information passed from the processor to the application may vary, depending on whether the processor reads parameter and external entities. For example, a non-validating processor may fail to normalize include default attribute values For maximum reliability in interoperating between different XML processors, applications which use non-validating processors SHOULD NOT ) SHOULD The formal grammar of XML is given in this specification using a simple Extended Backus-Naur Form (EBNF) notation. Each rule in the grammar defines one symbol, in the form symbol ::= expression Symbols are written with an initial capital letter if they are the start symbol of a regular language, otherwise with an initial lowercase letter. Literal strings are quoted. Within the expression on the right-hand side of a rule, the following expressions are used to match strings of one or more characters: #xN where N N #xN [a-zA-Z] [#xN-#xN] matches any Char [abc] [#xN#xN#xN] matches any Char [^a-z] [^#xN-#xN] matches any Char outside [^abc] [^#xN#xN#xN] matches any Char "string" matches a literal string matching 'string' matches a literal string matching These symbols may be combined to match more complex patterns as follows, where A B ( expression expression A? matches A A A B matches A B A B | C D (A B) | (C D) A | B matches A B A - B matches any string that matches A B A+ matches one or more occurrences of A A+ | B+ (A+) | (B+) A* matches zero or more occurrences of A A* | B* (A*) | (B*) Other notations used in the productions are: /* ... */ comment. [ wfc: ... ] well-formedness constraint; this identifies by name a constraint on well-formed [ vc: ... ] validity constraint; this identifies by name a constraint on valid (Internet Assigned Numbers Authority) Official Names for Character Sets IETF (Internet Engineering Task Force). RFC 2119: Key words for use in RFCs to Indicate Requirement Levels IETF (Internet Engineering Task Force). RFC 3066: Tags for the Identification of Languages IETF (Internet Engineering Task Force). RFC 3986: Uniform Resource Identifier (URI): Generic Syntax ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane ISO/IEC 10646-2:2001. Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2: Supplementary Planes http://www.iso.ch The Unicode Consortium. The Unicode Standard, Version 4.0. http://www.unicode.org/unicode/standard/versions W3C. Extensible Markup Language (XML) 1.0 (Fourth Edition) Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools Brüggemann-Klein, Anne. Formal Models in Document Processing Brüggemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages One-Unambiguous Regular Languages W3C Working Draft. Character Model for the World Wide Web 1.0 James Clark. Comparison of SGML and XML (Internet Assigned Numbers Authority) Registry of Language Tags IETF (Internet Engineering Task Force). RFC 2141: URN Syntax IETF (Internet Engineering Task Force). RFC 3023: XML Media Types IETF (Internet Engineering Task Force). RFC 2781: UTF-16, an encoding of ISO 10646 (International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. (International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of countries and their subdivisions — Part 1: Country codes ISO (International Organization for Standardization). ISO 8879:1986(E). Information processing — Text and Office Systems — Standard Generalized Markup Language (SGML). ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology — Hypermedia/Time-based Structuring Language (HyTime). Extended Facilities Annexe. ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology — Document Description and Processing Languages Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML This appendix contains the necessary definitions for character normalization. For additional background information and examples, see [Charmod] [ Definition Unicode encoding form [ Definition Legacy encoding [ Definition normalizing transcoder legacy encoding Unicode encoding form [Unicode] [ Definition character escape expressing syntax-significant characters while disregarding their significance in the syntax of the language, or expressing characters not representable in the character encoding chosen for an instance of the language, or expressing characters in general, without use of the corresponding character codes. [ Definition Certified it has been confirmed through inspection that the text is in normalized form the source text-processing component is identified and is known to produce only normalized text. [ Definition Unicode-normalized Unicode encoding form [Unicode] [ Definition include-normalized the text is Unicode-normalized character escapes includes Unicode-normalized the text is in a legacy encoding Unicode encoding form normalizing transcoder [ Definition composing character the second character in the canonical decomposition mapping of some primary composite (as defined in D3 of UAX #15 [Unicode] of non-zero canonical combining class (as defined in Unicode [Unicode] [ Definition fully-normalized the text is in a Unicode encoding form include-normalized relevant constructs composing character composing character the text is in a legacy encoding Unicode encoding form normalizing transcoder This appendix contains some examples illustrating the sequence of entity- and character-reference recognition and expansion, as specified in 4.4 XML Processor Treatment of Entities and References If the DTD contains the declaration <!ENTITY example "<p>An ampersand (&#38;) may be escaped numerically (&#38;#38;) or with a general entity (&amp;).</p>" > then the XML processor will recognize the character references when it parses the entity declaration, and resolve them before storing the following string as the value of the entity " example <p>An ampersand (&) may be escaped numerically (&#38;) or with a general entity (&amp;).</p> A reference in the document to " &example; p p An ampersand (&) may be escaped numerically (&) or with a general entity (&). A more complex example will illustrate the rules and their effects fully. In the following example, the line numbers are solely for reference. 1 <?xml version='1. 1 This produces the following: in line 4, the reference to character 37 is expanded immediately, and the parameter entity " xx %zz; zz zz in line 5, the character reference " < zz <!ENTITY tricky "error-prone"> in line 6, the reference to " xx xx %zz; zz <!ENTITY tricky "error-prone"> tricky error-prone in line 8, the reference to the general entity " tricky test This sample shows a error-prone method. As noted in 3.2.1 Element Content for compatibility For example, the content model ((b, c) | (b, d)) b b b b (b, (c | d)) b c d More formally: a finite state automaton may be constructed from the content model using the standard algorithms, e.g. algorithm 3.5 in section 3.9 of Aho, Sethi, and Ullman [Aho/Ullman] Algorithms exist which allow many but not all non-deterministic content models to be reduced automatically to equivalent deterministic models; see Brüggemann-Klein 1991 [Brüggemann-Klein] The XML encoding declaration functions as an internal label on each entity, indicating which character encoding is in use. Before an XML processor can read the internal label, however, it apparently has to know what character encoding is in use — which is what the internal label is trying to indicate. In the general case, this is a hopeless situation. It is not entirely hopeless in XML, however, because XML limits the general case in two ways: each implementation is assumed to support only a finite set of character encodings, and the XML encoding declaration is restricted in position and content in order to make it feasible to autodetect the character encoding in use in each entity in normal cases. Also, in many cases other sources of information are available in addition to the XML data stream itself. Two cases may be distinguished, depending on whether the XML entity is presented to the processor without, or with, any accompanying (external) information. We consider the first case first. Because each XML entity not accompanied by external encoding information and not in UTF-8 or UTF-16 encoding must begin with an XML encoding declaration, in which the first characters must be ' <?xml #x0000003C #x0000003F #xFEFF ## ## With a Byte Order Mark: 00 00 FE FF UCS-4, big-endian machine (1234 order) FF FE 00 00 UCS-4, little-endian machine (4321 order) 00 00 FF FE UCS-4, unusual octet order (2143) FE FF 00 00 UCS-4, unusual octet order (3412) FE FF ## ## UTF-16, big-endian FF FE ## ## UTF-16, little-endian EF BB BF UTF-8 Without a Byte Order Mark: 00 00 00 3C UCS-4 or other encoding with a 32-bit code unit and ASCII characters encoded as ASCII values, in respectively big-endian (1234), little-endian (4321) and two unusual byte orders (2143 and 3412). The encoding declaration must be read to determine which of UCS-4 or other supported 32-bit encodings applies. 3C 00 00 00 00 00 3C 00 00 3C 00 00 00 3C 00 3F UTF-16BE or big-endian ISO-10646-UCS-2 or other encoding with a 16-bit code unit in big-endian order and ASCII characters encoded as ASCII values (the encoding declaration must be read to determine which) 3C 00 3F 00 UTF-16LE or little-endian ISO-10646-UCS-2 or other encoding with a 16-bit code unit in little-endian order and ASCII characters encoded as ASCII values (the encoding declaration must be read to determine which) 3C 3F 78 6D UTF-8, ISO 646, ASCII, some part of ISO 8859, Shift-JIS, EUC, or any other 7-bit, 8-bit, or mixed-width encoding which ensures that the characters of ASCII have their normal positions, width, and values; the actual encoding declaration must be read to detect which of these applies, but since all of these encodings use the same bit patterns for the relevant ASCII characters, the encoding declaration itself may be read reliably 4C 6F A7 94 EBCDIC (in some flavor; the full encoding declaration must be read to tell which code page is in use) Other UTF-8 without an encoding declaration, or else the data stream is mislabeled (lacking a required encoding declaration), corrupt, fragmentary, or enclosed in a wrapper of some kind Note: In cases above which do not require reading the encoding declaration to determine the encoding, section 4.3.3 still requires that the encoding declaration, if present, be read and that the encoding name be checked to match the actual encoding of the entity. Also, it is possible that new character encodings will be invented that will make it necessary to use the encoding declaration to determine the encoding, in cases where this is not required at present. This level of autodetection is enough to read the XML encoding declaration and parse the character-encoding identifier, which is still necessary to distinguish the individual members of each family of encodings (e.g. to tell UTF-8 from 8859, and the parts of 8859 from each other, or to distinguish the specific EBCDIC code page in use, and so on). Because the contents of the encoding declaration are restricted to characters from the ASCII repertoire (however encoded), a processor can reliably read the entire encoding declaration as soon as it has detected which family of encodings is in use. Since in practice, all widely used character encodings fall into one of the categories above, the XML encoding declaration allows reasonably reliable in-band labeling of character encodings, even when external sources of information at the operating-system or transport-protocol level are unreliable. Character encodings such as UTF-7 that make overloaded usage of ASCII-valued bytes may fail to be reliably detected. Once the processor has detected the character encoding in use, it can act appropriately, whether by invoking a separate input routine for each case, or by calling the proper conversion function on each character of input. Like any self-labeling system, the XML encoding declaration will not work if any software changes the entity's character set or encoding without updating the encoding declaration. Implementors of character-encoding routines should be careful to ensure the accuracy of the internal and external information used to label the entity. The second possible case occurs when the XML entity is accompanied by encoding information, as in some file systems and some network protocols. When multiple sources of information are available, their relative priority and the preferred method of handling conflict should be specified as part of the higher-level protocol used to deliver XML. In particular, please refer to [IETF RFC 3023] text/xml application/xml If an XML entity is in a file, the Byte-Order Mark and encoding declaration are used (if present) to determine the character encoding. This specification was prepared and approved for publication by the W3C XML Working Group (WG). WG approval of this specification does not necessarily imply that all WG participants voted for its approval. The current and former members in the XML WG are: Jon Bosak, Sun ( Chair James Clark ( Technical Lead Tim Bray, Textuality and Netscape ( XML Co-editor Jean Paoli, Microsoft ( XML Co-editor C. M. Sperberg-McQueen, U. of Ill. ( XML Co-editor Dan Connolly, W3C ( W3C Liaison Paula Angerstein, Texcel Steve DeRose, INSO Dave Hollander, HP Eliot Kimber, ISOGEN Eve Maler, ArborText Tom Magliery, NCSA Murray Maloney, SoftQuad, Grif SA, Muzmo and Veo Systems MURATA Makoto (FAMILY Given), Fuji Xerox Information Systems Joel Nava, Adobe Conleth O'Connell, Vignette Peter Sharpe, SoftQuad John Tigue, DataChannel The second Leonid Arbouzov, Sun Microsystems John Cowan Andrew Fang, PTC-Arbortext Paul Grosso, PTC-Arbortext ( Co-Chair Konrad Lanz, A-SIT Philippe Le Hégaret, W3C ( Staff Contact Glenn Marcy, IBM Sandra Martinez, NIST Ravindrakumar R, CDAC Lew Shannon Henry Thompson, W3C ( Staff Contact Richard Tobin, University of Edinburgh Daniel Veillard Norman Walsh, Sun Microsystems ( Co-Chair François Yergeau This edition was encoded in a slightly modified version of the XMLspec DTD, 2.10 xmlspec.xsl diffspec.xsl REC-xml.xsl The following suggestions define what is believed to be best practice in the construction of XML names used as element names, attribute names, processing instruction targets, entity names, notation names, and the values of attributes of type ID, and are intended as guidance for document authors and schema designers. All references to Unicode are understood with respect to a particular version of the Unicode Standard greater than or equal to 3.0; which version should be used is left to the discretion of the document author or schema designer. The first two suggestions are directly derived from the rules given for identifiers in the Unicode Standard, version 3.0, and exclude all control characters, enclosing nonspacing marks, non-decimal numbers, private-use characters, punctuation characters (with the noted exceptions), symbol characters, unassigned codepoints, and white space characters. The other suggestions are mostly derived from [XML-1.0] The first character of any name should have a Unicode General Category of Ll, Lu, Lo, Lm, Lt, or Nl, or else be '_' #x5F. Characters other than the first should have a Unicode General Category of Ll, Lu, Lo, Lm, Lt, Mc, Mn, Nl, Nd, Pc, or Cf, or else be one of the following: '-' #x2D, '.' #x2E, ':' #x3A or '·' #xB7 (middle dot). Since Cf characters are not directly visible, they should be employed with caution and only when necessary, to avoid creating names which are distinct to XML processors but look the same to human beings. Ideographic characters which have a canonical decomposition (including those in the ranges [#xF900-#xFAFF] and [#x2F800-#x2FFFD], with 12 exceptions) should not be used in names. Characters which have a compatibility decomposition (those with a "compatibility formatting tag" in field 5 of the Unicode Character Database -- marked by field 5 beginning with a "<") should not be used in names. This suggestion does not apply to #x0E33 THAI CHARACTER SARA AM or #x0EB3 LAO CHARACTER AM, which despite their compatibility decompositions are in regular use in those scripts. Combining characters meant for use with symbols only (including those in the ranges [#x20D0-#x20EF] and [#x1D165-#x1D1AD]) should not be used in names. The interlinear annotation characters ([#xFFF9-#xFFFB ] Variation selector characters should not be used in names. Names which are nonsensical, unpronounceable, hard to read, or easily confusable with other names should not be employed.