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 and chaired by Jon Bosak of Sun Microsystems with the very 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 WG's contact with the W3C.

The design goals for XML are:

XML shall be straightforwardly usable over the Internet.

This specification, together with the associated standards, provides all the information necessary to understand XML version &XML.version; and construct computer programs to process it.

This version of the XML specification (&doc.date;) is for &doc.audience;. It &doc.distribution;.

Standards relevant to users and implementors of XML include:

SGML (ISO 8879:1986). By definition, valid XML documents are conformant SGML documents in the sense described in ISO standard 8879. The current draft of this specification presupposes the successful completion of the current work on a technical corrigendum to ISO 8879 now being prepared by ISO/IEC JTC1/SC18/WG8. If the corrigendum is not adopted in the expected form, some clauses of this specification may change, and some recommendations now labeled for interoperability will become requirements labeled for compatibility.

Some terms used with special meaning in this specification are: may

Conforming data and XML processors are permitted to but need not behave as described.

The formal grammar of XML is given 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 defined by a regular expression, or with an initial lowercase letter if a recursive grammar is required for recognition. Literal strings are quoted; unless otherwise noted they are case-insensitive. The distinction between symbols which can and cannot be recognized using simple regular expressions may be used to set the boundary between an implementation's lexical scanner and its parser, but this specification neither constrains the placement of that boundary nor presupposes that all implementations will have one.

Within the expression on the right-hand side of a rule, the meaning of symbols is as shown below. #xN

