[Definition: A data object is an XML
document if it is well-formed,
as defined in this specification. In addition, the XML document is
valid if it meets certain further constraints.]
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. Logically, the document
is composed of declarations, elements, comments, character references, and
processing instructions, all of which are indicated in the document by explicit
markup. The logical and physical structures MUST nest properly, as described
in 4.3.2 Well-Formed Parsed Entities.
[Definition: A textual object is a well-formed
XML document if:]
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
which is referenced directly or indirectly within the document is well-formed.
Matching the document production implies that:
It contains one or more elements.
[Definition: There is exactly one element,
called the root, or document element, no part of which appears
in the content of any other element.] For
all other elements, if the start-tag is in
the content of another element, the end-tag
is 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 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. P
is referred to as the parent of C, and C as
a child of P.]
[Definition: A parsed entity contains text,
a sequence of characters, which may
represent markup or character data.]
[Definition: A character
is an atomic unit of text as specified by ISO/IEC 10646:2000 [ISO/IEC 10646]. Legal characters are tab, carriage
return, line feed, and the legal characters
of Unicode and ISO/IEC 10646. The
versions of these standards cited in A.1 Normative References were
current at the time this document was prepared. New characters may be added
to these standards by amendments or new editions. Consequently, XML processors
MUST accept any character in the range specified for Char.
]
| [2] | Char | ::= | #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] | /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ |
The mechanism for encoding character code points into bit patterns may
vary from entity to entity. All XML processors MUST accept the UTF-8 and UTF-16
encodings of Unicode [Unicode];
the mechanisms for signaling which of the two is in use,
or for bringing other encodings into play, are discussed later, in 4.3.3 Character Encoding in Entities.
Note:
Document authors are encouraged to avoid
"compatibility characters", as defined
in section 2.3 of [Unicode]. The characters defined in the following ranges are also
discouraged. They are either control characters or permanently undefined Unicode
characters:
[#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].
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.
| [3] | S | ::= | (#x20 | #x9 | #xD | #xA)+ |
An Nmtoken (name token) is any mixture of name
characters.
[Definition: A Name is an Nmtoken with a restricted set of initial characters.] Disallowed initial characters for Names 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.
Note:
The
Namespaces in XML Recommendation [XML Names] assigns a meaning
to names containing colon characters. Therefore, authors should not use the
colon in XML names except for namespace purposes, but XML processors must
accept the colon as a name character.
The first character of a Name MUST be a NameStartChar, and any
other characters MUST be NameChars; this mechanism is used to
prevent names from beginning with European (ASCII) digits or with
basic combining characters. Almost all characters are permitted in
names, except those which either are or reasonably could be used as
delimiters. The intention is to be inclusive rather than exclusive,
so that writing systems not yet encoded in Unicode can be used in
XML names. See J Suggestions for XML Names for suggestions on the creation of
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 be part of
an XML name. The character #x037E, GREEK QUESTION MARK, is excluded
because when normalized it becomes a semicolon, which could change
the meaning of entity references.
| [4] | 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] |
| [4a] | NameChar | ::= | NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040] |
| [5] | Name | ::= | NameStartChar (NameChar)* |
| [6] | Names | ::= | Name (#x20 Name)* |
| [7] | Nmtoken | ::= | (NameChar)+ |
| [8] | Nmtokens | ::= | Nmtoken (#x20 Nmtoken)* |
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), the values
of attributes (AttValue), and external identifiers
(SystemLiteral). Note that a SystemLiteral
can be parsed without scanning for markup.
Note:
Although
the EntityValue production allows the definition
of a general entity consisting of a single explicit < in the literal
(e.g., <!ENTITY mylt "<">), it is strongly advised to avoid
this practice since any reference to that entity will cause a well-formedness
error.
Text consists of intermingled character data and markup. [Definition:
Markup takes the form of start-tags, end-tags, empty-element tags, entity references, character
references, comments, CDATA section delimiters, document
type declarations, processing instructions, XML declarations, text declarations,
and any white space that is at the top level of the document entity (that
is, outside the document element and not inside any other markup).]
[Definition: All text that is not markup
constitutes the character data of the document.]
The ampersand character (&) and the left angle bracket (<) MUST NOT appear
in their literal form, except when used as markup delimiters, or
within a comment, a processing
instruction, or a CDATA section.
If they are needed elsewhere, they MUST be escaped
using either numeric character references
or the strings "
&
" and "
<
"
respectively. The right angle bracket (>) may be represented using the string "
>
",
and MUST, for compatibility, be escaped
using either "
>
" or a character reference when it
appears in the string "
]]>
" in content, 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 and does not include the CDATA-section-close
delimiter, "
]]>
". 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 "
"
".
| [14] | CharData | ::= | [^<&]* - ([^<&]* ']]>' [^<&]*) |
[Definition:
Processing instructions
(PIs) allow documents to contain instructions for applications.]
PIs are not part of the document's character
data, but MUST be passed through to the application. The PI begins
with a target (PITarget) used to identify the application
to which the instruction is directed. The target names "
XML
", "
xml
",
and so on are reserved for standardization in this or future versions of this
specification. The XML Notation mechanism
may be used for formal declaration of PI targets. Parameter
entity references MUST NOT be recognized within processing instructions.
[Definition:
CDATA sections may 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 "
]]>
":]
Within a CDATA section, only the CDEnd string is
recognized as markup, 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, in which "
<greeting>
"
and "
</greeting>
" are recognized as character data, not markup:
<![CDATA[<greeting>Hello, world!</greeting>]]>
[Definition: XML documents SHOULD
begin with an XML declaration which specifies the version of
XML being used.] For example, the following is a complete XML document, well-formed but not valid:
<?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 and
logical structure and to associate attribute
name-value pairs with its logical structures. XML provides a mechanism, the
document
type declaration, to define constraints on the logical structure
and to support the use of predefined storage units. [Definition: An XML document is valid if it has 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 element
in the document.
Even though the VersionNum production matches
any version number of the form '1.x', XML 1.0 documents SHOULD NOT specify a version number other than '1.0'.
Note:
When an XML 1.0 processor encounters a document that specifies
a 1.x version number other than '1.0', it will process it as
a 1.0 document. This means that an XML 1.0 processor will accept
1.x documents provided they do not use any non-1.0 features.
[Definition: The XML document
type declaration contains or points to markup
declarations that provide a grammar for a class of documents. This
grammar is known as a document type definition, or DTD. The document
type declaration can point to an external subset (a special kind of external entity) containing markup declarations,
or can contain the markup declarations directly in an internal subset, or
can do both. The DTD for a document consists of both subsets taken together.]
[Definition: A markup declaration
is an element type declaration, an attribute-list declaration, an entity
declaration, or a notation declaration.]
These declarations may be contained in whole or in part within parameter
entities, as described in the well-formedness and validity constraints
below. For further
information, see 4 Physical Structures.
Note
that it is possible to construct a well-formed document containing a doctypedecl
that neither points to an external subset nor contains an internal subset.
The markup declarations may be made up in whole or in part of the replacement text of parameter
entities. The productions later in this specification for individual
nonterminals (elementdecl, AttlistDecl,
and so on) describe the declarations after all the parameter
entities have been 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).
They are also recognized in entity value literals. The use of parameter entities
in the internal subset is restricted as described below.
Like the internal subset, the external subset and any external parameter
entities referenced
in a DeclSep
MUST consist of a series of
complete markup declarations of the types allowed by the non-terminal symbol markupdecl, interspersed with white space or parameter-entity references. However, portions of
the contents of the external subset or of these
external parameter entities may conditionally be ignored by using the conditional section construct; this is not
allowed in the internal subset but is
allowed in external parameter entities referenced in the internal subset.
The external subset and external parameter entities also differ from the
internal subset in that in them, parameter-entity
references are permitted within markup declarations,
not only between 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>
The system 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 subset
MUST be considered to occur before the external subset.
This has the effect that entity and attribute-list declarations in the internal
subset take precedence over those in the external subset.
Markup declarations can affect the content of the document, as passed from
an XML processor to an application; examples
are attribute defaults and entity declarations. The standalone document declaration,
which may appear as a component of the XML declaration, signals whether or
not there are such declarations which appear external to the document
entity
or in parameter entities. [Definition: An external
markup declaration is defined as a markup declaration occurring in
the external subset or in a parameter entity (external or internal, the latter
being included because non-validating processors are not required to read
them).]
In a standalone document declaration, the value "yes" indicates
that there are no external markup declarations which
affect the information passed from the XML processor to the application. The
value "no" indicates that there are or may be such external
markup declarations. Note that the standalone document declaration only denotes
the presence of external declarations; the presence, in a document,
of references to external entities, when those entities are internally
declared, does not change its standalone status.
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" holds can be converted
algorithmically to a standalone document, which may be desirable for some
network delivery applications.
Validity constraint: Standalone Document Declaration
The
standalone document declaration MUST have the value "no" if
any external markup declarations contain declarations of:
attributes with default values,
if elements to which these attributes apply appear in the document without
specifications of values for these attributes, or
entities (other than amp,
lt,
gt,
apos,
quot), if references
to those entities appear in the document, or
attributes with
tokenized types, where the
attribute appears in the document with a value such that
normalization
will produce a different value from that which would be produced
in the absence of the declaration, or
element types with element content,
if white space occurs directly within any instance of those types.
An example XML declaration with a standalone document declaration:
<?xml version="1.0" 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 always pass
all characters in a document that are not markup through to the application.
A validating XML processor
MUST also
inform the application which of these characters constitute white space appearing
in element content.
A special attribute named xml: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, this
attribute, like any other, MUST be declared
if it is used. When declared, it MUST be given as an enumerated
type whose values
are 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-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 attribute. This specification does not give meaning to any value of xml:space other than "default" and "preserve". It is an error for other values to be specified; the XML processor MAY report the error or MAY recover by ignoring the attribute specification or by reporting the (erroneous) value to the application. Applications may ignore or reject erroneous values.
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 parsed entities are often stored
in computer files which, for editing convenience, are organized into lines.
These lines are typically separated by some combination of the characters
CARRIAGE RETURN (#xD) and LINE FEED (#xA).
To
simplify the tasks of applications, the
XML
processor
MUST behave as if it normalized all line breaks in external parsed
entities (including the document entity) on input, before parsing, by translating
both the two-character sequence #xD #xA and any #xD that is not followed by
#xA to a single #xA character.
In document processing, it is often useful to identify the natural or formal
language in which the content is written. A special attribute
named xml:lang may be inserted in documents to specify the language
used in the contents and attribute values of any element in an XML document.
In valid documents, this attribute, like any other, MUST be declared
if it is used. The
values of the attribute are language identifiers as defined by [IETF BCP 47], Tags
for 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 by xml: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 of xml:lang. In particular, the empty value of xml:lang is used on an element B to override
a specification of xml:lang on an enclosing element A, without specifying another language. Within B,
it is considered that there is no language information available, just as if xml: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 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 should be considered to override it.
A simple declaration for xml:lang might take the form
but specific default values may also be given, if appropriate. In a collection
of French poems for English students, with glosses and notes in English, the xml:lang
attribute might be declared this way:
<!ATTLIST poem xml:lang CDATA 'fr'>
<!ATTLIST gloss xml:lang CDATA 'en'>
<!ATTLIST note xml:lang CDATA 'en'>
[Definition: Each XML
document contains one or more elements, the boundaries
of which are either delimited by start-tags
and end-tags, or, for empty
elements, by an empty-element tag. Each
element has a type, identified by name, sometimes called its "generic
identifier" (GI), and may have a set of attribute specifications.]
Each attribute specification has a name
and a value.
This specification does not constrain the
application semantics, use, or (beyond syntax)
names of the element types and attributes, except that names beginning with
a match to (('X'|'x')('M'|'m')('L'|'l')) are reserved for standardization
in this or future versions of this specification.
Validity constraint: Element Valid
An element is valid
if there is a declaration matching elementdecl
where the Name matches the element type, and one of
the following holds:
The declaration matches EMPTY and the element has no content (not even entity
references, comments, PIs or white space).
The declaration matches children and the
sequence of child elements belongs
to the language generated by the regular expression in the content model,
with optional white space, comments and
PIs (i.e. markup matching production [27] Misc) between the
start-tag and the first child element, between child elements, or between
the last child element and the end-tag. Note that a CDATA section containing
only white space or a reference
to an entity whose replacement text is character references expanding to white
space do not
match the nonterminal S, and
hence cannot appear in these positions; however, a
reference to an internal entity with a literal value consisting of character
references expanding to white space does match S, since its
replacement text is the white space resulting from expansion of the character
references.
The declaration matches Mixed, and the content
(after replacing
any entity references with their replacement text) consists of
character data
(including CDATA sections),
comments, PIs and child elements whose types match names in the
content model.
The declaration matches ANY, and the content (after replacing
any entity references with their replacement text)
consists of character data, CDATA
sections, comments, PIs
and child elements
whose types have been declared.
[Definition: The beginning of every non-empty
XML element is marked by a start-tag.]
The Name in the start- and end-tags gives the element's type. [Definition: The Name-AttValue
pairs are referred to as the attribute specifications of the
element], [Definition: with the Name in each pair referred to as the attribute name
]
and [Definition: the content of the AttValue (the text between the ' or "
delimiters) as the attribute value.] Note
that the order of attribute specifications in a start-tag or empty-element
tag is not significant.
An example of a start-tag:
<termdef id="dt-dog" term="dog">
[Definition: The end of every element that begins
with a start-tag MUST be marked by an end-tag containing a name
that echoes the element's type as given in the start-tag:]
An example of an end-tag:
[Definition: The text
between the start-tag and end-tag is called the element's content:]
[Definition: An element
with no content is said to be empty.] The representation
of an empty element is either a start-tag immediately followed by an end-tag,
or an empty-element tag. [Definition: An empty-element
tag takes a special form:]
Empty-element tags may be used for any element which has no content, whether
or not it is declared using the keyword EMPTY. For
interoperability, the empty-element tag SHOULD
be used, and SHOULD only be used, for elements which are declared
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 type and attribute-list declarations.
An element type declaration constrains the element's content.
Element type 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 declaration mentions an
element type for which no declaration is provided, but this is not an error.
[Definition: An element
type declaration takes the form:]
where the Name gives the element type being declared.
Examples of element type declarations:
[Definition: An element type has element content when elements
of that type MUST contain only child
elements (no character data), optionally separated by white space (characters
matching the nonterminal S).]
[Definition: In this case, the constraint includes a content
model, a simple grammar governing the allowed types of the
child elements and the order in which they are allowed to appear.]
The grammar is built on content particles (cps), which
consist of names, choice lists of content particles, or sequence lists of
content particles:
where each Name is the type of an element which
may appear as a child. Any content
particle in a choice list may appear in the element
content at the location where the choice list appears in the grammar;
content particles occurring in a sequence list MUST each appear in the element content in the order given in the list.
The optional character following a name or list governs whether the element
or the content particles in the list may occur one or more (+),
zero or more (*), or zero or one times (?). The
absence of such an operator means that the element or content particle MUST
appear exactly once. This syntax and meaning are identical to those used in
the productions in this specification.
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, it is an error if the content model
allows an element to match more than one occurrence of an element type in the
content model. For more information, see E Deterministic Content Models.
Validity constraint: Proper Group/PE Nesting
Parameter-entity replacement text
MUST be properly nested with parenthesized
groups. That is to say, if either of the opening or closing parentheses in
a choice, seq, or Mixed
construct is contained in the replacement text for a parameter
entity, both MUST be contained in the same replacement text.
For interoperability, if a parameter-entity reference
appears in a choice, seq, or Mixed construct, its replacement text SHOULD contain at
least one non-blank character, and neither the first nor last non-blank character
of the replacement text SHOULD be a connector (| or ,).
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: An element type
has mixed content when elements of that type may contain character
data, optionally interspersed with child
elements.] In this case, the types of the child elements may be constrained,
but not their order or their number of occurrences:
where the Names give the types of elements that
may appear as children. The
keyword #PCDATA derives historically from the term "parsed
character data."
Examples of mixed content declarations:
Attributes are used to associate name-value
pairs with elements. Attribute specifications
MUST NOT appear outside of start-tags and empty-element tags; thus, the productions used to
recognize them appear in 3.1 Start-Tags, End-Tags, and Empty-Element Tags. Attribute-list declarations
may be used:
To define the set of attributes pertaining to a given element type.
To establish type constraints for these attributes.
To provide default values for
attributes.
[Definition:
Attribute-list
declarations specify the name, data type, and default value (if any)
of each attribute associated with a given element type:]
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,
at most one attribute definition for a given attribute name in an attribute-list
declaration, and at least one attribute definition in each attribute-list
declaration. 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 is provided
for a given attribute, but this is not an error.
Before the value of an attribute is passed to the application or checked
for validity, the XML processor MUST normalize the attribute value by applying
the algorithm below, or by using some other method such that the value passed
to the application is the same as that produced by the algorithm.
All line breaks MUST have been normalized on input to #xA as described
in 2.11 End-of-Line Handling, so the rest of this algorithm operates
on text normalized in this way.
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 further
process the normalized attribute value by discarding any leading and trailing
space (#x20) characters, and by replacing sequences of space (#x20) characters
by a single space (#x20) character.
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 be treated
by a non-validating processor as if declared CDATA.
It is an error if an attribute
value contains a reference to an
entity for which no declaration has been read.
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
is declared NMTOKENS and to those of the right columns if a
is declared CDATA.
| Attribute specification | a is NMTOKENS | a is CDATA |
|---|
|
|
|
|
a="&d;&d;A&a; &a;B&da;" |
|
#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
is declared to be of type NMTOKENS.
[Definition:
Conditional
sections are portions of the document type
declaration external subset or
of external parameter entities which are included in, or excluded from,
the logical structure of the DTD based on the keyword which governs them.]
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
contents of the conditional section MUST be processed as part of the DTD. If the keyword of
the conditional section is IGNORE, then the contents of the conditional
section MUST NOT be processed as part of the DTD.
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 MUST be ignored. The contents
of an ignored conditional section MUST be parsed by ignoring all characters after
the "[" following the keyword, except conditional section starts
"<![" and ends "]]>", until the matching conditional
section end is found. Parameter entity references MUST NOT be recognized in this
process.
If the keyword of the conditional section is a parameter-entity reference,
the parameter entity MUST be replaced by its content before the processor
decides whether to include or ignore the conditional section.
An example:
[Definition: An XML document may consist of one
or many storage units. These
are called entities; they all have content and are
all (except for the document entity and
the external DTD subset) identified by
entity name.] Each XML document has one entity
called the document entity, which serves
as the starting point for the XML processor
and may contain the whole document.
Entities may be either parsed or unparsed. [Definition: The contents of a parsed
entity are referred to as its replacement
text; this text is considered an
integral part of the document.]
[Definition: An unparsed entity
is a resource whose contents may or may not be text,
and if text, may
be other than XML. Each unparsed entity has an associated notation, identified by name. Beyond a requirement
that an XML processor make the identifiers for the entity and notation available
to the application, XML places no constraints on the contents of unparsed
entities.]
Parsed entities are invoked by name using entity references; unparsed entities
by name, given in the value of ENTITY or ENTITIES attributes.
[Definition:
General entities
are entities for use within the document content. In this specification, general
entities are sometimes referred to with the unqualified term entity
when this leads to no ambiguity.]
[Definition:
Parameter
entities are parsed entities for use within the DTD.]
These two types of entities use different forms of reference and are recognized
in different contexts. Furthermore, they occupy different namespaces; a parameter
entity and a general entity with the same name are two distinct entities.
[Definition: A character
reference refers to a specific character in the ISO/IEC 10646 character
set, for example one not directly accessible from available input devices.]
If the character reference begins with "
&#x
",
the digits and letters up to the terminating ; provide a hexadecimal
representation of the character's code point in ISO/IEC 10646. If it begins
just with "
&#
", the digits up to the terminating ;
provide a decimal representation of the character's code point.
[Definition: An entity reference
refers to the content of a named entity.]
[Definition: References to parsed general entities use
ampersand (&) and semicolon (;) as delimiters.]
[Definition:
Parameter-entity references
use percent-sign (%) and semicolon (;) as delimiters.]
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'
", for
an entity reference that does not occur within the external subset or a parameter
entity, the Name given in the entity reference MUST
match that in an entity
declaration that does not occur within the external subset or a
parameter entity, except that well-formed documents need not declare
any of the following entities: amp,
lt,
gt,
apos,
quot. The
declaration of a general entity MUST precede any reference to it which appears
in a default value in an attribute-list declaration.
Note that non-validating processors are not
obligated to read and process entity declarations occurring in parameter entities or in
the external subset; for such documents,
the rule that an entity must be declared is a well-formedness constraint only
if standalone='yes'.
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: Entities are declared
thus:]
The Name identifies the entity in an entity
reference or, in the case of an unparsed entity, in the value of
an ENTITY or ENTITIES attribute. 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.
[Definition: If the entity is not internal,
it is an external entity, declared as follows:]
If the NDataDecl is present, this is a general unparsed entity; otherwise it is a parsed entity.
[Definition: The SystemLiteral is called the entity's system
identifier. It is meant to be converted to a URI reference
(as defined in [IETF RFC 3986]),
as part of the
process of dereferencing it to obtain input for the XML processor to construct the
entity's replacement text.] It is an error for a fragment identifier
(beginning with a # character) to be part of a system identifier.
Unless otherwise provided by information outside the scope of this specification
(e.g. a special XML element type defined by a particular DTD, or a processing
instruction defined by a particular application specification), relative URIs
are relative to the location of the resource within which the entity declaration
occurs. This is defined to
be the external entity containing the '<' which starts the declaration, at the
point when it is parsed as a declaration.
A URI might thus be relative to the document
entity, to the entity containing the external
DTD subset, or to some other external parameter
entity. Attempts to
retrieve the resource identified by a URI may be redirected at the parser
level (for example, in an entity resolver) or below (at the protocol level,
for example, via an HTTP Location: header). In the absence of additional
information outside the scope of this specification within the resource,
the base URI of a resource is always the URI of the actual resource returned.
In other words, it is the URI of the resource retrieved after all redirection
has occurred.
System
identifiers (and other XML strings meant to be used as URI references) may contain
characters that, according to [IETF RFC 3986],
must be escaped before a URI can be used to retrieve the referenced resource. The
characters to be escaped are the control characters #x0 to #x1F and #x7F (most of
which cannot appear in XML), space #x20, the delimiters '<' #x3C, '>' #x3E and
'"' #x22, the unwise characters '{' #x7B, '}' #x7D, '|' #x7C, '\' #x5C, '^' #x5E and
'`' #x60, as well as all characters above #x7F. Since escaping is not always a fully
reversible process, it MUST be performed only when absolutely necessary and as late
as possible in a processing chain. In particular, neither the process of converting
a relative URI to an absolute one nor the process of passing a URI reference to a
process or software component responsible for dereferencing it SHOULD trigger escaping.
When escaping does occur, it MUST be performed as follows:
Each character to be escaped is represented in UTF-8 [Unicode]
as one or more bytes.
The resulting bytes are escaped with
the URI escaping mechanism (that is, converted to %
HH,
where HH is the hexadecimal notation of the byte value).
The original character is replaced by the resulting character sequence.
Note:
In a future edition of this specification, the XML Core Working Group intends to replace the preceding paragraph
and list of steps with a normative reference to an upcoming revision of IETF RFC 3987, which will define
"Legacy Extended IRIs (LEIRIs)". When this revision is available, it is the intent of the XML Core WG to use it to replace
language similar to the above in any future revisions of XML-related specifications under its purview.
[Definition: In addition to a system
identifier, an external identifier may include a public identifier.]
An XML processor attempting to retrieve the entity's content may use
any combination of
the public and system identifiers as well as additional information outside the
scope of this specification to try to generate an alternative URI reference.
If the processor is unable to do so, it MUST use the URI
reference specified in the system literal. Before a match is attempted,
all strings of white space in the public identifier MUST be normalized to
single space characters (#x20), and leading and trailing white space MUST
be removed.
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 >
Each external parsed entity in an XML document may use a different encoding
for its characters. All XML processors MUST be able to read entities in both
the UTF-8 and UTF-16 encodings. The terms "UTF-8"
and "UTF-16" in this specification do not apply to
related character encodings, including but not limited to UTF-16BE, UTF-16LE, or CESU-8.
Entities encoded in UTF-16 MUST and entities
encoded in UTF-8 MAY begin with the Byte Order Mark described by
Annex H of [ISO/IEC 10646:2000], section
16.8 of [Unicode]
(the ZERO WIDTH NO-BREAK SPACE character, #xFEFF). This is an encoding signature,
not part of either the markup or the character data of the XML document. XML
processors MUST be able to use this character to differentiate between UTF-8
and UTF-16 encoded documents.
If the replacement text of an external entity is to
begin with the character U+FEFF, and no text declaration
is present, then a Byte Order Mark MUST be present,
whether the entity is encoded in UTF-8 or UTF-16.
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 begin with a text declaration (see 4.3.1 The Text Declaration) containing
an encoding declaration:
| [80] | EncodingDecl | ::= |
S 'encoding' Eq
('"' EncName '"' | "'" EncName
"'" ) |
| [81] | EncName | ::= | [A-Za-z] ([A-Za-z0-9._] | '-')* | /* Encoding
name contains only Latin characters */ |
In the document entity, the encoding
declaration is part of the XML declaration.
The EncName is the name of the encoding used.
In an encoding declaration, the values "
UTF-8
", "
UTF-16
",
"
ISO-10646-UCS-2
", and "
ISO-10646-UCS-4
"
SHOULD be used
for the various encodings and transformations of Unicode / ISO/IEC 10646,
the values "
ISO-8859-1
", "
ISO-8859-2
",
... "
ISO-8859-
n
" (where n
is the part number) SHOULD be used for the parts of ISO 8859, and
the values "
ISO-2022-JP
", "
Shift_JIS
",
and "
EUC-JP
"
SHOULD be used for the various encoded
forms of JIS X-0208-1997. It
is RECOMMENDED that character encodings registered (as charsets)
with the Internet Assigned Numbers Authority [IANA-CHARSETS],
other than those just listed, be referred to using their registered names;
other encodings SHOULD use names starting with an "x-" prefix.
XML processors SHOULD match character encoding names in a case-insensitive
way and SHOULD either interpret an IANA-registered name as the encoding registered
at IANA for that name or treat it as unknown (processors are, of course, not
required to support all IANA-registered encodings).
In the absence of information provided by an external transport protocol
(e.g. HTTP or MIME), it is a fatal error for
an entity including an encoding declaration to be presented to the XML processor
in an encoding other than that named in the declaration, or for an entity which
begins with neither a Byte Order Mark
nor an encoding declaration to use an encoding other than UTF-8. Note that
since ASCII is a subset of UTF-8, ordinary ASCII entities do not strictly
need an encoding declaration.
It is a fatal error for a TextDecl to occur other
than at the beginning of an external entity.
It is a fatal error when an XML processor
encounters an entity with an encoding that it is unable to process. It
is a fatal error if an XML entity is determined (via default, encoding declaration,
or higher-level protocol) to be in a certain encoding but contains byte
sequences that are not legal in that encoding. Specifically, it is a
fatal error if an entity encoded in UTF-8 contains any ill-formed code unit sequences,
as defined in section 3.9 of Unicode [Unicode]. Unless an encoding
is determined by a higher-level protocol, it is also a fatal error if an XML entity
contains no encoding declaration and its content is not legal UTF-8 or UTF-16.
Examples of text declarations containing encoding declarations:
<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>
The table below summarizes the contexts in which character references,
entity references, and invocations of unparsed entities might appear and the
REQUIRED behavior of an XML processor
in each case. The labels in the leftmost column describe the recognition context:
- Reference in Content
as a reference anywhere after the start-tag
and before the end-tag of an element; corresponds
to the nonterminal content.
- Reference in Attribute Value
as a reference within either the value of an attribute in a start-tag,
or a default value in an attribute declaration;
corresponds to the nonterminal AttValue.
- Occurs as Attribute Value
as a Name, not a reference, appearing either as
the value of an attribute which has been declared as type ENTITY,
or as one of the space-separated tokens in the value of an attribute which
has been declared as type ENTITIES.
- Reference in Entity Value
as a reference within a parameter or internal entity's literal
entity value in the entity's declaration; corresponds to the nonterminal EntityValue.
- Reference in DTD
as a reference within either the internal or external subsets of the DTD, but outside of an EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral,
or the contents of an ignored conditional section (see 3.4 Conditional Sections).
.
[Definition: An entity is included
when its replacement text is retrieved
and processed, in place of the reference itself, as though it were part of
the document at the location the reference was recognized.] The replacement
text may contain both character data
and (except for parameter entities) markup,
which MUST be recognized in the usual way. (The string "
AT&T;
"
expands to "
AT&T;
" and the remaining ampersand
is not recognized as an entity-reference delimiter.) A character reference
is included when the indicated character is processed in place
of the reference itself.
When an XML processor recognizes a reference to a parsed entity, in order
to validate the document, the processor
MUST
include its replacement text. If
the entity is external, and the processor is not attempting to validate the
XML document, the processor MAY, but need
not, include the entity's replacement text. If a non-validating processor
does not include the replacement text, it MUST inform the application that
it recognized, but did not read, the entity.
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.
When an entity reference appears in
an attribute value, or a parameter entity reference appears in a literal entity
value, its replacement text
MUST be processed
in place of the reference itself as though it were part of the document at
the location the reference was recognized, except that a single or double
quote character in the replacement text MUST always be treated as a normal data
character and MUST NOT terminate the literal. For example, this is well-formed:
<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" >
while this is not:
<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>
In discussing the treatment of entities, it is useful to distinguish
two forms of the entity's value.
[Definition: For an
internal entity, the literal
entity value is the quoted string actually present in the entity declaration,
corresponding to the non-terminal EntityValue.]
[Definition: For an external entity, the literal
entity value is the exact text contained in the entity.]
[Definition: For an
internal entity, the replacement text
is the content of the entity, after replacement of character references and
parameter-entity references.]
[Definition: For
an external entity, the replacement text is the content of the entity,
after stripping the text declaration (leaving any surrounding whitespace) if there
is one but without any replacement of character references or parameter-entity
references.]
The literal entity value as given in an internal entity declaration (EntityValue) may contain character, parameter-entity,
and general-entity references. Such references MUST be contained entirely
within the literal entity value. The actual replacement text that is included (or included in literal) as described above
MUST contain the replacement
text of any parameter entities referred to, and MUST contain the character
referred to, in place of any character references in the literal entity value;
however, general-entity references MUST be left as-is, unexpanded. For example,
given the following declarations:
<!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
"
is:
La Peste: Albert Camus,
© 1947 Éditions Gallimard. &rights;
The general-entity reference "
&rights;
" would
be expanded should the reference "
&book;
" appear
in the document's content or an attribute value.
These simple rules may have complex interactions; for a detailed discussion
of a difficult example, see D Expansion of Entity and Character References.
[Definition: Entity and character references may
both be used to escape the left angle bracket, ampersand, and
other delimiters. A set of general entities (amp,
lt,
gt,
apos,
quot) 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.]
All XML processors MUST recognize these entities whether they are declared
or not. For interoperability, valid XML
documents SHOULD declare these entities, like any others, before using them. If
the entities lt or amp are declared, they MUST be
declared as internal entities whose replacement text is a character reference
to the respective
character (less-than sign or ampersand) being escaped; the double
escaping is REQUIRED for these entities so that references to them produce
a well-formed result. If the entities gt, apos,
or quot are declared, they MUST be declared as internal entities
whose replacement text is the single character being escaped (or a character
reference to that character; the double escaping here is OPTIONAL but harmless).
For example:
<!ENTITY lt "&#60;">
<!ENTITY gt ">">
<!ENTITY amp "&#38;">
<!ENTITY apos "'">
<!ENTITY quot """>
[Definition:
Notations identify
by name the format of unparsed entities,
the format of elements which bear a notation attribute, or the application
to which a processing instruction is addressed.]
[Definition:
Notation declarations
provide a name for the notation, for use in entity and attribute-list declarations
and in attribute 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.]
XML processors MUST provide applications with the name and external identifier(s)
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.)
[Definition: The document entity
serves as the root of the entity tree and a starting-point for an XML processor.] This specification does
not 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 appear
on a processor input stream without any identification at all.
