Extensible Markup Language (XML) 1.0

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 (
cp
s), which consist of names,
choice lists of content particles, or
sequence lists of content particles:
Element-content Models
[47]
children
::=
choice
seq
('?' | '*' | '+')?
[48]
cp
::=
Name
choice
seq
('?' | '*' | '+')?
[49]
choice
::=
'('
? cp
? '|'
cp
)*
? ')'
VC:
Proper Group/PE Nesting
[50]
seq
::=
'('
? cp
? ','
cp
)*
? ')'
VC:
Proper Group/PE Nesting
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 an element in the document can
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 parenthetized 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 not be empty, and
neither the first nor last non-blank
character of the replacement text should be a connector
or
).
Examples of element-content models:



3.2.2 Mixed Content
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:
Mixed-content Declaration
[51]
Mixed
::=
'('
'#PCDATA'
'|'
Name
)*
')*'
| '('
? '#PCDATA'
? ')'
VC:
Proper Group/PE Nesting
VC:
No Duplicate Types
where the
Name
s give the types of elements
that may appear as children.
Validity Constraint:
No Duplicate Types
The same name must not appear more than once in a single mixed-content
declaration.
Examples of mixed content declarations:



3.3 Attribute-List Declarations
Attributes
are used to associate
name-value pairs with
elements
Attribute specifications may appear only within
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.
Attribute-list declarations
specify the name, data type, and default
value (if any) of each attribute associated with a given element type:
Attribute-list Declaration
[52]
AttlistDecl
::=
'Name
AttDef
? '>'
[53]
AttDef
::=
Name
AttType
DefaultDecl
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, 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.
3.3.1 Attribute Types
XML attribute types are of three kinds: a string type, a
set of tokenized types, and enumerated types. The string type may take
any literal string as a value; the tokenized types have varying lexical
and semantic constraints, as noted:
Attribute Types
[54]
AttType
::=
StringType
TokenizedType
EnumeratedType
[55]
StringType
::=
'CDATA'
[56]
TokenizedType
::=
'ID'
VC:
ID
VC:
One ID per Element Type
VC:
ID Attribute Default
| 'IDREF'
VC:
IDREF
| 'IDREFS'
VC:
IDREF
| 'ENTITY'
VC:
Entity Name
| 'ENTITIES'
VC:
Entity Name
| 'NMTOKEN'
VC:
Name Token
| 'NMTOKENS'
VC:
Name Token
Validity Constraint:
ID
Values of type
ID
must match the
Name
production.
A name must not appear more than once in
an XML document as a value of this type; i.e., ID values must uniquely
identify the elements which bear them.
Validity Constraint:
One ID per Element Type
No element type may have more than one ID attribute specified.
Validity Constraint:
ID Attribute Default
An ID attribute must have a declared default of
#IMPLIED
or
#REQUIRED
Validity Constraint:
IDREF
Values of type
IDREF
must match
the
Name
production, and
values of type
IDREFS
must match
Names
each
Name
must match the value of an ID attribute on
some element in the XML document; i.e.
IDREF
values must
match the value of some ID attribute.
Validity Constraint:
Entity Name
Values of type
ENTITY
must match the
Name
production,
values of type
ENTITIES
must match
Names
each
Name
must
match the
name of an
unparsed entity
declared in the
DTD
Validity Constraint:
Name Token
Values of type
NMTOKEN
must match the
Nmtoken
production;
values of type
NMTOKENS
must
match
Nmtokens
Enumerated attributes
can take one
of a list of values provided in the declaration. There are two
kinds of enumerated types:
Enumerated Attribute Types
[57]
EnumeratedType
::=
NotationType
Enumeration
[58]
NotationType
::=
'NOTATION'
'('
Name
? '|'
Name
)*
? ')'
VC:
Notation Attributes
[59]
Enumeration
::=
'('
Nmtoken
? '|'
Nmtoken
)*
')'
VC:
Enumeration
NOTATION
attribute identifies a
notation
, declared in the
DTD with associated system and/or public identifiers, to
be used in interpreting the element to which the attribute
is attached.
Validity Constraint:
Notation Attributes
Values of this type must match
one of the
notation
names included in
the declaration; all notation names in the declaration must
be declared.
Validity Constraint:
Enumeration
Values of this type
must match one of the
Nmtoken
tokens in the
declaration.
For interoperability,
the same
Nmtoken
should not occur more than once in the
enumerated attribute types of a single element type.
3.3.2 Attribute Defaults
An
attribute declaration
provides
information on whether
the attribute's presence is required, and if not, how an XML processor should
react if a declared attribute is absent in a document.
Attribute Defaults
[60]
DefaultDecl
::=
'#REQUIRED'
| '#IMPLIED'
| (('#FIXED' S)?
AttValue
VC:
Required Attribute
VC:
Attribute Default Legal
WFC:
No < in Attribute Values
VC:
Fixed Attribute Default
In an attribute declaration,
#REQUIRED
means that the
attribute must always be provided,
#IMPLIED
that no default
value is provided.
If the
declaration
is neither
#REQUIRED
nor
#IMPLIED
, then the
AttValue
value contains the declared
default
value; the
#FIXED
keyword states that
the attribute must always have the default value.
If a default value
is declared, when an XML processor encounters an omitted attribute, it
is to behave as though the attribute were present with
the declared default value.
Validity Constraint:
Required Attribute
If the default declaration is the keyword
#REQUIRED
, then
the attribute must be specified for
all elements of the type in the attribute-list declaration.
Validity Constraint:
Attribute Default Legal
The declared
default value must meet the lexical constraints of the declared attribute type.
Validity Constraint:
Fixed Attribute Default
If an attribute has a default value declared with the
#FIXED
keyword, instances of that attribute must
match the default value.
Examples of attribute-list declarations:
id      ID      #REQUIRED
name    CDATA   #IMPLIED>
type    (bullets|ordered|glossary)  "ordered">
method  CDATA   #FIXED "POST">
3.3.3 Attribute-Value Normalization
Before the value of an attribute is passed to the application
or checked for validity, the
XML processor must normalize it as follows:
a character reference is processed by appending the referenced
character to the attribute value
an entity reference is processed by recursively processing the
replacement text of the entity
a whitespace character (#x20, #xD, #xA, #x9) is processed by
appending #x20 to the normalized value, except that only a single #x20
is appended for a "#xD#xA" sequence that is part of an external
parsed entity or the literal entity value of an internal parsed
entity
other characters are processed by appending them to the normalized
value
If the declared value 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.
All attributes for which no declaration has been read should be treated
by a non-validating parser as if declared
CDATA
3.4 Conditional Sections
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.
Conditional Section
[61]
conditionalSect
::=
includeSect
ignoreSect
[62]
includeSect
::=
'extSubsetDecl
']]>'
[63]
ignoreSect
::=
'ignoreSectContents
']]>'
[64]
ignoreSectContents
::=
Ignore
('ignoreSectContents
']]>'
Ignore
)*
[65]
Ignore
::=
Char
* -
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 contents of the conditional
section are part of the DTD.
If the keyword of the conditional
section is
IGNORE
, then the contents of the conditional section are
not logically part of the DTD.
Note that for reliable parsing, the contents of even ignored
conditional sections must be read in order 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 must be replaced by its
content before the processor decides whether to
include or ignore the conditional section.
An example:



]]>

]]>
4. Physical Structures
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, see below, and
the
external DTD subset
identified by
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.
parsed entity's
contents are referred to as its
replacement text
this
text
is considered an
integral part of the document.
An
unparsed entity
is a resource whose contents may or may not be
text
, and if text, may not be 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.
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.
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.
4.1 Character and Entity References
character reference
refers to a specific character in the
ISO/IEC 10646 character set, for example one not directly accessible from
available input devices.
Character Reference
[66]
CharRef
::=
'&#' [0-9]+ ';'
| '&#x' [0-9a-fA-F]+ ';'
WFC:
Legal Character
Well-Formedness Constraint:
Legal Character
Characters referred to using character references must
match the production for
Char
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.
An
entity
reference
refers to the content of a named entity.
References to
parsed general entities
use ampersand (
) and semicolon (
) as
delimiters.
Parameter-entity references
use percent-sign (
) and
semicolon
) as delimiters.
Entity Reference
[67]
Reference
::=
EntityRef
CharRef
[68]
EntityRef
::=
'&'
Name
';'
WFC:
Entity Declared
VC:
Entity Declared
WFC:
Parsed Entity
WFC:
No Recursion
[69]
PEReference
::=
'%'
Name
';'
VC:
Entity Declared
WFC:
No Recursion
WFC:
In DTD
Well-Formedness Constraint:
Entity Declared
In a document without any DTD, a document with only an internal
DTD subset which contains no parameter entity references, or a document with
standalone='yes'
",
the
Name
given in the entity reference must
match
that in an
entity declaration
, except that
well-formed documents need not declare
any of the following entities:
amp
lt
gt
apos
quot
The declaration of a parameter entity must precede any reference to it.
Similarly, 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 if entities are declared in the external subset or in
external parameter entities, a non-validating processor is
not obligated to
read
and process their declarations; for such documents, the rule that
an entity must be declared is a well-formedness constraint only
if
standalone='yes'
Validity Constraint:
Entity Declared
In a document with an external subset or external parameter
entities with "
standalone='no'
",
the
Name
given in the entity reference must
match
that in an
entity declaration
For interoperability, valid documents should declare the entities
amp
lt
gt
apos
quot
, in the form
specified in "
4.6 Predefined Entities
".
The declaration of a parameter entity must precede any reference to it.
Similarly, the declaration of a general entity must precede any
reference to it which appears in a default value in an attribute-list
declaration.
Well-Formedness Constraint:
Parsed Entity
An entity reference must not contain the name of an
unparsed entity
. Unparsed entities may be referred
to only in
attribute values
declared to
be of type
ENTITY
or
ENTITIES
Well-Formedness Constraint:
No Recursion
A parsed entity must not contain a recursive reference to itself,
either directly or indirectly.
Well-Formedness Constraint:
In DTD
Parameter-entity references may only appear in the
DTD
Examples of character and entity references:
Type less-than (<) to save options.
This document was prepared on &docdate; and
is classified &security-level;.
Example of a parameter-entity reference:

SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >

%ISOLat2;
4.2 Entity Declarations
Entities are declared thus:
Entity Declaration
[70]
EntityDecl
::=
GEDecl
PEDecl
[71]
GEDecl
::=
'Name
EntityDef
? '>'
[72]
PEDecl
::=
''%'
Name
PEDef
? '>'
[73]
EntityDef
::=
EntityValue
| (
ExternalID
NDataDecl
?)
[74]
PEDef
::=
EntityValue
ExternalID
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.
4.2.1 Internal Entities
If
the entity definition is an
EntityValue
the defined entity is called an
internal entity
There is no separate physical
storage object, and the content of the entity is given in the
declaration.
Note that some processing of entity and character references in the
literal entity value
may be required to
produce the correct
replacement
text
: see "
4.5 Construction of Internal Entity Replacement Text
".
An internal entity is a
parsed
entity
Example of an internal entity declaration:
specification.">
4.2.2 External Entities
If the entity is not
internal, it is an
external
entity
, declared as follows:
External Entity Declaration
[75]
ExternalID
::=
'SYSTEM'
SystemLiteral
| 'PUBLIC'
PubidLiteral
SystemLiteral
[76]
NDataDecl
::=
'NDATA'
Name
VC:
Notation Declared
If the
NDataDecl
is present, this is a
general
unparsed
entity
; otherwise it is a parsed entity.
Validity Constraint:
Notation Declared
The
Name
must match the declared name of a
notation
The
SystemLiteral
is called the entity's
system identifier
. It is a URI,
which may be used to retrieve the entity.
Note that the hash mark (
) and fragment identifier
frequently used with URIs are not, formally, part of the URI itself;
an XML processor may signal an error if a fragment identifier is
given as 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.
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
An XML processor should handle a non-ASCII character in a URI by
representing the character in UTF-8 as one or more bytes, and then
escaping these bytes with the URI escaping mechanism (i.e., by
converting each byte to %HH, where HH is the hexadecimal notation of the
byte value).
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 the public
identifier to try to generate an alternative URI. If the processor
is unable to do so, it must use the URI 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:
SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">
PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
"http://www.textuality.com/boilerplate/OpenHatch.xml">
SYSTEM "../grafix/OpenHatch.gif"
NDATA gif >
4.3 Parsed Entities
4.3.1 The Text Declaration
External parsed entities may each begin with a
text
declaration
Text Declaration
[77]
TextDecl
::=
'VersionInfo
EncodingDecl
? '?>'
The text declaration must be provided literally, not
by reference to a parsed entity.
No text declaration may appear at any position other than the beginning of
an external parsed entity.
4.3.2 Well-Formed Parsed Entities
The document entity is well-formed if it matches the production labeled
document
An external general
parsed entity is well-formed if it matches the production labeled
extParsedEnt
An external parameter
entity is well-formed if it matches the production labeled
extPE
Well-Formed External Parsed Entity
[78]
extParsedEnt
::=
TextDecl
content
[79]
extPE
::=
TextDecl
extSubsetDecl
An internal general parsed entity is well-formed if its replacement text
matches the production labeled
content
All internal parameter entities are well-formed by definition.
A consequence of well-formedness in entities is that the logical
and physical structures in an XML document are properly nested; no
start-tag
end-tag
empty-element tag
element
comment
processing instruction
character
reference
, or
entity reference
can begin in one entity and end in another.
4.3.3 Character Encoding in Entities
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 either UTF-8 or UTF-16.
Entities encoded in UTF-16 must
begin with the Byte Order Mark described by ISO/IEC 10646 Annex E and
Unicode Appendix B (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.
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.
Parsed entities which are stored in an encoding other than
UTF-8 or UTF-16 must begin with a
text
declaration
containing an encoding declaration:
Encoding Declaration
[80]
EncodingDecl
::=
'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-9
" 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. XML
processors may recognize other encodings; it is recommended that
character encodings registered (as
charset
s)
with the Internet Assigned Numbers
Authority
[IANA]
, other than those just listed, should be
referred to
using their registered names.
Note that these registered names are defined to be
case-insensitive, so processors wishing to match against them
should do so in a case-insensitive
way.
In the absence of information provided by an external
transport protocol (e.g. HTTP or MIME),
it is an
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,
for an encoding declaration to occur other than at the beginning
of an external entity, 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
when an XML processor
encounters an entity with an encoding that it is unable to process.
Examples of encoding declarations:


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 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
or
AttValue
Entity Type
Character
Parameter
Internal
General
External Parsed
General
Unparsed
Reference
in Content
Not recognized
Included
Included if validating
Forbidden
Included
Reference
in Attribute Value
Not recognized
Included in literal
Forbidden
Forbidden
Included
Occurs as
Attribute Value
Not recognized
Forbidden
Forbidden
Notify
Not recognized
Reference
in EntityValue
Included in literal
Bypassed
Bypassed
Forbidden
Included
Reference
in DTD
Included as PE
Forbidden
Forbidden
Forbidden
Forbidden
4.4.1 Not Recognized
Outside the DTD, the
character has no
special significance; thus, what would be parameter entity references in the
DTD are not recognized as markup in
content
Similarly, the names of unparsed entities are not recognized except
when they appear in the value of an appropriately declared attribute.
4.4.2 Included
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, except that the replacement text of entities used to escape
markup delimiters (the entities
amp
lt
gt
apos
quot
) is always treated as
data. (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.
4.4.3 Included If Validating
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 parser 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.
4.4.4 Forbidden
The following are forbidden, and constitute
fatal
errors:
the appearance of a reference to an
unparsed entity
the appearance of any character or general-entity reference in the
DTD except within an
EntityValue
or
AttValue
a reference to an external entity in an attribute value.
4.4.5 Included in Literal
When an
entity reference
appears in an
attribute value, or a parameter entity reference appears in a literal entity
value, its
replacement text
is
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
is always treated as a normal data character and will not terminate the
literal.
For example, this is well-formed:


while this is not:


4.4.6 Notify
When the name of an
unparsed
entity
appears as a token in the
value of an attribute of declared type
ENTITY
or
ENTITIES
a validating processor must inform the
application of the
system
and
public
(if any)
identifiers for both the entity and its associated
notation
4.4.7 Bypassed
When a general entity reference appears in the
EntityValue
in an entity declaration,
it is bypassed and left as is.
4.4.8 Included as PE
Just as with external parsed entities, parameter entities
need only be
included if
validating
When a parameter-entity reference is recognized in the DTD
and included, its
replacement
text
is enlarged by the attachment of one leading and one following
space (#x20) character; the intent is to constrain the replacement
text of parameter
entities to contain an integral number of grammatical tokens in the DTD.
4.5 Construction of Internal Entity Replacement Text
In discussing the treatment
of internal entities, it is
useful to distinguish two forms of the entity's value.
The
literal
entity value
is the quoted string actually
present in the entity declaration, corresponding to the
non-terminal
EntityValue
The
replacement
text
is the content of the entity, after
replacement of character references and 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
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:


© 1947 %pub;. &rights;" >
then the replacement text for the entity "
book
" is:
La Peste: Albert Camus,
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
".
4.6 Predefined Entities
Entity and character
references can 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 in question 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, as shown below.





Note that the
and
characters
in the declarations of "
lt
" and "
amp
are doubly escaped to meet the requirement that entity replacement
be well-formed.
4.7 Notation Declarations
Notations
identify by
name the format of
unparsed
entities
, the
format of elements which bear a notation attribute,
or the application to which
processing instruction
is
addressed.
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.
Notation Declarations
[82]
NotationDecl
::=
'Name
ExternalID
PublicID
? '>'
[83]
PublicID
::=
'PUBLIC'
PubidLiteral
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.)
4.8 Document Entity
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.
5. Conformance
5.1 Validating and Non-Validating Processors
Conforming
XML processors
fall into two
classes: validating and non-validating.
Validating and non-validating processors alike must report
violations of this specification's well-formedness constraints
in the content of the
document entity
and any
other
parsed entities
that
they read.
Validating processors
must report
violations of the constraints expressed by the declarations in the
DTD
, and
failures to fulfill the validity constraints given
in this specification.

To accomplish this, validating XML processors must read and process the entire
DTD and all external parsed entities referenced in the document.
Non-validating processors are required to check only the
document entity
, including
the entire internal DTD subset, for well-formedness.
While they are not required to check the document for validity,
they are required to
process
all the declarations they read in the
internal DTD subset and in any parameter entity that they
read, up to the first reference
to a parameter entity that they do
not
read; that is to
say, they must
use the information in those declarations to
normalize
attribute values,
include
the replacement text of
internal entities, and supply
default attribute values

They must not
process
entity declarations
or
attribute-list declarations
encountered after a reference to a parameter entity that is not
read, since the entity may have contained overriding declarations.
5.2 Using XML Processors
The behavior of a validating XML processor is highly predictable; it
must read every piece of a document and report all well-formedness and
validity violations.
Less is required of a non-validating processor; it need not read any
part of the document other than the document entity.
This has two effects that may be important to users of XML processors:
Certain well-formedness errors, specifically those that require
reading external entities, may not be detected by a non-validating processor.
Examples include the constraints entitled
Entity Declared
Parsed Entity
, and
No Recursion
, as well
as some of the cases described as
forbidden
in
4.4 XML Processor Treatment of Entities and References
".
The information passed from the processor to the application may
vary, depending on whether the processor reads
parameter and external entities.
For example, a non-validating processor may not
normalize
attribute values,
include
the replacement text of
internal entities, or supply
default attribute values
where doing so depends on having read declarations in
external or parameter entities.
For maximum reliability in interoperating between different XML
processors, applications which use non-validating processors should not
rely on any behaviors not required of such processors.
Applications which require facilities such as the use of default
attributes or internal entities which are declared in external
entities should use validating XML processors.
6. Notation
The formal grammar of XML is given in this specification using a simple
Extended Backus-Naur Form (EBNF) notation. Each rule in the grammar defines
one symbol, in the form
symbol ::= expression
Symbols are written with an initial capital letter if they are
defined by a regular expression, or with an initial lower case letter
otherwise.
Literal strings are quoted.
Within the expression on the right-hand side of a rule, the following
expressions are used to match strings of one or more characters:
#xN
where
is a hexadecimal integer, the
expression matches the character in ISO/IEC 10646 whose canonical
(UCS-4)
code value, when interpreted as an unsigned binary number, has
the value indicated. The number of leading zeros in the
#xN
form is insignificant; the number of leading
zeros in the corresponding code value
is governed by the character
encoding in use and is not significant for XML.
[a-zA-Z]
[#xN-#xN]
matches any
character
with a value in the range(s) indicated (inclusive).
[^a-z]
[^#xN-#xN]
matches any
character
with a value
outside
the
range indicated.
[^abc]
[^#xN#xN#xN]
matches any
character
with a value not among the characters given.
"string"
matches a literal string
matching
that given inside the double quotes.
'string'
matches a literal string
matching
that given inside the single quotes.
These symbols may be combined to match more complex patterns as follows,
where
and
represent simple expressions:
expression
expression
is treated as a unit
and may be combined as described in this list.
A?
matches
or nothing; optional
A B
matches
followed by
A | B
matches
or
but not both.
A - B
matches any string that matches
but does not match
A+
matches one or more occurrences of
A*
matches zero or more occurrences of
Other notations used in the productions are:
/* ... */
comment.
[ wfc: ... ]
well-formedness constraint; this identifies by name a
constraint on
well-formed
documents
associated with a production.
[ vc: ... ]
validity constraint; this identifies by name a constraint on
valid
documents associated with
a production.
Appendices
A. References
A.1 Normative References
IANA
(Internet Assigned Numbers Authority)
Official Names for
Character Sets
ed. Keld Simonsen et al.
See
ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets
IETF RFC 1766
IETF (Internet Engineering Task Force).
RFC 1766: Tags for the Identification of Languages
ed. H. Alvestrand.
1995.
ISO 639
(International Organization for Standardization).
ISO 639:1988 (E).
Code for the representation of names of languages.
[Geneva]: International Organization 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 for
Standardization, 1997.
ISO/IEC 10646
ISO
(International Organization for Standardization).
ISO/IEC 10646-1993 (E). Information technology -- Universal
Multiple-Octet Coded Character Set (UCS) -- Part 1:
Architecture and Basic Multilingual Plane.
[Geneva]: International Organization for
Standardization, 1993 (plus amendments AM 1 through AM 7).
Unicode
The Unicode Consortium.
The Unicode Standard, Version 2.0.
Reading, Mass.: Addison-Wesley Developers Press, 1996.
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.
Berners-Lee et al.
Berners-Lee, T., R. Fielding, and L. Masinter.
Uniform Resource Identifiers (URI): Generic Syntax and
Semantics
1997.
(Work in progress; see updates to RFC1738.)
Brüggemann-Klein
Brüggemann-Klein, Anne.
Regular Expressions into Finite Automata
Extended abstract in I. Simon, Hrsg., LATIN 1992,
S. 97-98. Springer-Verlag, Berlin 1992.
Full Version in Theoretical Computer Science 120: 197-213, 1993.
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.
Clark
James Clark.
Comparison of SGML and XML. See
IETF RFC1738
IETF (Internet Engineering Task Force).
RFC 1738: Uniform Resource Locators (URL)
ed. T. Berners-Lee, L. Masinter, M. McCahill.
1994.
IETF RFC1808
IETF (Internet Engineering Task Force).
RFC 1808: Relative Uniform Resource Locators
ed. R. Fielding.
1995.
IETF RFC2141
IETF (Internet Engineering Task Force).
RFC 2141: URN Syntax
ed. R. Moats.
1997.
ISO 8879
ISO
(International Organization for Standardization).
ISO 8879: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 for Standardization).
ISO/IEC 10744-1992 (E). Information technology --
Hypermedia/Time-based Structuring Language (HyTime).
[Geneva]: International Organization for
Standardization, 1992.
Extended Facilities Annexe.
[Geneva]: International Organization for
Standardization, 1996.
B. Character Classes
Following the characteristics defined in the Unicode standard,
characters are classed as base characters (among others, these
contain the alphabetic characters of the Latin alphabet, without
diacritics), ideographic characters, and combining characters (among
others, this class contains most diacritics); these classes combine
to form the class of letters. Digits and extenders are
also distinguished.
Characters
[84]
Letter
::=
BaseChar
Ideographic
[85]
BaseChar
::=
[#x0041-#x005A]
| [#x0061-#x007A]
| [#x00C0-#x00D6]
| [#x00D8-#x00F6]
| [#x00F8-#x00FF]
| [#x0100-#x0131]
| [#x0134-#x013E]
| [#x0141-#x0148]
| [#x014A-#x017E]
| [#x0180-#x01C3]
| [#x01CD-#x01F0]
| [#x01F4-#x01F5]
| [#x01FA-#x0217]
| [#x0250-#x02A8]
| [#x02BB-#x02C1]
| #x0386
| [#x0388-#x038A]
| #x038C
| [#x038E-#x03A1]
| [#x03A3-#x03CE]
| [#x03D0-#x03D6]
| #x03DA
| #x03DC
| #x03DE
| #x03E0
| [#x03E2-#x03F3]
| [#x0401-#x040C]
| [#x040E-#x044F]
| [#x0451-#x045C]
| [#x045E-#x0481]
| [#x0490-#x04C4]
| [#x04C7-#x04C8]
| [#x04CB-#x04CC]
| [#x04D0-#x04EB]
| [#x04EE-#x04F5]
| [#x04F8-#x04F9]
| [#x0531-#x0556]
| #x0559
| [#x0561-#x0586]
| [#x05D0-#x05EA]
| [#x05F0-#x05F2]
| [#x0621-#x063A]
| [#x0641-#x064A]
| [#x0671-#x06B7]
| [#x06BA-#x06BE]
| [#x06C0-#x06CE]
| [#x06D0-#x06D3]
| #x06D5
| [#x06E5-#x06E6]
| [#x0905-#x0939]
| #x093D
| [#x0958-#x0961]
| [#x0985-#x098C]
| [#x098F-#x0990]
| [#x0993-#x09A8]
| [#x09AA-#x09B0]
| #x09B2
| [#x09B6-#x09B9]
| [#x09DC-#x09DD]
| [#x09DF-#x09E1]
| [#x09F0-#x09F1]
| [#x0A05-#x0A0A]
| [#x0A0F-#x0A10]
| [#x0A13-#x0A28]
| [#x0A2A-#x0A30]
| [#x0A32-#x0A33]
| [#x0A35-#x0A36]
| [#x0A38-#x0A39]
| [#x0A59-#x0A5C]
| #x0A5E
| [#x0A72-#x0A74]
| [#x0A85-#x0A8B]
| #x0A8D
| [#x0A8F-#x0A91]
| [#x0A93-#x0AA8]
| [#x0AAA-#x0AB0]
| [#x0AB2-#x0AB3]
| [#x0AB5-#x0AB9]
| #x0ABD
| #x0AE0
| [#x0B05-#x0B0C]
| [#x0B0F-#x0B10]
| [#x0B13-#x0B28]
| [#x0B2A-#x0B30]
| [#x0B32-#x0B33]
| [#x0B36-#x0B39]
| #x0B3D
| [#x0B5C-#x0B5D]
| [#x0B5F-#x0B61]
| [#x0B85-#x0B8A]
| [#x0B8E-#x0B90]
| [#x0B92-#x0B95]
| [#x0B99-#x0B9A]
| #x0B9C
| [#x0B9E-#x0B9F]
| [#x0BA3-#x0BA4]
| [#x0BA8-#x0BAA]
| [#x0BAE-#x0BB5]
| [#x0BB7-#x0BB9]
| [#x0C05-#x0C0C]
| [#x0C0E-#x0C10]
| [#x0C12-#x0C28]
| [#x0C2A-#x0C33]
| [#x0C35-#x0C39]
| [#x0C60-#x0C61]
| [#x0C85-#x0C8C]
| [#x0C8E-#x0C90]
| [#x0C92-#x0CA8]
| [#x0CAA-#x0CB3]
| [#x0CB5-#x0CB9]
| #x0CDE
| [#x0CE0-#x0CE1]
| [#x0D05-#x0D0C]
| [#x0D0E-#x0D10]
| [#x0D12-#x0D28]
| [#x0D2A-#x0D39]
| [#x0D60-#x0D61]
| [#x0E01-#x0E2E]
| #x0E30
| [#x0E32-#x0E33]
| [#x0E40-#x0E45]
| [#x0E81-#x0E82]
| #x0E84
| [#x0E87-#x0E88]
| #x0E8A
| #x0E8D
| [#x0E94-#x0E97]
| [#x0E99-#x0E9F]
| [#x0EA1-#x0EA3]
| #x0EA5
| #x0EA7
| [#x0EAA-#x0EAB]
| [#x0EAD-#x0EAE]
| #x0EB0
| [#x0EB2-#x0EB3]
| #x0EBD
| [#x0EC0-#x0EC4]
| [#x0F40-#x0F47]
| [#x0F49-#x0F69]
| [#x10A0-#x10C5]
| [#x10D0-#x10F6]
| #x1100
| [#x1102-#x1103]
| [#x1105-#x1107]
| #x1109
| [#x110B-#x110C]
| [#x110E-#x1112]
| #x113C
| #x113E
| #x1140
| #x114C
| #x114E
| #x1150
| [#x1154-#x1155]
| #x1159
| [#x115F-#x1161]
| #x1163
| #x1165
| #x1167
| #x1169
| [#x116D-#x116E]
| [#x1172-#x1173]
| #x1175
| #x119E
| #x11A8
| #x11AB
| [#x11AE-#x11AF]
| [#x11B7-#x11B8]
| #x11BA
| [#x11BC-#x11C2]
| #x11EB
| #x11F0
| #x11F9
| [#x1E00-#x1E9B]
| [#x1EA0-#x1EF9]
| [#x1F00-#x1F15]
| [#x1F18-#x1F1D]
| [#x1F20-#x1F45]
| [#x1F48-#x1F4D]
| [#x1F50-#x1F57]
| #x1F59
| #x1F5B
| #x1F5D
| [#x1F5F-#x1F7D]
| [#x1F80-#x1FB4]
| [#x1FB6-#x1FBC]
| #x1FBE
| [#x1FC2-#x1FC4]
| [#x1FC6-#x1FCC]
| [#x1FD0-#x1FD3]
| [#x1FD6-#x1FDB]
| [#x1FE0-#x1FEC]
| [#x1FF2-#x1FF4]
| [#x1FF6-#x1FFC]
| #x2126
| [#x212A-#x212B]
| #x212E
| [#x2180-#x2182]
| [#x3041-#x3094]
| [#x30A1-#x30FA]
| [#x3105-#x312C]
| [#xAC00-#xD7A3]
[86]
Ideographic
::=
[#x4E00-#x9FA5]
| #x3007
| [#x3021-#x3029]
[87]
CombiningChar
::=
[#x0300-#x0345]
| [#x0360-#x0361]
| [#x0483-#x0486]
| [#x0591-#x05A1]
| [#x05A3-#x05B9]
| [#x05BB-#x05BD]
| #x05BF
| [#x05C1-#x05C2]
| #x05C4
| [#x064B-#x0652]
| #x0670
| [#x06D6-#x06DC]
| [#x06DD-#x06DF]
| [#x06E0-#x06E4]
| [#x06E7-#x06E8]
| [#x06EA-#x06ED]
| [#x0901-#x0903]
| #x093C
| [#x093E-#x094C]
| #x094D
| [#x0951-#x0954]
| [#x0962-#x0963]
| [#x0981-#x0983]
| #x09BC
| #x09BE
| #x09BF
| [#x09C0-#x09C4]
| [#x09C7-#x09C8]
| [#x09CB-#x09CD]
| #x09D7
| [#x09E2-#x09E3]
| #x0A02
| #x0A3C
| #x0A3E
| #x0A3F
| [#x0A40-#x0A42]
| [#x0A47-#x0A48]
| [#x0A4B-#x0A4D]
| [#x0A70-#x0A71]
| [#x0A81-#x0A83]
| #x0ABC
| [#x0ABE-#x0AC5]
| [#x0AC7-#x0AC9]
| [#x0ACB-#x0ACD]
| [#x0B01-#x0B03]
| #x0B3C
| [#x0B3E-#x0B43]
| [#x0B47-#x0B48]
| [#x0B4B-#x0B4D]
| [#x0B56-#x0B57]
| [#x0B82-#x0B83]
| [#x0BBE-#x0BC2]
| [#x0BC6-#x0BC8]
| [#x0BCA-#x0BCD]
| #x0BD7
| [#x0C01-#x0C03]
| [#x0C3E-#x0C44]
| [#x0C46-#x0C48]
| [#x0C4A-#x0C4D]
| [#x0C55-#x0C56]
| [#x0C82-#x0C83]
| [#x0CBE-#x0CC4]
| [#x0CC6-#x0CC8]
| [#x0CCA-#x0CCD]
| [#x0CD5-#x0CD6]
| [#x0D02-#x0D03]
| [#x0D3E-#x0D43]
| [#x0D46-#x0D48]
| [#x0D4A-#x0D4D]
| #x0D57
| #x0E31
| [#x0E34-#x0E3A]
| [#x0E47-#x0E4E]
| #x0EB1
| [#x0EB4-#x0EB9]
| [#x0EBB-#x0EBC]
| [#x0EC8-#x0ECD]
| [#x0F18-#x0F19]
| #x0F35
| #x0F37
| #x0F39
| #x0F3E
| #x0F3F
| [#x0F71-#x0F84]
| [#x0F86-#x0F8B]
| [#x0F90-#x0F95]
| #x0F97
| [#x0F99-#x0FAD]
| [#x0FB1-#x0FB7]
| #x0FB9
| [#x20D0-#x20DC]
| #x20E1
| [#x302A-#x302F]
| #x3099
| #x309A
[88]
Digit
::=
[#x0030-#x0039]
| [#x0660-#x0669]
| [#x06F0-#x06F9]
| [#x0966-#x096F]
| [#x09E6-#x09EF]
| [#x0A66-#x0A6F]
| [#x0AE6-#x0AEF]
| [#x0B66-#x0B6F]
| [#x0BE7-#x0BEF]
| [#x0C66-#x0C6F]
| [#x0CE6-#x0CEF]
| [#x0D66-#x0D6F]
| [#x0E50-#x0E59]
| [#x0ED0-#x0ED9]
| [#x0F20-#x0F29]
[89]
Extender
::=
#x00B7
| #x02D0
| #x02D1
| #x0387
| #x0640
| #x0E46
| #x0EC6
| #x3005
| [#x3031-#x3035]
| [#x309D-#x309E]
| [#x30FC-#x30FE]
The character classes defined here can be derived from the
Unicode character database as follows:
Name start characters must have one of the categories Ll, Lu,
Lo, Lt, Nl.
Name characters other than Name-start characters
must have one of the categories Mc, Me, Mn, Lm, or Nd.
Characters in the compatibility area (i.e. with character code
greater than #xF900 and less than #xFFFE) are not allowed in XML
names.
Characters which have a font or compatibility decomposition (i.e. those
with a "compatibility formatting tag" in field 5 of the database --
marked by field 5 beginning with a "<") are not allowed.
The following characters are treated as name-start characters
rather than name characters, because the property file classifies
them as Alphabetic: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.
Characters #x20DD-#x20E0 are excluded (in accordance with
Unicode, section 5.14).
Character #x00B7 is classified as an extender, because the
property list so identifies it.
Character #x0387 is added as a name character, because #x00B7
is its canonical equivalent.
Characters ':' and '_' are allowed as name-start characters.
Characters '-' and '.' are allowed as name characters.
C. XML and SGML (Non-Normative)
XML is designed to be a subset of SGML, in that every
valid
XML document should also be a
conformant SGML document.
For a detailed comparison of the additional restrictions that XML places on
documents beyond those of SGML, see
[Clark]
D. Expansion of Entity and Character References (Non-Normative)
This appendix contains some examples illustrating the
sequence of entity- and character-reference recognition and
expansion, as specified in "
4.4 XML Processor Treatment of Entities and References
".
If the DTD contains the declaration
An ampersand (&#38;) may be escaped
numerically (&#38;#38;) or with a general entity
(&amp;).

An ampersand (&) may be escaped
numerically (&#38;) or with a general entity
(&amp;).

their relative
priority and the preferred method of handling conflict should be
specified as part of the higher-level protocol used to deliver XML.
Rules for the relative priority of the internal label and the
MIME-type label in an external header, for example, should be part of the
RFC document defining the text/xml and application/xml MIME types. In
the interests of interoperability, however, the following rules
are recommended.
If an XML entity is in a file, the Byte-Order Mark
and encoding-declaration PI are used (if present) to determine the
character encoding. All other heuristics and sources of information
are solely for error recovery.
If an XML entity is delivered with a
MIME type of text/xml, then the
charset
parameter
on the MIME type determines the
character encoding method; all other heuristics and sources of
information are solely for error recovery.
If an XML entity is delivered
with a
MIME type of application/xml, then the Byte-Order Mark and
encoding-declaration PI are used (if present) to determine the
character encoding. All other heuristics and sources of
information are solely for error recovery.
These rules apply only in the absence of protocol-level documentation;
in particular, when the MIME types text/xml and application/xml are
defined, the recommendations of the relevant RFC will supersede
these rules.
G. W3C XML Working Group (Non-Normative)
This specification was prepared and approved for publication by the
W3C XML Working Group (WG). WG approval of this specification does
not necessarily imply that all WG members voted for its approval.
The current and former members of the XML WG are:
Jon Bosak, Sun (Chair);
James Clark (Technical Lead);
Tim Bray, Textuality and Netscape (XML Co-editor);
Jean Paoli, Microsoft (XML Co-editor);
C. M. Sperberg-McQueen, U. of Ill. (XML
Co-editor);
Dan Connolly, W3C (W3C Liaison);
Paula Angerstein, Texcel;
Steve DeRose, INSO;
Dave Hollander, HP;
Eliot Kimber, ISOGEN;
Eve Maler, ArborText;
Tom Magliery, NCSA;
Murray Maloney, Muzmo and Grif;
Makoto Murata, Fuji Xerox Information Systems;
Joel Nava, Adobe;
Conleth O'Connell, Vignette;
Peter Sharpe, SoftQuad;
John Tigue, DataChannel
W3C
MIT
INRIA
Keio
), All Rights Reserved. W3C
liability,
trademark
document
use
and
software
licensing
rules apply.