where N is a hexadecimal integer, the expression represents the character in ISO/IEC 10646 whose canonical (UCS-4) bit string, when interpreted as an unsigned binary number, has the value indicated. The number of leading zeroes in the #xN form is insignificant; the number of leading zeroes in the corresponding bit string is governed by the character encoding in use and is not significant for XML.

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. S (#x20 | #x9 | #xd | #xa)+

Legal characters are tab, carriage return, line feed, and the legal graphic characters of Unicode and ISO/IEC 10646. Char #x9 | #xA | #xD | [#x20-#xFFFD] | [#x00010000-#x7FFFFFFF] any ISO/IEC 10646 UCS-4 code, FFFE and FFFF excluded Characters are classified for convenience as letters, digits, or other characters. Letters consist of an alphabetic or syllabic base character possibly followed by one or more combining characters, or of an ideographic character. Certain layout and format-control characters defined by ISO/IEC 10646 should be ignored when recognizing identifiers; these are defined by the classes Ignorable and Extender. Full definitions of the specific characters in each class are given in the appendix on character classes.

A Name is a token beginning with a letter or underscore character and continuing with letters, digits, hyphens, underscores, or full stops (together known as name characters). Names beginning with the string XML are reserved for standardization in this or future versions of this specification.

Note: the colon character is also allowed within XML names; it is reserved for experimentation with name spaces and schema scoping. Its meaning is expected to be standardized at some future point, at which point those documents using colon for experimental purposes will need to be updated. (Note: there is no guarantee that any name-space mechanism adopted for XML will in fact use colon as a name-space delimiter.) In practice, this means that authors should not use colon in XML names except as part of name-space experiments, but that implementors should accept colon as a name character.

An Nmtoken (name token) is any mixture of name characters. MiscName '.' | '-' | '_' | ':' | CombiningChar | Ignorable | Extender NameChar Letter | Digit | MiscName Name (Letter | '_' | ':') (NameChar)* Names Name (S Name)* Nmtoken (NameChar)+ Nmtokens Nmtoken (S Nmtoken)*

Literal data is any quoted string not containing the quotation mark used as a delimiter for that string; different forms of literal data may or may not contain angle brackets, entity references, and character references. Literals are used for specifying the replacement text of internal entities (EntityValue), the values of attributes (AttValue), and external identifiers (SystemLiteral); for some purposes, the entire literal can be skipped without scanning for markup within it (SkipLit): EntityValue '"' ([^%&"] | PEReference | Reference)* '"' |  "'" ([^%&'] | PEReference | Reference)* "'" AttValue '"' ([^<&"] | Reference)* '"' |  "'" ([^<&'] | Reference)* "'" SystemLiteral '"' URLchar* '"' | "'" (URLchar - "'")* "'" URLchar See RFC 1738 and 1808 PubidLiteral '"' PubidChar* '"' | "'" (PubidChar - "'")* "'" PubidChar #x20 | #x9 | #xd | #xa | #x&IDEOSPACE; | [a-zA-Z0-9] | [-'()+,./:=?] SkipLit ('"' [^"]* '"') | ("'" [^']* "'") Note that entity references and character references are recognized and processed within EntityValue and AttValue, but not within SystemLiteral.

Each XML document has both a logical and a physical structure.

Physically, the document is composed of units called entities. An entity may refer to other entities to cause their inclusion in the document. A document begins in a "root" or document entity.

The logical structure contains declarations, elements, comments, character references, and processing instructions, all of which are indicated in the document by explicit markup.

The two structures must be synchronous: see section 4.1.

A textual object is said to be a well-formed XML document if, first, it matches the production labeled document, and if for each entity reference which appears in the document, either the entity has been declared in the document type declaration or the entity name is one of: &magicents;.

Matching the document production implies that:

It contains one or more elements.

As a consequence of this, for each non-root element C in the document, there is one other element P in the document such that C is in the content of P, but is not in the content of any other element that is in the content of P. Then P is referred to as the parent of C, and C as a child of P.

The data stored in an XML entity is either text or binary. Binary data has an associated notation, identified by name; beyond a requirement to make available the notation's name and the associated system identifier, XML places no constraints on the contents or use of binary entities. So-called binary data might in fact be textual; its identification as binary means that an XML processor need not parse it in the fashion described by this specification. XML text data is a sequence of characters. A character is an atomic unit of text; valid characters are specified by ISO/IEC 10646. Users may extend the ISO/IEC 10646 character repertoire by exploiting the private use areas.

The mechanism for encoding character values into bit patterns may vary from entity to entity. All XML processors must accept the UTF-8 and UCS-2 encodings of 10646; the mechanisms for signaling which of the two are in use, or for bringing other encodings into play, are discussed later, in the discussion of character encodings.

Regardless of the specific encoding used, any character in the ISO/IEC 10646 character set may be referred to by the decimal or hexadecimal equivalent of its bit string.

XML text consists of intermingled character data and markup. Markup takes the form of start-tags, end-tags, empty elements, entity references, character references, comments, CDATA sections, document type declarations, and processing instructions.

All text that is not markup constitutes the character data of the document.

The ampersand character (&) and the left angle bracket (<) may appear in their literal form only when used as markup delimiters, or within comments, processing instructions, or CDATA sections. If they are needed elsewhere, they must be escaped using either numeric character references or the strings "&" and "<". The right angle bracket (>) may be represented using the string ">", and must, for compatibility, be so represented when it appears in the string "]]>", when that string is not marking the end of a CDATA section.

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

To allow attribute values to contain both single and double quotes, the apostrophe or single-quote character (') may be represented as "'", and the double-quote character (") as """. PCData [^<&]*

Comments may appear anywhere except in a CDATA section, i.e. within element content, in mixed content, or in a DTD. They must not occur within declarations or tags. They are not part of the document's character data; an XML processor may, but need not, make it possible for an application to retrieve the text of comments. For compatibility, the string -- (double-hyphen) must not occur within comments. Comment '<!&como;' (Char* - (Char* '&comc;' Char*)) '&comc;>'

An example of a comment: <!&como; declarations for <head> & <body> &comc;>

Processing instructions (PIs) allow documents to contain instructions for applications. PI '<?' Name S (Char* - (Char* &pic; Char*)) &pic; PIs are not part of the document's character data, but must be passed through to the application. The Name is called the PI target; it is used to identify the application to which the instruction is directed. XML provides an optional mechanism, NOTATION, for formal declaration of such names. PI targets with names beginning with the string "XML" are reserved for standardization in this or future versions of this specification.

CDATA sections can occur anywhere character data may occur; they are used to escape blocks of text containing characters which would otherwise be recognized as markup. CDATA sections begin with the string <![CDATA[ and end with the string ]]>: CDSect CDStart CData CDEnd CDStart '<![CDATA[' CData (Char* - (Char* ']]>' Char*)) CDEnd ']]>' Within a CDATA section, only the CDEnd string is recognized, so that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using < and &. CDATA sections cannot nest.

An example of a CDATA section: <![CDATA[<greeting>Hello, world!</greeting>]]>

In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines, denoted by the nonterminal S in this specification) 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 must be retained in the delivered version is common, for example in poetry and source code.

An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must distinguish white space in element content from other non-markup characters and signal to the application that white space in element content is not significant.

A special attribute may be inserted in documents to signal an intention that the element to which this attribute applies requires all white space to be treated as significant by applications.

In valid documents, this attribute must be declared as follows, if used:

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 this element, unless overriden with another instance of the XML-SPACE attribute.

The root element of any document is considered to have signaled no intentions as regards application space handling, unless it provides a value for this attribute or the attribute is declared with a default value.

XML documents may, and should, begin with an XML declaration which specifies, among other things, the version of XML being used.

The function of the markup in an XML document is to describe its storage and logical structures, and associate attribute-value pairs with the logical structure. XML provides a mechanism, the document type declaration, to define constraints on that logical structure and to support the use of predefined storage units. An XML document is said to be valid if there is an associated document type declaration and if the document complies with the constraints expressed in it.

The document type declaration must appear before the first start-tag in the document. document prolog element Misc* prolog XMLDecl? Misc* (doctypedecl Misc*)? XMLDecl &xmlpio; VersionInfo EncodingDecl? RMDecl? S? &pic; VersionInfo S 'version' Eq ('"&XML.version;"' | "'&XML.version;'") Misc Comment | PI | S

The identification of the XML version as "1.0" does not indicate a commitment to produce any future versions of XML, nor if any are produced, to use any particular numbering scheme. Since future versions are not ruled out, this construct is provided as a means to allow the possibility of automatic version recognition, should it become necessary.

For example, the following is a complete XML document, well-formed but not valid: Hello, world! ]]> and so is this: Hello, world! ]]>

The XML document type declaration may include a pointer to an external entity containing a subset of the necessary markup declarations, and may also directly include another, internal, subset.

These two subsets make up the document type definition, abbreviated DTD. The DTD, in effect, provides a grammar which defines a class of documents. Properly speaking, the DTD consists of both subsets taken together, but it is a common practice for the bulk of the markup declarations to appear in the external subset, and for this subset, usually contained in a file, to be referred to as "the DTD" for a class of documents. doctypedecl '<!DOCTYPE' S Name (S ExternalID)? S? ('[' %markupdecl* ']' S?)? '>' Root Element Type Non-null DTD markupdecl ( %elementdecl | %AttlistDecl | %EntityDecl | %NotationDecl | %PI | %S | %Comment | InternalPERef )* InternalPERef PEReference Integral Declarations The Name in the document-type declaration must match the element type of the root element. The internal and external subsets of the DTD must not both be empty. A parameter-entity reference recognized in this context must have replacement text consisting of zero or more complete declarations, i.e. matching the production for the non-terminal markupdecl.

The external subset must obey substantially the same grammatical constraints as the internal subset; i.e. it must match the production for the non-terminal symbol markupdecl. In the external subset, however, parameter-entity references can be used to replace constructs prefixed by % in a production of the grammar, and conditional sections may occur. In the internal subset, by contrast, conditional sections may not occur and the only parameter-entity references allowed are those which match the non-terminal InternalPERef within the rule for markupdecl. extSubset ( %markupdecl | %conditionalSect )*

For example: Hello, world! ]]> The system identifier hello.dtd indicates the location of a DTD for the document.

The declarations can also be given locally, as in this example: ]> Hello, world! ]]>

If both the external and internal subsets are used, an XML processor must read the internal subset first, then the external subset. This has the effect that entity and attribute declarations in the internal subset take precedence over those in the external subset.

In some cases, an XML processor can read an XML document and accomplish useful tasks without having first processed the entire DTD. However, certain declarations can substantially affect the actions of an XML processor. It is desirable, therefore, to be able to specify whether a document contains any such declarations. A document author can communicate whether or not DTD processing is necessary using a required markup declaration (abbreviated RMD), which appears as a component of the XML declaration: RMDecl S 'RMD' Eq "'" ('NONE' | 'INTERNAL' | 'ALL') "'" | S 'RMD' Eq '"' ('NONE' | 'INTERNAL' | 'ALL') '"'

In an RMD, the value NONE indicates that an XML processor can parse the containing document correctly without first reading any part of the DTD. The value INTERNAL indicates that the XML processor must read and process the internal subset of the DTD, if provided, to parse the containing document correctly. The value ALL indicates that the XML processor must read and process the declarations in both the subsets of the DTD, if provided, to parse the containing document correctly.

The RMD must indicate that the entire DTD is required if the external subset contains any declarations of

attributes with default values, if elements to which these attributes apply appear in the document without specifying values for these attributes, or

If no RMD is provided, an XML processor must behave as though an RMD had been provided with the value ALL.

An example XML declaration with an RMD:<?XML version="&XML.version;" RMD='INTERNAL'?>

The beginning of every non-empty XML element is marked by a start-tag. STag '<' Name (S Attribute)* S? '>' Unique Att Spec Attribute Name Eq AttValue Attribute Value Type No External Entity References Eq S? '=' S? The Name in the start- and end-tags gives the element's type. The Name-AttValue pairs are referred to as the attribute specifications of the element, with the Name referred to as the attribute name and the content of the AttValue (the characters between the ' or " delimiters) as the attribute value.

An example of a start-tag: <termdef id="dt-dog" term="dog">

The end of every element may (for elements which are not empty, must) be marked by an end-tag containing a name that echoes the element's type as given in the start-tag: ETag '</' Name S? '>'

An example of an end-tag:</termdef>

The text between the start-tag and end-tag is called the element's content: content (element | PCData | Reference | CDSect | PI | Comment)* Content element EmptyElement | STag content ETagGI Match

If an element is empty, it may be represented either by a start-tag immediately followed by an end-tag, or by an empty-element tag. An Empty-element tag takes a special form: EmptyElement '<' Name (S Attribute)* S? '/>' Unique Att Spec

Empty-element tags may be used for any element which has no content, whether or not they are declared using the keyword EMPTY.

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

The element structure of an XML document may, for validation purposes, be constrained using element and attribute declarations.

An element declaration constrains the element's type and its content.

Element declarations often constrain which element types can appear as children of the element. At user option, an XML processor may issue a warning when a reference is made to an element type for which no declaration is provided, but this is not an error.

An element declaration takes the form: elementdecl '<!ELEMENT' S %Name S (%S S)? %contentspec S? '>' Unique Element Declaration contentspec 'EMPTY' | 'ANY' | Mixed | elements where the Name gives the type of the element.

An element can declared using a content model, in which case its content can be categorized as element content or mixed content, as explained below.

An element declared using the keyword EMPTY must be empty and may be tagged using an empty-element tag when it appears in the document.

If an element type is declared using the keyword ANY, then there are no validity constraints on its content: it may contain child elements of any type and number, interspersed with character data.

Examples of element declarations: <!ELEMENT br EMPTY> <!ELEMENT %name.para; %content.para; > <!ELEMENT container ANY>

Attributes are used to associate name-value pairs with elements. Attributes may appear only within start-tags; thus, the productions used to recognize them appear in the discussion of start-tags. Attribute-list declarations may be used:

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

Attribute-list declarations specify the name, data type, and default value (if any) of each attribute associated with a given element type: AttlistDecl '<!ATTLIST' S %Name S? %AttDef+ S? '>' AttDef S %Name S %AttType S %Default The Name in the AttlistDecl rule is the type of an element. At user option, an XML processor may issue a warning if attributes are declared for an element type not itself declared, but this is not an error. The Name in the AttDef rule is the name of the attribute.

When more than one AttlistDecl is provided for a given element type, the contents of all those provided are merged. When more than one definition is provided for the same attribute of a given element type, the first declaration is binding and later declarations are ignored. For interoperability, writers of DTDs may choose to provide at most one attribute-list declaration for a given element type, and at most one attribute definition for a given attribute name. For interoperability, an XML processor may at user option issue a warning when more than one attribute-list declaration is provided for a given element type, or more than one attribute definition for a given attribute, but this is not an error.

Conditional sections are portions of the document type declaration external subset which are included in, or excluded from, the logical structure of the DTD based on the keyword which governs them. conditionalSect includeSect | ignoreSect includeSect '<![' %'INCLUDE' '[' (%markupdecl*)* ']]>' ignoreSect '<![' %'IGNORE' '[' ignoreSectContents* ']]>' ignoreSectContents ((SkipLit | Comment | PI) - (Char* ']]>' Char*)) | ('<![' ignoreSectContents* ']]>') | (Char - (']' | [<'"])) | ('<!' (Char - ('-' | '[')))

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, then the conditional section is read and processed in the normal way. If the keyword is IGNORE, then the declarations within the conditional section are ignored; the processor must read the conditional section to detect nested conditional sections and ensure that the end of the outermost (ignored) conditional section is properly detected. If a conditional section with a keyword of INCLUDE occurs within a larger conditional section with a keyword of IGNORE, both the outer and the inner conditional sections are ignored.

If the keyword of the conditional section is a parameter entity reference, the parameter entity is replaced by its value before the processor decides 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?)> ]]>

The logical and physical structures (elements and entities) in an XML document must be synchronous. Tags and elements must each begin and end in the same entity, but may refer to other entities internally; comments, processing instructions, character references, and entity references must each be contained entirely within a single entity. Entities must each contain an integral number of elements, comments, processing instructions, and references, possibly together with character data not contained within any element in the entity, or else they must contain non-textual data, which by definition contains no elements.

A character reference refers to a specific character in the ISO/IEC 10646 character set, e.g. one not directly accessible from available input devices: CharRef '&#' [0-9]+ ';' | '&hcro;' [0-9a-fA-F]+ ';'

An entity reference refers to the content of a named entity. General entities are text entities for use within the document itself; references to them use ampersand (&) and semicolon (;) as delimiters. In this specification, general entities are sometimes referred to with the unqualified term entity when this leads to no ambiguity. Parameter entities are text entities for use within the DTD, or to control processing of conditional sections; references to them use percent-sign (%) and semicolon (;) as delimiters. Reference EntityRef | CharRef EntityRef '&' Name ';' Entity Declared Text Entity No Recursion PEReference '%' Name ';' Entity Declared Text Entity No Recursion In DTD

Examples of character and entity references: Type <key>less-than</key> (&hcro;3C;) to save options. This document was prepared on &docdate; and is classified &security-level;.

Example of a parameter-entity reference: <!ENTITY % ISOLat2 SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" > %ISOLat2;

Entities are declared thus: EntityDecl '<!ENTITY' S %Name S %EntityDef S? '>' General entities | '<!ENTITY' S '%' S %Name S %EntityDef S? '>' Parameter entities EntityDef EntityValue | ExternalDef The Name is that by which the entity is invoked by exact match in an entity reference. If the same entity is declared more than once, the first declaration encountered is binding; at user option, an XML processor may issue a warning if entities are declared multiple times.

XML allows character and general-entity references in two places: the content of elements (content) and attribute values (AttValue). When an XML processor encounters such a reference, or the name of an external binary entity as the value of an ENTITY or ENTITIES attribute, then:

In all cases, the XML processor may inform the application of the reference's occurrence and its identifier (for an entity reference, the name; for a character reference, the character number in decimal, hexadecimal, or binary form).

Entity and character references can both be used to escape the left angle bracket, ampersand, and other delimiters. A set of general entities (&magicents;) is specified for this purpose. Numeric character references may also be used; they are expanded immediately when recognized, and must be treated as character data, so the numeric character references < and & may be used to escape < and & when they occur in character data.

XML allows parameter-entity references in a variety of places within the DTD. Parameter-entity references are always expanded immediately upon being recognized, and the DTD must match the relevant rules of the grammar after all parameter-entity references have been expanded. In addition, parameter entities referred to in specific contexts are required to satisfy certain constraints in their replacement text; for example, a parameter entity referred to within the internal DTD subset must match the rule for markupdecl.

Implementors of XML processors need to know the rules for expansion of references in more detail. These rules only come into play when the replacement text for an internal entity itself contains other references.

In the replacement text of an internal entity, parameter-entity references and character references in the replacement text are recognized and resolved when the entity declaration is parsed, before the replacement text is stored in the processor's symbol table. General-entity references in the replacement text are not resolved when the entity declaration is parsed.

Simple character references do not suffice to escape delimiters within the replacement text of an internal entity: they will be expanded when the entity declaration is parsed, before the replacement text is stored in the symbol table. When the entity itself is referred to, the replacement text will be parsed again, and the delimiters (no longer character references) will be recognized as delimiters. To escape the characters &magicents; in an entity replacement text, use a general-entity reference or a doubly-escaped character reference. See the appendix on expansion of entity references for detailed examples.

As mentioned in the discussion of Character Data and Markup, the characters used as markup delimiters by XML may all be escaped using entity references (for the entities &magicents;).

All XML processors must recognize these entities whether they are declared or not. Valid XML documents must declare these entities, like any others, before using them.

If the entities in question are declared, they must be declared as internal entities whose replacement text is the single character being escaped, as shown below. ]]>

Notations identify by name the format of external binary entities, or the application to which processing instructions are addressed.

Notation declarations provide a name for the notation, for use in entity and attribute-list declarations and in attribute-value specifications, and an external identifier for the notation which may allow an XML processor or its client application to locate a helper application capable of processing data in the given notation. NotationDecl '<!NOTATION' S %Name S %ExternalID S? '>'

XML processors must provide applications with the name and external identifier of any notation declared and referred to in an attribute value, attribute definition, or entity declaration. They may additionally resolve the external identifier into the system identifier, file name, or other information needed to allow the application to call a processor for data in the notation described. (It is not an error, however, for XML documents to declare and refer to notations for which notation-specific applications are not available on the system where the XML processor or application is running.)