1.1 Origin and Goals

XML was developed by an XML Working Group (originally known as the SGMLEditorial 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 activeparticipation of an XML Special Interest Group (previously known as the SGMLWorking Group) also organized by the W3C. The membership of the XML WorkingGroup is given in an appendix. Dan Connolly served as the Working Group's contact withthe W3C.

The design goals for XML are:

1. XML shall be straightforwardly usable over the Internet.

2. XML shall support a wide variety of applications.

3. XML shall be compatible with SGML.

4. It shall be easy to write programs which process XML documents.

5. The number of optional features in XML is to be kept to the absoluteminimum, ideally zero.

6. XML documents should be human-legible and reasonably clear.

7. The XML design should be prepared quickly.

8. The design of XML shall be formal and concise.

9. XML documents shall be easy to create.

10. Terseness in XML markup is of minimal importance.

This specification, together with associated standards (Unicode[Unicode]and ISO/IEC 10646[ISO/IEC 10646] for characters, InternetBCP 47[IETF BCP 47]and the Language Subtag Registry[IANA-LANGCODES] for languageidentification tags), providesall the information necessary to understand XML Version 1.0 andconstruct computer programs to process it.

This version of the XML specification may be distributed freely, as long asall text and legal notices remain intact.

1.2 Terminology

The terminology used to describe XML documents is defined in the body ofthis specification. The key wordsMUST,MUST NOT,REQUIRED,SHALL,SHALL NOT,SHOULD,SHOULD NOT,RECOMMENDED,MAY, andOPTIONAL, whenEMPHASIZED,are to be interpreted as described in[IETF RFC 2119]. In addition, the terms definedin the following list are used in buildingthose definitions and in describing the actions of an XML processor:

error

[Definition: A violation of the rules of this specification;results are undefined. Unless otherwise specified, failure to observe a prescription of this specification indicated by one of the keywordsMUST,REQUIRED,MUST NOT,SHALL andSHALL NOT is an error. Conforming softwareMAY detect and report an errorandMAY recover from it.]

fatal error

[Definition: An error which a conformingXML processorMUST detect and report to the application.After encountering a fatal error, the processorMAY continue processing thedata to search for further errors andMAY report such errors to the application.In order to support correction of errors, the processorMAY make unprocesseddata from the document (with intermingled character data and markup) availableto the application. Once a fatal error is detected, however, the processorMUST NOT continue normal processing (i.e., itMUST NOT continue to pass characterdata and information about the document's logical structure to the applicationin the normal way).]

at user option

[Definition: Conforming softwareMAY orMUST (depending on the modal verb in the sentence) behave as described;if it does, itMUST provide users a means to enable or disable the behaviordescribed.]

validity constraint

[Definition: A rule which applies toallvalid XML documents. Violations of validityconstraints are errors; theyMUST, at user option, be reported byvalidating XML processors.]

well-formedness constraint

[Definition: A rule which appliesto allwell-formed XML documents. Violationsof well-formedness constraints arefatal errors.]

match

[Definition: (Of strings or names:) Two stringsor names being compared are identical. Characters with multiple possiblerepresentations in ISO/IEC 10646 (e.g. characters with both precomposed andbase+diacritic forms) match only if they have the same representation in bothstrings. Nocase folding is performed. (Of strings and rules in the grammar:) A stringmatches a grammatical production if it belongs to the language generated bythat production. (Of content and content models:) An element matches its declarationwhen it conforms in the fashion described in the constraint[VC:Element Valid].]

for compatibility

[Definition: Marksa sentence describing a feature of XML included solely to ensurethat XML remains compatible with SGML.]

for interoperability

[Definition: Marksa sentence describing a non-binding recommendation included to increasethe chances that XML documents can be processed by the existing installedbase of SGML processors which predate the WebSGML Adaptations Annex to ISO 8879.]

2.1 Well-Formed XML Documents

[Definition: A textual object is awell-formedXML document if:]

1. Taken as a whole, it matches the production labeleddocument.

2. It meets all the well-formedness constraints given in this specification.

3. Each of theparsed entitieswhich is referenced directly or indirectly within the document iswell-formed.

Document

Matching thedocument production implies that:

1. It contains one or moreelements.

2. [Definition: There is exactly one element,called theroot, or document element, no part of which appearsin thecontent of any other element.] Forall other elements, if thestart-tag is inthe content of another element, theend-tagis in the content of the same element. More simply stated, the elements,delimited by start- and end-tags, nest properly within each other.

[Definition: As a consequence of this,for each non-root elementC in the document, there is one other elementPin the document such thatC is in the content ofP, butis not in the content of any other element that is in the content ofP.Pis referred to as theparent ofC, andC asachild ofP.]

2.2 Characters

[Definition: A parsed entity containstext,a sequence ofcharacters, which mayrepresent markup or character data.][Definition: Acharacteris an atomic unit of text as specified by ISO/IEC 10646:2000[ISO/IEC 10646]. Legal characters are tab, carriagereturn, line feed, and the legal charactersof Unicode and ISO/IEC 10646. Theversions of these standards cited inA.1 Normative References werecurrent at the time this document was prepared. New characters may be addedto these standards by amendments or new editions. Consequently, XML processorsMUST accept any character in the range specified forChar.]

Character Range

The mechanism for encoding character code points into bit patterns mayvary from entity to entity. All XML processorsMUST accept the UTF-8 and UTF-16encodings of Unicode[Unicode];the mechanisms for signaling which of the two is in use,or for bringing other encodings into play, are discussed later, in4.3.3 Character Encoding in Entities.

[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF],[#x1FFFE-#x1FFFF], [#x2FFFE-#x2FFFF], [#x3FFFE-#x3FFFF],[#x4FFFE-#x4FFFF], [#x5FFFE-#x5FFFF], [#x6FFFE-#x6FFFF],[#x7FFFE-#x7FFFF], [#x8FFFE-#x8FFFF], [#x9FFFE-#x9FFFF],[#xAFFFE-#xAFFFF], [#xBFFFE-#xBFFFF], [#xCFFFE-#xCFFFF],[#xDFFFE-#xDFFFF], [#xEFFFE-#xEFFFF], [#xFFFFE-#xFFFFF],[#x10FFFE-#x10FFFF].

2.3 Common Syntactic Constructs

This section defines some symbols used widely in the grammar.

S (white space) consists of one or more space (#x20)characters, carriage returns, line feeds, or tabs.

White Space

AnNmtoken (name token) is any mixture of namecharacters.

[Definition: AName is anNmtoken with a restricted set of initial characters.] Disallowed initial characters forNames include digits, diacritics, the full stop and the hyphen.

Names beginning with the string "xml",or with any string which would match(('X'|'x') ('M'|'m') ('L'|'l')),are reserved for standardization in this or future versions of this specification.

The first character of aNameMUST be aNameStartChar, and anyother charactersMUST beNameChars; this mechanism is used toprevent names from beginning with European (ASCII) digits or withbasic combining characters. Almost all characters are permitted innames, except those which either are or reasonably could be used asdelimiters. The intention is to be inclusive rather than exclusive,so that writing systems not yet encoded in Unicode can be used inXML names. SeeJ Suggestions for XML Names for suggestions on the creation ofnames.

Document authors are encouraged to use names which aremeaningful words or combinations of words in natural languages, andto avoid symbolic or white space characters in names. Note thatCOLON, HYPHEN-MINUS, FULL STOP (period), LOW LINE (underscore), andMIDDLE DOT are explicitly permitted.

The ASCII symbols and punctuation marks, along with a fairlylarge group of Unicode symbol characters, are excluded from namesbecause they are more useful as delimiters in contexts where XMLnames are used outside XML documents; providing this group givesthose contexts hard guarantees about whatcannot be part ofan XML name. The character #x037E, GREEK QUESTION MARK, is excludedbecause when normalized it becomes a semicolon, which could changethe meaning of entity references.

Names and Tokens

Literal data is any quoted string not containing the quotation mark usedas a delimiter for that string. Literals are used for specifying the contentof internal entities (EntityValue), the valuesof attributes (AttValue), and external identifiers(SystemLiteral). Note that aSystemLiteralcan be parsed without scanning for markup.

Literals

2.4 Character Data and Markup

Text consists of intermingledcharacter data and markup. [Definition:Markup takes the form ofstart-tags,end-tags,empty-element tags,entity references,characterreferences,comments,CDATA section delimiters,documenttype declarations,processing instructions,XML declarations,text declarations,and any white space that is at the top level of the document entity (thatis, outside the document element and not inside any other markup).]

[Definition: All text that is not markupconstitutes thecharacter data of the document.]

The ampersand character (&) and the left angle bracket (<)MUST NOT appearin their literal form, except when used as markup delimiters, orwithin acomment, aprocessinginstruction, or aCDATA section.If they are needed elsewhere, theyMUST beescapedusing eithernumeric character referencesor the strings "&" and "<"respectively. The right angle bracket (>) may be represented using the string ">",andMUST,for compatibility, be escapedusing either ">" or a character reference when itappears in the string "]]>" in content, whenthat string is not marking the end of aCDATAsection.

In the content of elements, character data is any string of characterswhich does not contain the start-delimiter of any markup and does not include the CDATA-section-closedelimiter, "]]>". In a CDATA section,character data is any string of characters not including the CDATA-section-closedelimiter, "]]>".

To allow attribute values to contain both single and double quotes, theapostrophe or single-quote character (') may be represented as "'",and the double-quote character (") as """.

Character Data

2.5 Comments

[Definition:Comments may appearanywhere in a document outside othermarkup;in addition, they may appear within the document type declaration at placesallowed by the grammar. They are not part of the document'scharacterdata; an XML processorMAY, but need not, make it possible for anapplication to retrieve the text of comments.Forcompatibility, the string "--" (double-hyphen)MUST NOT occur within comments.] Parameterentity referencesMUST NOT be recognized within comments.

Comments

An example of a comment:

<!-- declarations for <head> & <body> -->

Notethat the grammar does not allow a comment ending in--->. Thefollowing example isnot well-formed.

<!-- B+, B, or B--->

2.6 Processing Instructions

[Definition:Processing instructions(PIs) allow documents to contain instructions for applications.]

Processing Instructions

PIs are not part of the document'scharacterdata, butMUST be passed through to the application. The PI beginswith a target (PITarget) used to identify the applicationto which the instruction is directed. The target names "XML", "xml",and so on are reserved for standardization in this or future versions of thisspecification. The XMLNotation mechanismmay be used for formal declaration of PI targets. Parameterentity referencesMUST NOT be recognized within processing instructions.

2.7 CDATA Sections

[Definition:CDATA sections may occur anywhere character data may occur; they are used to escape blocksof text containing characters which would otherwise be recognized as markup.CDATA sections begin with the string "<![CDATA["and end with the string "]]>":]

CDATA Sections

Within a CDATA section, only theCDEnd string isrecognized as markup, so that left angle brackets and ampersands may occurin their literal form; they need not (and cannot) be escaped using "<"and "&". CDATA sections cannot nest.

An example of a CDATA section, in which "<greeting>"and "</greeting>" are recognized ascharacter data, notmarkup:

<![CDATA[<greeting>Hello, world!</greeting>]]>

2.8 Prolog and Document Type Declaration

[Definition: XML documentsSHOULDbegin with anXML declaration which specifies the version ofXML being used.] For example, the following is a complete XML document,well-formed but notvalid:

<?xml version="1.0"?><greeting>Hello, world!</greeting>

and so is this:

<greeting>Hello, world!</greeting>

The function of the markup in an XML document is to describe its storage andlogical structure and to associate attributename-value pairs with its logical structures. XML provides a mechanism, thedocumenttype declaration, to define constraints on the logical structureand to support the use of predefined storage units. [Definition: An XML document isvalid if it has an associateddocument type declaration and if the document complies with the constraintsexpressed in it.]

The document type declarationMUST appear before the firstelementin the document.

Prolog

Even though theVersionNum production matchesany version number of the form '1.x', XML 1.0 documentsSHOULD NOT specify a version number other than '1.0'.

[Definition: The XMLdocumenttype declaration contains or points tomarkupdeclarations that provide a grammar for a class of documents. Thisgrammar is known as a document type definition, orDTD. The documenttype declaration can point to an external subset (a special kind ofexternal entity) containing markup declarations,or can contain the markup declarations directly in an internal subset, orcan do both. The DTD for a document consists of both subsets taken together.]

[Definition: Amarkup declarationis anelement type declaration, anattribute-list declaration, anentitydeclaration, or anotation declaration.]These declarations may be contained in whole or in part withinparameterentities, as described in the well-formedness and validity constraintsbelow. For furtherinformation, see4 Physical Structures.

Document Type Definition

Notethat it is possible to construct a well-formed document containing adoctypedeclthat neither points to an external subset nor contains an internal subset.

The markup declarations may be made up in whole or in part of thereplacement text ofparameterentities. The productions later in this specification for individualnonterminals (elementdecl,AttlistDecl,and so on) describe the declarationsafter all the parameterentities have beenincluded.

Parameterentity references are recognized anywhere in the DTD (internal and externalsubsets and external parameter entities), except in literals, processing instructions,comments, and the contents of ignored conditional sections (see3.4 Conditional Sections).They are also recognized in entity value literals. The use of parameter entitiesin the internal subset is restricted as described below.

Like the internal subset, the external subset and any external parameterentities referencedin aDeclSepMUST consist of a series ofcomplete markup declarations of the types allowed by the non-terminal symbolmarkupdecl, interspersed with white space orparameter-entity references. However, portions ofthe contents of the external subset or of theseexternal parameter entities may conditionally be ignored by using theconditional section construct; this is notallowed in the internal subset but isallowed in external parameter entities referenced in the internal subset.

External Subset

The external subset and external parameter entities also differ from theinternal subset in that in them,parameter-entityreferences are permittedwithin markup declarations,not onlybetween markup declarations.

An example of an XML document with a document type declaration:

<?xml version="1.0"?><!DOCTYPE greeting SYSTEM "hello.dtd"><greeting>Hello, world!</greeting>

Thesystem identifier"hello.dtd"gives the address (a URI reference) of a DTD for the document.

The declarations can also be given locally, as in this example:

<?xml version="1.0" encoding="UTF-8" ?><!DOCTYPE greeting [  <!ELEMENT greeting (#PCDATA)>]><greeting>Hello, world!</greeting>

If both the external and internal subsets are used, the internal subsetMUST be considered to occur before the external subset. This has the effect that entity and attribute-list declarations in the internalsubset take precedence over those in the external subset.

2.9 Standalone Document Declaration

Markup declarations can affect the content of the document, as passed fromanXML processor to an application; examplesare attribute defaults and entity declarations. The standalone document declaration,which may appear as a component of the XML declaration, signals whether ornot there are such declarations which appear external to thedocumententityor in parameter entities. [Definition: Anexternalmarkup declaration is defined as a markup declaration occurring inthe external subset or in a parameter entity (external or internal, the latterbeing included because non-validating processors are not required to readthem).]

Standalone Document Declaration

In a standalone document declaration, the value "yes" indicatesthat there are noexternal markup declarations whichaffect the information passed from the XML processor to the application. Thevalue "no" indicates that there are or may be such externalmarkup declarations. Note that the standalone document declaration only denotesthe presence of externaldeclarations; the presence, in a document,of references to externalentities, when those entities are internallydeclared, does not change its standalone status.

If there are no external markup declarations, the standalone document declarationhas no meaning. If there are external markup declarations but there is nostandalone document declaration, the value "no" is assumed.

Any XML document for whichstandalone="no" holds can be convertedalgorithmically to a standalone document, which may be desirable for somenetwork delivery applications.

An example XML declaration with a standalone document declaration:

<?xml version="1.0" standalone='yes'?>

2.10 White Space Handling

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 typicallynot intended for inclusion in the delivered version of the document. On theother hand, "significant" white space that should be preservedin the delivered version is common, for example in poetry and source code.

AnXML processorMUST always passall characters in a document that are not markup through to the application.A validating XML processorMUST alsoinform the application which of these characters constitute white space appearinginelement content.

A specialattribute namedxml:space may be attached to an element to signal an intention that in that element,white space should be preserved by applications. In valid documents, thisattribute, like any other,MUST bedeclaredif it is used. When declared, itMUST be given as anenumeratedtype whose valuesare one or both of "default" and "preserve".For example:

<!ATTLIST poem  xml:space (default|preserve) 'preserve'><!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

The value "default" signals that applications' default white-spaceprocessing modes are acceptable for this element; the value "preserve"indicates the intent that applications preserve all the white space. Thisdeclared intent is considered to apply to all elements within the contentof the element where it is specified, unless overridden withanother instance of thexml:space attribute. This specification does not give meaning to any value ofxml:space other than "default" and "preserve". It is an error for other values to be specified; the XML processorMAY report the error orMAY recover by ignoring the attribute specification or by reporting the (erroneous) value to the application. Applications may ignore or reject erroneous values.

Theroot element of any document is consideredto have signaled no intentions as regards application space handling, unlessit provides a value for this attribute or the attribute is declared with adefault value.

2.11 End-of-Line Handling

XMLparsed entities are often storedin computer files which, for editing convenience, are organized into lines.These lines are typically separated by some combination of the charactersCARRIAGE RETURN (#xD) and LINE FEED (#xA).

Tosimplify the tasks ofapplications, theXMLprocessorMUST behave as if it normalized all line breaks in external parsedentities (including the document entity) on input, before parsing, by translatingboth the two-character sequence #xD #xA and any #xD that is not followed by#xA to a single #xA character.

2.12 Language Identification

In document processing, it is often useful to identify the natural or formallanguage in which the content is written. A specialattributenamedxml:lang may be inserted in documents to specify the languageused in the contents and attribute values of any element in an XML document.In valid documents, this attribute, like any other,MUST bedeclaredif it is used. Thevalues of the attribute are language identifiers as defined by[IETF BCP 47],Tagsfor the Identification of Languages; in addition, the empty string may be specified.

(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 byxml:lang applies to the element where it is specified (including the values of its attributes), and to all elements in its content unless overridden with another instance ofxml:lang. In particular, the empty value ofxml:lang is used on an element B to override a specification ofxml:lang on an enclosing element A, without specifying another language. Within B, it is considered that there is no language information available, just as ifxml:lang had not been specified on B or any of its ancestors. 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 byxml:lang.

A simple declaration forxml:lang might take the form

xml:lang CDATA #IMPLIED

but specific default values may also be given, if appropriate. In a collectionof French poems for English students, with glosses and notes in English, thexml:langattribute might be declared this way:

<!ATTLIST poem   xml:lang CDATA 'fr'><!ATTLIST gloss  xml:lang CDATA 'en'><!ATTLIST note   xml:lang CDATA 'en'>

Well-formedness constraint: Element Type Match

TheNamein an element's end-tagMUST match the element type in the start-tag.

Validity constraint: Element Valid

An element is validif there is a declaration matchingelementdeclwhere theName matches the element type, and one ofthe following holds:

1. The declaration matchesEMPTY and the element has nocontent (not even entityreferences, comments, PIs or white space).

2. The declaration matcheschildren and thesequence ofchild elements belongsto the language generated by the regular expression in the content model,with optional white space, comments andPIs (i.e. markup matching production [27]Misc) between thestart-tag and the first child element, between child elements, or betweenthe last child element and the end-tag. Note that a CDATA section containingonly white space or a referenceto an entity whose replacement text is character references expanding to whitespace do notmatch the nonterminalS, andhence cannot appear in these positions; however, areference to an internal entity with a literal value consisting of characterreferences expanding to white space does matchS, since itsreplacement text is the white space resulting from expansion of the characterreferences.

3. The declaration matchesMixed, and the content(after replacingany entity references with their replacement text) consists ofcharacter data(includingCDATA sections),comments,PIs andchild elements whose types match names in thecontent model.

4. The declaration matchesANY, and the content (after replacingany entity references with their replacement text)consists of character data,CDATAsections,comments,PIs andchild elementswhose types have been declared.

3.1 Start-Tags, End-Tags, and Empty-Element Tags

[Definition: The beginning of every non-emptyXML element is marked by astart-tag.]

Start-tag

TheName in the start- and end-tags gives the element'stype. [Definition: TheName-AttValuepairs are referred to as theattribute specifications of theelement], [Definition: with theName in each pair referred to as theattribute name]and [Definition: the content of theAttValue (the text between the' or"delimiters) as theattribute value.] Notethat the order of attribute specifications in a start-tag or empty-elementtag is not significant.

An example of a start-tag:

<termdef term="dog">

[Definition: The end of every element that beginswith a start-tagMUST be marked by anend-tag containing a namethat echoes the element's type as given in the start-tag:]

End-tag

An example of an end-tag:

</termdef>

[Definition: Thetextbetween the start-tag and end-tag is called the element'scontent:]

Content of Elements

[Definition: An elementwith nocontent is said to beempty.] The representationof an empty element is either a start-tag immediately followed by an end-tag,or an empty-element tag. [Definition: Anempty-elementtag takes a special form:]

Tags for Empty Elements

Empty-element tags may be used for any element which has no content, whetheror not it is declared using the keywordEMPTY.Forinteroperability, the empty-element tagSHOULDbe used, andSHOULD only be used, for elements which are declaredEMPTY.

Examples of empty elements:

<IMG align="left" src="http://www.w3.org/Icons/WWW/w3c_home" /><br></br><br/>

3.2 Element Type Declarations

Theelement structure of anXML document may, forvalidationpurposes, be constrained using element type and attribute-list declarations.An element type declaration constrains the element'scontent.

Element type declarations often constrain which element types can appearaschildren of the element. At useroption, an XML processorMAY issue a warning when a declaration mentions anelement type for which no declaration is provided, but this is not an error.

[Definition: Anelementtype declaration takes the form:]

Element Type Declaration

where theName gives the element type being declared.

Examples of element type declarations:

<!ELEMENT br EMPTY><!ELEMENT p (#PCDATA|emph)* ><!ELEMENT %name.para; %content.para; ><!ELEMENT container ANY>

<!ELEMENT spec (front, body, back?)><!ELEMENT div1 (head, (p | list | note)*, div2*)><!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>

<!ELEMENT p (#PCDATA|a|ul|b|i|em)*><!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* ><!ELEMENT b (#PCDATA)>

3.3 Attribute-List Declarations

Attributes are used to associate name-valuepairs withelements. Attribute specificationsMUST NOT appear outside ofstart-tags andempty-element tags; thus, the productions used torecognize them appear in3.1 Start-Tags, End-Tags, and Empty-Element Tags. Attribute-list declarationsmay be used:

• To define the set of attributes pertaining to a given element type.

• To establish type constraints for these attributes.

• To providedefault values forattributes.

[Definition:Attribute-listdeclarations specify the name, data type, and default value (if any)of each attribute associated with a given element type:]

Attribute-list Declaration

TheName in theAttlistDeclrule is the type of an element. At user option, an XML processorMAY issuea warning if attributes are declared for an element type not itself declared,but this is not an error. TheName in theAttDefrule is the name of the attribute.

When more than oneAttlistDecl is providedfor a given element type, the contents of all those provided are merged. Whenmore than one definition is provided for the same attribute of a given elementtype, the first declaration is binding and later declarations are ignored.For interoperability, writers of DTDs may chooseto provide at most one attribute-list declaration for a given element type,at most one attribute definition for a given attribute name in an attribute-listdeclaration, and at least one attribute definition in each attribute-listdeclaration. For interoperability, an XML processorMAY at user optionissue a warning when more than one attribute-list declaration is providedfor a given element type, or more than one attribute definition is providedfor a given attribute, but this is not an error.

<!ATTLIST termdef          id      ID      #REQUIRED          name    CDATA   #IMPLIED><!ATTLIST list          type    (bullets|ordered|glossary)  "ordered"><!ATTLIST form          method  CDATA   #FIXED "POST">

<!ENTITY d "&#xD;"><!ENTITY a "&#xA;"><!ENTITY da "&#xD;&#xA;">

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

3.4 Conditional Sections

[Definition:Conditionalsections are portions of thedocument typedeclaration external subset orof external parameter entities which are included in, or excluded from,the logical structure of the DTD based on the keyword which governs them.]

Conditional Section

Like the internal and external DTD subsets, a conditional section may containone or more complete declarations, comments, processing instructions, or nestedconditional sections, intermingled with white space.

If the keyword of the conditional section isINCLUDE, then thecontents of the conditional sectionMUST be processed as part of the DTD. If the keyword ofthe conditional section isIGNORE, then the contents of the conditionalsectionMUSTNOT be processed as part of the DTD.If a conditional section with a keyword ofINCLUDE occurs withina larger conditional section with a keyword ofIGNORE, both the outerand the inner conditional sectionsMUST be ignored. The contentsof an ignored conditional sectionMUST be parsed by ignoring all characters afterthe "[" following the keyword, except conditional section starts"<![" and ends "]]>", until the matching conditionalsection end is found. Parameter entity referencesMUST NOT be recognized in thisprocess.

If the keyword of the conditional section is a parameter-entity reference,the parameter entityMUST be replaced by its content before the processordecides whether to include or ignore the conditional section.

An example:

<!ENTITY % draft 'INCLUDE' ><!ENTITY % final 'IGNORE' ><![%draft;[<!ELEMENT book (comments*, title, body, supplements?)>]]><![%final;[<!ELEMENT book (title, body, supplements?)>]]>

4.1 Character and Entity References

[Definition: Acharacterreference refers to a specific character in the ISO/IEC 10646 characterset, for example one not directly accessible from available input devices.]

Character Reference

If the character reference begins with "&#x",the digits and letters up to the terminating; provide a hexadecimalrepresentation of the character's code point in ISO/IEC 10646. If it beginsjust with "&#", the digits up to the terminating;provide a decimal representation of the character's code point.

[Definition: Anentity referencerefers to the content of a named entity.][Definition: References to parsed general entities useampersand (&) and semicolon (;) as delimiters.][Definition:Parameter-entity referencesuse percent-sign (%) and semicolon (;) as delimiters.]

Entity Reference

Examples of character and entity references:

Type <key>less-than</key> (&#x3C;) to save options.This document was prepared on &docdate; andis 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;

4.2 Entity Declarations

[Definition: Entities are declaredthus:]

Entity Declaration

TheName identifies the entity in anentityreference or, in the case of an unparsed entity, in the value ofanENTITY orENTITIES attribute. If the same entity is declaredmore than once, the first declaration encountered is binding; at user option,an XML processorMAY issue a warning if entities are declared multiple times.

<!ENTITY Pub-Status "This is a pre-release of the specification.">

<!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 >

4.3 Parsed Entities

<?xml encoding='UTF-8'?><?xml encoding='EUC-JP'?>

4.4 XML Processor Treatment of Entities and References

The table below summarizes the contexts in which character references,entity references, and invocations of unparsed entities might appear and theREQUIRED behavior of anXML processorin each case. The labels in the leftmost column describe the recognition context:

Reference in Content

as a reference anywhere after thestart-tagand before theend-tag of an element; correspondsto the nonterminalcontent.

Reference in Attribute Value

as a reference within either the value of an attribute in astart-tag,or a default value in anattribute declaration;corresponds to the nonterminalAttValue.

Occurs as Attribute Value

as aName, not a reference, appearing either asthe value of an attribute which has been declared as typeENTITY,or as one of the space-separated tokens in the value of an attribute whichhas been declared as typeENTITIES.

Reference in Entity Value

as a reference within a parameter or internal entity'sliteralentity value in the entity's declaration; corresponds to the nonterminalEntityValue.

Reference in DTD

as a reference within either the internal or external subsets of theDTD, but outside of anEntityValue,AttValue,PI,Comment,SystemLiteral,PubidLiteral,or the contents of an ignored conditional section (see3.4 Conditional Sections).

.

<!ENTITY % YN '"Yes"' ><!ENTITY WhatHeSaid "He said %YN;" >

<!ENTITY EndAttr "27'" ><element attribute='a-&EndAttr;>

4.5 Construction of Entity Replacement Text

In discussing the treatment of entities, it is useful to distinguishtwo forms of the entity's value.[Definition: For aninternal entity, theliteralentity value is the quoted string actually present in the entity declaration,corresponding to the non-terminalEntityValue.][Definition: For an external entity, theliteralentity value is the exact text contained in the entity.][Definition: For aninternal entity, thereplacement textis the content of the entity, after replacement of character references andparameter-entity references.][Definition: Foran external entity, thereplacement text is the content of the entity,after stripping the text declaration (leaving any surrounding whitespace) if thereis one but without any replacement of character references or parameter-entityreferences.]

The literal entity value as given in an internal entity declaration (EntityValue) may contain character, parameter-entity,and general-entity references. Such referencesMUST be contained entirelywithin the literal entity value. The actual replacement text that isincluded (orincluded in literal) as described aboveMUST contain thereplacementtext of any parameter entities referred to, andMUST contain the characterreferred to, in place of any character references in the literal entity value;however, general-entity referencesMUST be left as-is, unexpanded. For example,given the following declarations:

<!ENTITY % pub    "&#xc9;ditions Gallimard" ><!ENTITY   rights "All rights reserved" ><!ENTITY   book   "La Peste: Albert Camus,&#xA9; 1947 %pub;. &rights;" >

then the replacement text for the entity "book"is:

La Peste: Albert Camus,© 1947 Éditions Gallimard. &rights;

The general-entity reference "&rights;" wouldbe expanded should the reference "&book;" appearin the document's content or an attribute value.

These simple rules may have complex interactions; for a detailed discussionof a difficult example, seeD Expansion of Entity and Character References.

4.6 Predefined Entities

[Definition: Entity and character references mayboth be used toescape the left angle bracket, ampersand, andother delimiters. A set of general entities (amp,lt,gt,apos,quot) is specified forthis purpose. Numeric character references may also be used; they are expandedimmediately when recognized andMUST be treated as character data, so thenumeric character references "<" and "&" may be used to escape< and& when they occurin character data.]

All XML processorsMUST recognize these entities whether they are declaredor not.For interoperability, valid XMLdocumentsSHOULD declare these entities, like any others, before using them. Ifthe entitieslt oramp are declared, theyMUST bedeclared as internal entities whose replacement text is a character referenceto the respectivecharacter (less-than sign or ampersand) being escaped; the doubleescaping isREQUIRED for these entities so that references to them producea well-formed result. If the entitiesgt,apos,orquot are declared, theyMUST be declared as internal entitieswhose replacement text is the single character being escaped (or a characterreference to that character; the double escaping here isOPTIONAL but harmless).For example:

<!ENTITY lt     "&#38;#60;"><!ENTITY gt     "&#62;"><!ENTITY amp    "&#38;#38;"><!ENTITY apos   "&#39;"><!ENTITY quot   "&#34;">

4.7 Notation Declarations

[Definition:Notations identifyby name the format ofunparsed entities,the format of elements which bear a notation attribute, or the applicationto which aprocessing instruction is addressed.]

[Definition:Notation declarationsprovide a name for the notation, for use in entity and attribute-list declarationsand in attribute specifications, and an external identifier for the notationwhich may allow an XML processor or its client application to locate a helperapplication capable of processing data in the given notation.]

Notation Declarations

XML processorsMUST provide applications with the name and external identifier(s)of any notation declared and referred to in an attribute value, attributedefinition, or entity declaration. TheyMAY additionally resolve the externalidentifier into thesystem identifier, filename, or other information needed to allow the application to call a processorfor data in the notation described. (It is not an error, however, for XMLdocuments to declare and refer to notations for which notation-specific applicationsare not available on the system where the XML processor or application isrunning.)

4.8 Document Entity

[Definition: Thedocument entityserves as the root of the entity tree and a starting-point for anXML processor.] This specification doesnot specify how the document entity is to be located by an XML processor;unlike other entities, the document entity has no name and might well appearon a processor input stream without any identification at all.

5.1 Validating and Non-Validating Processors

ConformingXML processors fall intotwo classes: validating and non-validating.

Validating and non-validating processors alikeMUST report violations ofthis specification's well-formedness constraints in the content of thedocument entity and any otherparsedentities that they read.

[Definition:ValidatingprocessorsMUST,at user option, report violations of the constraints expressed bythe declarations in theDTD, and failuresto fulfill the validity constraints given in this specification.]To accomplish this, validating XML processorsMUST read and process the entireDTD and all external parsed entities referenced in the document.

Non-validating processors areREQUIRED to check only thedocumententity, including the entire internal DTD subset, for well-formedness. [Definition: While they are not requiredto check the document for validity, they areREQUIRED toprocessall the declarations they read in the internal DTD subset and in any parameterentity that they read, up to the first reference to a parameter entity thatthey donot read; that is to say, theyMUST use the informationin those declarations tonormalizeattribute values,include the replacementtext of internal entities, and supplydefaultattribute values.] Except whenstandalone="yes", theyMUST NOTprocessentitydeclarations orattribute-list declarationsencountered after a reference to a parameter entity that is not read, sincethe entity may have contained overriding declarations; whenstandalone="yes", processorsMUSTprocess these declarations.

Note that when processing invalid documents with a non-validatingprocessor the application may not be presented with consistentinformation. For example, several requirements for uniquenesswithin the document may not be met, including more than one elementwith the same id, duplicate declarations of elements or notationswith the same name, etc. In these cases the behavior of the parserwith respect to reporting such information to the application isundefined.

5.2 Using XML Processors

The behavior of a validating XML processor is highly predictable; it mustread every piece of a document and report all well-formedness and validityviolations. Less is required of a non-validating processor; it need not readany part of the document other than the document entity. This has two effectsthat may be important to users of XML processors:

• Certain well-formedness errors, specifically those that require readingexternal entities, may fail to be detected by a non-validating processor. Examplesinclude the constraints entitledEntity Declared,Parsed Entity, andNoRecursion, as well as some of the cases described asforbidden in4.4 XML Processor Treatment of Entities and References.

• The information passed from the processor to the application mayvary, depending on whether the processor reads parameter and external entities.For example, a non-validating processor may fail tonormalizeattribute values,include the replacementtext of internal entities, or supplydefaultattribute values, where doing so depends on having read declarationsin external or parameter entities, or in the internal subset after an unread parameter entity reference.

For maximum reliability in interoperating between different XML processors,applications which use non-validating processorsSHOULD NOT rely on any behaviorsnot required of such processors. Applications which require DTD facilities not related to validation (suchas the declaration of default attributes and internal entities that are or may be specified inexternal entities)SHOULD use validating XML processors.

symbol ::= expression

A.1 Normative References

IANA-CHARSETS

(InternetAssigned Numbers Authority)Official Names for Character Sets,ed. Keld Simonsen et al. (See http://www.iana.org/assignments/character-sets.)

IETF RFC 2119

IETF(Internet Engineering Task Force).RFC 2119: Key words for use in RFCs to Indicate Requirement Levels.Scott Bradner, 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)

IETF BCP 47

IETF (Internet Engineering Task Force).BCP 47, consisting ofRFC 4646: Tags for Identifying Languages, andRFC 4647: Matching of Language Tags,A. Phillips, M. Davis. 2006.

IETF RFC 3986

IETF (Internet Engineering Task Force).RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 2005. (See http://www.ietf.org/rfc/rfc3986.txt.)

ISO/IEC 10646

ISO (InternationalOrganization for Standardization).ISO/IEC 10646-1:2000. Informationtechnology — Universal Multiple-Octet Coded Character Set (UCS) —Part 1: Architecture and Basic Multilingual Plane andISO/IEC 10646-2:2001.Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2:Supplementary Planes, as, from time to time, amended, replaced by a new edition orexpanded by the addition of new parts. [Geneva]: International Organization for Standardization.(Seehttp://www.iso.org/iso/home.htm for the latest version.)

ISO/IEC 10646:2000

ISO (InternationalOrganization for Standardization).ISO/IEC 10646-1:2000. Informationtechnology — Universal Multiple-Octet Coded Character Set (UCS) —Part 1: Architecture and Basic Multilingual Plane. [Geneva]: InternationalOrganization for Standardization, 2000.

Unicode

The Unicode Consortium.The UnicodeStandard, Version5.0.0,defined by: The Unicode Standard, Version 5.0 (Boston, MA,Addison-Wesley, 2007. ISBN 0-321-48091-0).

UnicodeNormal

The UnicodeConsortium.Unicode normalization forms. Mark Davis andMartin Durst. 2008. (See http://unicode.org/reports/tr15/.)

A.2 Other References

Aho/Ullman

Aho, Alfred V., Ravi Sethi, and Jeffrey D.Ullman.Compilers: Principles, Techniques, and Tools.Reading: Addison-Wesley, 1986, rpt. corr. 1988.

Brüggemann-Klein

Brüggemann-Klein,Anne.Formal Models in Document Processing. Habilitationsschrift. Facultyof Mathematics at the University of Freiburg, 1993. (See ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)

Brüggemann-Klein and Wood

Brüggemann-Klein,Anne, and Derick Wood.Deterministic Regular Languages.Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991. Extendedabstract in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag,Berlin 1992. Lecture Notes in Computer Science 577. Full version titledOne-UnambiguousRegular Languages in Information and Computation 140 (2): 229-253,February 1998.

Clark

James Clark.Comparison of SGML and XML. (See http://www.w3.org/TR/NOTE-sgml-xml-971215.)

IANA-LANGCODES

(InternetAssigned Numbers Authority)Registry of Language Tags (See http://www.iana.org/assignments/language-subtag-registry.)

IETF RFC 2141

IETF(Internet Engineering Task Force).RFC 2141: URN Syntax, ed.R. Moats. 1997. (See http://www.ietf.org/rfc/rfc2141.txt.)

IETF RFC 3023

IETF(Internet Engineering Task Force).RFC 3023: XML Media Types.eds. M. Murata, S. St.Laurent, D. Kohn. 2001. (See http://www.ietf.org/rfc/rfc3023.txt.)

IETF RFC 2781

IETF(Internet Engineering Task Force).RFC 2781: UTF-16, an encodingof ISO 10646, ed. P. Hoffman, F. Yergeau. 2000. (See http://www.ietf.org/rfc/rfc2781.txt.)

ISO 639

(International Organization for Standardization).ISO 639:1988 (E).Code for the representation of names of languages. [Geneva]: InternationalOrganization for Standardization, 1988.

ISO 3166

(International Organization for Standardization).ISO 3166-1:1997(E). Codes for the representation of names of countries and their subdivisions —Part 1: Country codes [Geneva]: International Organization forStandardization, 1997.

ISO 8879

ISO (International Organization for Standardization).ISO8879:1986(E). Information processing — Text and Office Systems —Standard Generalized Markup Language (SGML). First edition —1986-10-15. [Geneva]: International Organization for Standardization, 1986.

ISO/IEC 10744

ISO (International Organization forStandardization).ISO/IEC 10744-1992 (E). Information technology —Hypermedia/Time-based Structuring Language (HyTime). [Geneva]:International Organization for Standardization, 1992.Extended FacilitiesAnnexe. [Geneva]: International Organization for Standardization, 1996.

WEBSGML

ISO(International Organization for Standardization).ISO 8879:1986TC2. Information technology — Document Description and Processing Languages.[Geneva]: International Organization for Standardization, 1998. (See http://www.sgmlsource.com/8879/n0029.htm.)

XML Names

Tim Bray,Dave Hollander, and Andrew Layman, editors.Namespaces in XML.Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (See http://www.w3.org/TR/xml-names/.)

<!ENTITY example "<p>An ampersand (&#38;#38;) may be escapednumerically (&#38;#38;#38;) or with a general entity(&amp;amp;).</p>" >

<p>An ampersand (&#38;) may be escapednumerically (&#38;#38;) or with a general entity(&amp;amp;).</p>

An ampersand (&) may be escapednumerically (&) or with a general entity(&).

1 <?xml version='1.0'?>2 <!DOCTYPE test [3 <!ELEMENT test (#PCDATA) >4 <!ENTITY % xx '&#37;zz;'>5 <!ENTITY % zz '&#60;!ENTITY tricky "error-prone" >' >6 %xx;7 ]>8 <test>This sample shows a &tricky; method.</test>

<!DOCTYPE foo [ <!ENTITY x "&lt;"> ]> <foo attr="&x;"/>

<!ENTITY x "&#60;">

F.1 Detection Without External Encoding Information

Because each XML entity not accompanied by externalencoding information and not in UTF-8 or UTF-16 encoding mustbegin with an XML encoding declaration, in which the first characters mustbe '<?xml', any conforming processor can detect, after twoto four octets of input, which of the following cases apply. In reading thislist, it may help to know that in UCS-4, '<' is "#x0000003C"and '?' is "#x0000003F", and the Byte Order Markrequired of UTF-16 data streams is "#xFEFF". The notation## is used to denote any byte value except that two consecutive##s cannot be both 00.

With a Byte Order Mark:

Without a Byte Order Mark:

This level of autodetection is enough to read the XML encoding declarationand parse the character-encoding identifier, which is still necessary to distinguishthe individual members of each family of encodings (e.g. to tell UTF-8 from8859, and the parts of 8859 from each other, or to distinguish the specificEBCDIC code page in use, and so on).

Because the contents of the encoding declaration are restricted to charactersfrom the ASCII repertoire (however encoded),a processor can reliably read the entire encoding declaration as soon as ithas detected which family of encodings is in use. Since in practice, all widelyused character encodings fall into one of the categories above, the XML encodingdeclaration allows reasonably reliable in-band labeling of character encodings,even when external sources of information at the operating-system or transport-protocollevel are unreliable. Character encodings such as UTF-7that 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 actappropriately, 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 workif any software changes the entity's character set or encoding without updatingthe encoding declaration. Implementors of character-encoding routines shouldbe careful to ensure the accuracy of the internal and external informationused to label the entity.

F.2 Priorities in the Presence of External Encoding Information

The second possible case occurs when the XML entity is accompanied by encodinginformation, as in some file systems and some network protocols. When multiplesources of information are available, their relative priority and the preferredmethod of handling conflict should be specified as part of the higher-levelprotocol used to deliver XML. In particular, please referto[IETF RFC 3023] or its successor, which defines thetext/xmlandapplication/xml MIME types and provides some useful guidance.In the interests of interoperability, however, the following rule is recommended.

• If an XML entity is in a file, the Byte-Order Mark and encoding declaration are used(if present) to determine the character encoding.