本文档完整地描述了可扩展标记语言(Extensible Markup Language，XML)，它是标准通用标记语言(Standard Generic Markup Language，SGML)的一个子集。其目的在于使得在Web上能以现有超文本标记语言(Hypertext Markup Language，HTML)的使用方式提供，接收和处理通用的SGML成为可能。XML的设计既考虑了实现的方便性，同时也顾及了与SGML和HTML的互操作性。
本文档已由W3C组织成员和其他相关各方审阅，并已被组织理事批准为W3C建议。这是一个稳定的文档，可以用作参考材料，也可以作为其他文档的正式参考文献。W3C在建议制定过程中的作用是吸引对本规范的注意并促进它的广泛使用。这能增强Web的功能和互操作性。
本文档规定了一种用于World Wide Web的语法，此语法是通过取一个业已存在并已广泛使用的文本处理国际标准(标准通用标记语言，经增补和更正的ISO 8879:1986(E))的子集而创建的。它是W3C XML行动组(XML Activity)的工作成果，关于XML行动组的详细信息可以在http://www.w3.org/XML找到。在http://www.w3.org/TR可以找到现有W3C建议和其他技术文档的一个列表。
本规范中使用了[Berners-Lee等人]定义的一个术语URI，他们正在从事的的工作将更新[IETF RFC1738]和[IETF RFC1808]。
本规范的已知错误列表可以在http://www.w3.org/XML/xml-19980210-errata找到。
请将本文档中的错误报告给xml-editor@w3.org。
1. 绪论
1.1
开发者和开发目标
1.2
术语
2.
文件
2.1
规范的XML文件
2.2
字符
2.3
通用语法成分
2.4
字符数据和标记
2.5
注释
2.6
处理指令
2.7
CDATA段
2.8
序和文件类型声明
2.9
独立文件声明
2.10
空白处理
2.11
行尾处理
2.12
语言标识
3.
逻辑结构
3.1
起始标签，结束标签和空元素标签
3.2
元素类型声明
3.2.1
元素型内容
3.2.2
混合型内容
3.3
属性表声明
3.3.1
属性类型
3.3.2
属性的缺省值
3.3.3
属性-值对的规范化
3.4
条件段
4.
物理结构
4.1
字符和实体引用
4.2
实体声明
4.2.1
内部实体
4.2.2
外部实体
4.3
已析实体
4.3.1
文本声明
4.3.2
规范的已析实体
4.3.3
实体中的字符编码
4.4
XML处理器对实体和引用的处理
4.4.1
不被识别
4.4.2
被包含
4.4.3
进行验证时被包含
4.4.4
被禁止
4.4.5
被包含在常量中
4.4.6
通知
4.4.7
不处理
4.4.8
作为PE被包含
4.5
内部实体置换文本的构建
4.6
预定义实体
4.7
记法声明
4.8
文件实体
5.
一致性
5.1
进行验证和不进行验证的处理器
5.2
使用XML处理器
6.
记法
A. 参考文献
A.1
正式参考文献
A.2
其他参考文献
B.
字符的分类
C.
XML和SGML(非正式)
D.
实体和字符引用的展开(非正式)
E.
确定型内容模型(非正式)
F.
字符编码的自动检测(非正式)
G.
W3C
XML工作组(非正式)
可扩展标记语言，缩写为XML，描述了一类称为XML文件的数据对象，同时也部分地描述了处理这些数据对象的计算机程序的动作。XML是SGML(标准通用标记语言[ISO 8879])针对特定应用领域的一个子集，或者说是SGML的一种受限形式。根据定义，XML文件是合乎规范的SGML文件。
XML文件由称为实体的存储单元组成，实体可以包含已析数据或未析数据。已析数据由字符组成，其中一些字符组成字符数据，另一些字符组成标记。标记中包含了对文件存储格式(storage layout)和逻辑结构的描述。XML提供了一种机制用于约束存储格式和逻辑结构。
称为XML处理器的软件模块用于读取XML文件，存取其中的内容和结构。XML处理器被设想为是为另一个称为应用的模块作处理。本规范从XML处理器应如何读取XML数据以及应向应用提供哪些信息的这两个方面，描述了要求XML处理器作出的动作。
XML由XML工作组(原先的SGML编辑审查委员会)开发，此工作组由World Wide Web Consortium(W3C)在1996年主持成立。工作组由Sun Microsystems的Jon Bosak负责，同样由W3C组织的XML SIG(Special Interest Group)(原先的SGML工作组)积极参与了XML工作组的工作。XML工作组的成员在附录中给出。工作组与W3C的联系人是Dan Connolly。
XML的设计目标如下：
本规范与其他相关的标准一起(Unicode和ISO/IEC 10646定义了字符集，Internet RFC1766定义了语言识别码，ISO 639定义了语言名称代码，ISO 3166定义了国家名称代码)，提供了理解XML版本1.0和构建相应计算机处理程序所需的所有信息。
在完整保留所有文本和法律注意事项的前提下，本版本的XML规范可以自由分发。
用于描述 XML 文件的术语在此规范的正文中定义。在这些定义中以及描述一个XML处理器的动作时，使用了下表中的术语：
如果一个数据对象满足本规范中规范的定义时，它是一个XML文件。一个规范的XML文件可以更进一步是有效的如果它满足某些进一步的约束。
每一个XML文件都有逻辑和物理结构。物理上而言，文件由称为实体的单元组成。一个实体可以引用(refer)其他实体，将它们包含在文件中。文件开始于"根(root)"或文件实体中。逻辑上而言，文件由声明，元素，注释，字符引用和处理指令组成，所有这些都在文件中用显式标记指明。逻辑和物理结构必须如"4.3.2 规范的已析实体"中所描述那样严格地嵌套。
| 文件 | ||||
|
匹配document产生式意味着：
这样做的结果是，对于每一个非根的元素C，文件中另有一个元素P，C在P的内容中，而不在其他任何被P所包含的元素的内容中。P被称为C的父元素(parent)，而C被称为P的子元素(child)。
一个已析实体包含文本(text)，文本是一个字符(character)序列，可以表示标记或字符数据。一个字符是ISO/IEC 10646[ISO/IEC 10646]中定义的文本最小单元。合法的字符包括制表符，回车，换行以及Unicode和ISO/IEC 10646中定义的合法的图形字符。不提倡使用[Unicode]6.8节中定义的"兼容字符(compatibility characters)"。
| 字符范围 | ||||||
|
将字符代码编码成位模型的机制各个实体间可能会有所不同。所有的XML处理器必须接受10646中的UTF-8和UTF-16编码；用于指出所用编码或指定使用其他编码的机制在后面的"4.3.3 实体中的字符编码"中讨论。
本节中定义了一些在文法中广泛使用的符号。
S(空白)包括一个或多个空格字符(#x20)，回车，换行和制表符。
| 空白 | ||||
|
为方便起见，字符被分为字母，数字和其他字符三类。字母可以是字母表中的字母，或是一个音节基字符(syllabic base character)后跟一个或多个组合字符，也可以是一个表意字符。在"B. 字符的分类"中给出了每一类字符的完整定义。
名字(name)是以字母或某些标点符号开头的记号，后跟字母，数字，连字符，下划线，冒号或句号，这些符号统称为命名字符(name
character)。以"xml"或其他任何匹配 (('X'|'x') ('M'|'m')
('L'|'l')) 的字符串开头的名字，被保留用于本规范的此版本或后续版本的标准化。
注意：XML名字中的冒号被保留用于名字空间(name space)实验。它的含义有待于日后标准化，那时那些将冒号用于实验目的的文件有可能需要更新。(不保证XML采用的任何名字空间机制会实际采用冒号作为定界符。)实际上，这意味着除非用于名字空间实验，XML文件作者不应该在XML名字中使用冒号，但XML处理器应该接受冒号作为一个命名字符。
Nmtoken(名字记号，name
token)是任何命名字符的混合体。
| 名字和记号 | ||||||||||||||||||||
|
常量数据是任何用引号括起的字符串，不包括用作定界符的引号。常量用于指明内部实体的内容(EntityValue)，属性值(AttValue)，以及外部标识符(SystemLiteral)。注意，对SystemLiteral的语法分析可以不扫描标记。
| 常量 | ||||||||||||||||||||||||||||
|
文本由字符数据和标记混合构成。标记包括起始标签，结束标签，空元素标签，实体引用，字符引用，注释，CDATA段定界符，文件类型声明和处理指令。
"and"号(&)和左尖括号(<)只有作为标记定界符，或在注释，处理指令，或CDATA段中时才能以常量形式出现。它们在一个内部实体声明的常量实体数值中也是合法的，参见"4.3.2 规范的已析实体"。如果在其他地方需要用到这两个字符，它们必须用数值式字符引用来转义或分别用字符串"&"和"<"表示。右尖括号(>)可以用">"表示，而当它在内容中的字符串"]]>"中出现，但此字符串不表示一个CDATA段的结束时，出于兼容性考虑，必须用">"或一个字符引用转义得到。
在一个元素的内容中，字符数据可以是不包括任何标记的起始定界符的任意字符串。在一个CDATA段中，字符数据可以是不包括CDATA段结束定界符"]]>"的任意字符串。
为了允许在属性值中包含单引号和双引号，省略符或称单引号(')可以被表示为"'"，而双引号(")可以被表示为"""。
| 字符数据 | ||||
|
注释可以在其他标记之外的文件中的任何位置出现。另外，它们可以在文件类型声明中文法允许的地方出现。它们不是文件字符数据的一部分，XML处理器可以，但不是必须，允许一个应用检索注释文本。出于兼容性考虑，字符串"--"(双连字符)不能在注释中出现。
| 注释 | ||||
|
注释的一个例子：
<!-- declarations for <head> & <body> --> |
| 处理指令 | ||||||||
|
PI不是文件字符数据的一部分，但必须传递给应用。PI以用于指示传递给哪个应用的目标(PITarget)开头，目标名字"XML"，"xml"，等等，保留用于本规范的此版本或后续版本的标准化。XML记法机制可以用于PI目标的形式化声明。
CDATA段可以出现在字符数据可以出现的任何地方，它们用于转义包含会被识别为标记的字符串的文本块。CDATA段以字符串"<![CDATA["开始，以字符串"]]>"结束：
| CDATA段 | ||||||||||||||||
|
在一个CDATA段内，只有CDEnd字符串被识别为标记，因此左尖括号和"&"可以以它们的常量形式出现，不需要(也不能)被换码为"<"和"&"。CDATA段不能嵌套。
一个CDATA段的例子，其中"<greeting>"和"</greeting>"被识别为字符数据，而不是标记：
<![CDATA[<greeting>Hello, world!</greeting>]]> |
XML文件可以，也应该以一个XML声明开始，其中指明了所用XML的版本。 例如，以下是一个完整的XML文件，它是规范的，但不是有效的：
<?xml version="1.0"?> |
下面这个也同样：
<greeting>Hello, world!</greeting> |
版本号"1.0"应该用于表明对与规范此版本相一致，如果使用了值"1.0"但又与本规范的此版本不一致，那么这是文件的一个错误。XML工作组打算赋予本规范的后续版本不同于"1.0"的数值，但这并不代表开发后续版本的承诺，也不代表如果有后续版本，会使用任何特殊的命名方案的承诺。因为不排除有后续版本的可能性，提供了本构造(construct)作为一旦需要时进行自动版本识别的手段。当处理器收到的文件标有它们不支持的版本时，可以给出一个错误。
XML文件中标记的功能是描述文件的存储格式和逻辑结构，并将属性-值对和逻辑结构关联起来。XML提供一种称为文件类型声明的机制，用于定义对逻辑结构的约束，支持预定义存储单元的使用。如果一个XML文件有相应的文件类型声明并且它遵循其中的约束，则称它是有效的(valid)。
文件类型声明必须位于文件第一个元素之前。
| 序 | ||||||||||||||||||||||||
|
XML文件类型声明包含或指向xmlrkupdecl">标记声明，标记声明提供某一类文件的文法。这种文法被称为文件类型定义(document type difinition，DTD)。文件类型定义可以指向一个外部子集(一种特殊类型的外部实体)，或者可以在一个内部子集中直接包含标记声明，或者两者兼用。一个文件的文件类型定义由这两个子集合在一起组成。
标记声明可以是元素类型声明，属性表声明，实体声明，或是记法声明。这些声明可以如下面规范性和有效性约束中所述，全部或部分地包含在参数实体中，完整的信息参见"4. 物理结构"。
| 文件类型定义 | ||||||||||||||||||
|
标记声明可以全部或部分地由参数实体的置换文本组成。本规范后面的各个非终结符(elementdecl，AttlistDecl，等等)产生式描述的是在所有的参数实体被包含(include)之后的声明。
有效性约束: 根元素类型(Root Element Type)
文件类型声明中的Name必须匹配根元素的类型。
有效性约束: 严格的声明/PE嵌套
参数实体的置换文本必须用标记声明严格嵌套。即，如果一个标记声明(上面的markupdecl)的第一个或最后一个字符被包含于一个参数实体引用的置换文本中，两者必须都在此置换文本中。
规范性约束: 内部子集中的PE
在内部DTD子集中，参数实体引用只能出现在标记声明可以出现的地方，而不能在标记声明内部出现。(这个约束不适用于出现在外部参数实体内的引用，也不适用于外部子集。)
同内部子集一样，外部子集和任何DTD中引用的外部参数实体，必须由一系列被非终结符markupdecl所允许的完整的标记声明组成，其中可以夹杂空白字符或参数实体引用。但是，外部子集和外部参数实体的部分内容可以通过使用条件段(conditional
section)被有条件地忽略，在内部子集中则不允许这么做。
| 外部子集 | ||||||||
|
外部子集和外部参数实体与内部实体不同之处还在于：在它们内，参数实体引用不仅可以出现在标记声明间，还可以出现在标记声明内。
有文件类型声明的XML文件的例子：
<?xml version="1.0"?> |
系统标识符"hello.dtd"给出了文件DTD的URI。
声明也可以如同下面这个例子一样直接(locally)给出：
<?xml version="1.0" encoding="UTF-8" ?> |
如果同时使用外部和内部子集，子集子集被看成出现在外部子集之前，这意味着内部子集中的实体和属性表声明的优先级要比在外部子集中的高。
当文件从XML处理器递给应用时，标记声明可以影响它的内容，属性缺省值和实体声明是其中的例子。可以作为XML声明成分的独立文件声明，指明了对于文件实体而言，是否存在外部的声明。
| 独立文件声明 | ||||||
|
在一个独立文件声明中，值"yes"表示对于文件实体没有外部标记声明(不论是在DTD外部子集中，还是在由内部实体引用的外部参数实体中)会影响从XML处理器传递给应用的信息。值"no"表示有或可能有这样的外部标记声明。注意独立文件声明只是表示外部声明的存在，如果文件中存在对外部实体的引用，而这些实体已在内部声明时，不影响它的独立状态。
如果不存在外部标记声明，独立文件声明没有意义。如果存在外部标记声明，但没有独立文件声明，就假定取值"no"。
某些网络传输应用也许需要独立的文件，任何满足standalone="no"的XML文件可以通过一定的算法转换为独立文件。
有效性约束: 独立文件声明
独立文件声明必须取值为"no"，如果任何外部标记声明中包含：
amp，lt，gt，apos，quot的)实体的声明，而对这些实体的引用出现在文件中的话。
具有独立文件声明的XML声明的例子：
<?xml version="1.0" standalone='yes'?> |
在编辑XML文件时，使用"空白"(空格，制表符，空行，在本规范中用非终结符S表示)来分开标记以获得更好的可读性是很方便的。通常在文件的交付版本中不想包含这些空白。另一方面，必须保留在交付版本中的有意义的空白是很常见的，如在诗歌和源码中的空白。
XML处理器必须始终把不是标记的所有字符传递给应用。一个进行验证的XML处理器必须同时通知应用这些字符中的那一些组成了出现在元素型内容中的空白。
可以在元素中附加一个名为xml:space的特殊属性，以通知应用应该保留此元素中的空白。在有效的文件中，此属性和其他属性一样，使用时必须声明。它必须被声明为枚举类型，只有"default"和"preserve"两个可能的值。例如：
<!ATTLIST poem xml:space (default|preserve) 'preserve'> |
"default"表示可以对此元素使用应用的缺省空白处理模式，"preserve"表示应用应该保留所有的空白。这适用于其所处元素的内容中的所有元素，除非被另一个xml:space属性的实例所覆盖。
任何文件的根元素被认为对应用的空白处理方式不作要求，除非它给此属性赋了值或将此属性声明为带缺省值。
为编辑的方便起见，存储XML已析实体的计算机文件经常用行来组织。通常这些行用回车符(#xD)和换行符(#xA)的一些组合来分隔。
为了使应用的工作简单化，对于一个外部已析实体或内部已析实体的常量实体值中包含的任何两字符常量序列"#xD#xA"或单独的常量#xD，XML处理器都应换成#xA传递给应用。(这可以通过在进行语法分析前将所有行分隔符规范成#xA而方便地实现。)
在进行文件处理时，标识出其内容所使用的自然或形式化语言经常是很有用的。可以在文件中插入一个名为xml:lang的特殊属性用于指出XML文件中任何元素的内容和属性所使用的语言。在有效的文件中，此属性和其他属性一样，使用时必须声明。此属性的值是[IETF
RFC 1766]，"语言标识码"中定义的语言标识符：
| 语言标识 | ||||||||||||||||||||||||
|
Langcode可以是下列值：
i-I-")开头。
x-"或"X-"开头，以保证它们不会和以后经IANA标准化或在IANA注册的名字相冲突。
可以有任意多个Subcode段，如果第一个子代码段存在，并且子代码由两个字母组成，那么此子代码必须是[ISO
3166]，"国家名称的表示码"中定义的国家代码。如果第一个子代码多于两个字母，那么它必须是在IANA注册的语言代码所表示的语言的子代码，除非它Langcode以前缀"x-"或"X-"开头。
习惯上用小写字母给出语言代码，用大写字母给出国家代码(如果有的话)。注意这些值与XML文件中的其他名字不同，是大小写无关的。
举例如下：
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p> |
xml:lang所表示的语言选择适用于它所处元素的所有属性和内容，除非被此内容中的元素内的另一个xml:lang的实例所覆盖。
xml:lang的一个简单声明可以采用如下形式：
xml:lang NMTOKEN #IMPLIED |
但是如果合适的话，也可以给出特定的缺省值。在一本供英国学生使用的法文诗歌集中，评注和注解使用英语，xml:lang属性可以这样声明：
<!ATTLIST poem xml:lang NMTOKEN 'fr'> |
每个XML文件包含一个或多个元素，它们的边界用起始标签和结束标签分隔，或者，对于空元素，用一个空元素标签分隔。每一个元素有一个用名字标识的类型，有时称之为它的"通用标识符(generic identifier)"(GI)，同时它可以有一个属性值说明(attribute specification)集。每一个属性值说明有一个名字和一个值。
| 元素 | ||||||||||||||||
|
除了那些开头匹配(('X'|'x')('M'|'m')('L'|'l'))的名字保留用于本规范的此版本和后继版本的标准化外，本规范不对元素类型和属性的语义，用法和名字(语法之外)作出限制。
规范性约束: 元素类型匹配
元素结束标签中的Name必须和起始标签中的元素类型相匹配。
有效性约束: 元素有效性
如果有一个与elementdecl相匹配的声明的Name与元素类型相匹配，且下述之一成立时，称此元素是有效的：
EMPTY相匹配，同时此元素没有内容。
children相匹配，同时子元素的序列属于内容模型中的正则表达式所产生的语言，在每对子元素间允许有空白(匹配非终结符S的字符)。
Mixed相匹配，同时内容由其类型匹配内容模型中的名字的字符数据和子元素组成。
ANY相匹配，同时每个子元素的类型均已声明。
| 起始标签 | ||||||||||||||||||||||||
|
起始标签和结束标签中的Name给出了元素的类型。Name-AttValue对被统称为元素的属性值说明，其中每一对中的Name被称为属性名，AttValue的内容(在'或"定界符间的文本)被称为属性值。
规范性约束: 唯一的属性值说明
一个属性名只能在同一个起始标签或空元素标签中出现一次。
有效性约束: 属性值类型
属性必须被声明，其值必须具有所声明的类型。(属性类型参见"3.3 属性表声明"。)
规范性约束: 无外部实体引用
属性值不能包含对外部实体直接或间接的实体引用。
规范性约束: 在属性值中没有<
在一个属性值中直接或间接引用的实体的置换文本(除了"<")不能包含<。
起始标签的一个例子：
<termdef id="dt-dog" term="dog"> |
由一个起始标签开始的每一个元素必须用一个结束标签标记其结束，结束标签中的名字必须与起始标签中给出的元素类型相同：
| 结束标签 | ||||
|
结束标签的一个例子：
</termdef> |
在起始标签和结束标签中的文本被称为元素的内容：
| 元素的内容 | ||||
|
如果元素的内容为空，它必须表示为一个起始标签紧跟一个结束标签或空元素标签。空元素标签则采用一种特殊的形式：
| 空元素标签 | ||||||
|
不论元素是否用关键字EMPTY声明，空元素标签都可以用于任何没有内容的元素。出于互操作性考虑，空元素必须用于，且只能用于声明为EMPTY的元素。
空元素的例子：
<IMG align="left" |
出于验证的目的，可以用元素类型和属性表声明限制XML文件中元素的结构。元素类型声明限制了元素的内容。
元素类型声明通常限制了子元素的类型。由用户选择，当声明提到的元素类型没有相应的声明时，XML处理器可以给出警告，但这不是一个错误。
| 元素类型声明 | ||||||||||
|
其中Name给出了所声明的元素类型。
有效性约束: 唯一的元素类型声明
元素类型只能声明一次。
元素类型声明的例子：
<!ELEMENT br EMPTY> |
当某一类型的元素只能包含用可选空白(匹配非终结符S)分隔的子元素(无字符数据)时，称此元素类型具有元素型内容。在这种情况下，有内容模型作为类型限制之一，内容模型是决定子元素类型和子元素出现顺序的一种简单文法。此文法用内容粒子(cp)构建，内容粒子由名字，内容粒子的选择表(choice
list)或内容粒子的序列表(sequence list)组成：
| 元素型内容的模型 | ||||||||||||||||||||
|
其中每一个Name是可以作为子元素的元素的类型。选择表中出现的任意内容粒子在元素型内容中允许出现的位置对应于选择表在文法中的位置。序列表中出现的所有内容粒子必须以相同的顺序出现在元素型内容中。在名字或表之后的可选字符(optional
character)决定了表中元素或内容粒子可以出现一次或多次(+)，还是零次或多次(*)，或是零次或一次(?)。没有这样一个操作符意味着元素或内容粒子必须恰好出现一次。这种语法和意义和本规范中的产生式中所使用的相同。
当且仅当一个元素的内容可以通过满足内容模型中的选择，序列和重复操作符得到，并且内容中的每一个元素与内容模型中的一种元素类型相匹配时，称此元素的内容与该内容模型相匹配。出于兼容性考虑， 如果文件的某个元素可以和内容模型中的一种元素类型多次匹配，这是一个错误。 更详细的信息参见"E. 确定型内容模型".
有效性约束: 严格的组/PE嵌套
参数实体的置换文本用括号括起的组严格嵌套。即，如果choice，seq或Mixed语法成分的开始或结束括号出现在某个参数实体的置换文本中，两者必须同在此置换文本中。出于互操作性考虑，如果一个参数实体引用出现在choice，seq或Mixed语法成分中时，它的置换文本不应为空，同时其置换文本的第一个和最后一个非空字符不应为一个连接符(|或,)。
元素型内容的模型举例：
<!ELEMENT spec (front, body, back?)> |
当某元素类型可以包含字符数据，其间可以随意穿插子元素时，称此元素类型具有混合型内容。在这种情况下，对子元素的类型可能有所限制，但对它们的次序和出现次数没有限制：
| 混合型内容声明 | ||||||||||||||||
|
其中Name给出了子元素的元素的类型。
有效性约束: 无重复类型
同一名字在单个混合型内容声明中只能出现一次。
混合内容声明的例子：
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*> |
属性用于关联名字-值对和元素。属性值说明只能在起始标签和空元素标签中出现; 因此，用于识别它们的产生式出现在"3.1 起始标签，结束标签和空元素标签"中。属性表声明可以用于：
属性表声明 详细说明了与给定元素类型相关联的每一个属性的名字，数据类型和缺省值(如果有的话)：
| 属性表声明 | ||||||||
|
AttlistDecl规则中Name是元素的类型。由用户选择，当属性声明相关的元素类型没有被声明时，XML处理器可以给出一个警告，但这不是一个错误。AttDef规则中的Name是属性的名字。
当与某个给定元素类型相关的AttlistDecl超过一个时，这些声明中的内容被合并在一起。当给定元素类型的某个属性的定义超过一个时，绑定第一个定义，其余定义被忽略。出于互操作性考虑，DTD的作者可以选择一个给定的元素类型至多有一个属性表声明，一个给定的属性名至多有一个属性定义，以及每个属性表声明至少有一个属性定义。出于互操作性考虑，当一个给定元素有超过一个的属性表声明或一个给定属性有超过一个的属性定义时，XML处理器可以，由用户选择，给出警告，但这不是一个错误。
XML属性有三种类型：字符串类型，一组记号化类型和枚举类型。字符串类型可以以任意常量字符串为值; 各个记号化类型有不同的词法和语义约束，如下：
| 属性类型 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
有效性约束: IDID类型的值必须匹配Name产生式。作为此类型值的名字只能在XML文件中出现一次;即，ID类型的值必须能唯一标识元素。
有效性约束: 每种属性类型一个ID
每种属性类型只能有一个ID属性。
有效性约束:
ID属性的缺省值
ID属性必须有一个声明为#IMPLIED或#REQUIRED的缺省值。
有效性约束: IDREFIDREF类型的值必须匹配Name产生式，IDREFS类型的值必须匹配Names产生式；每一个Name必须匹配XML文件中某些元素ID属性的值；也就是说，IDREF类型的值必须匹配某些ID属性的值。
有效性约束: 实体名ENTITY类型的值必须匹配Name产生式，ENTITIES类型的值必须匹配Names产生式；每一个Name必须匹配DTD中声明的未析实体的名字。
有效性约束: 名字记号NMTOKEN类型的值必须匹配Nmtoken产生式;NMTOKENS类型的值必须匹配Nmtokens产生式。
枚举类型的属性可以在声明中提供的取值表中取值。有两种枚举类型：
| 枚举属性类型 | ||||||||||||||||
|
一个NOTATION类型的属性标识了一种用于解释与此属性相关的元素的记法，此记法中用系统或公共标识符在DTD中声明。
有效性约束: 记法属性
此类型的值必须与声明中所包含的记法名之一相匹配;声明中的所有记法名都必须声明。
有效性约束: 枚举
此类型的值必须与声明中所包含的Nmtoken记号之一相匹配。
出于互操作性考虑，同一Nmtoken只能在单个元素类型的枚举属性类型中出现一次。
属性声明提供的信息指明了某属性是否必须出现，同时指明了在被声明的属性不是必须出现而文件中没有出现此属性的情况下，XML处理器应如何处理。
| 属性缺省值 | ||||||||||||||||||||||||||||
|
在一个属性声明中，#REQUIRED表示必须总是提供此属性，#IMPLIED表示不提供缺省值。如果声明既不是#REQUIRED，也不是#IMPLIED，那么AttValue值包含了所声明的缺省值;关键字#FIXED规定此属性必须总是有缺省值。如果声明了一个缺省值，当XML处理器遇到一个被省略的属性时，它将当成此属性以缺省值出现
有效性约束:
必须的属性
如果缺省值声明是关键字#REQUIRED，那么属性表声明所指类型的元素中都必须有此属性。
有效性约束: 合法的属性缺省值
被声明的属性缺省值必须满足被声明的属性类型的词法约束。
有效性约束:
固定的属性缺省值
如果某属性的缺省值用关键字#FIXED声明，此属性的所有实例必须匹配该缺省值。
属性表声明的例子：
<!ATTLIST termdef |
在将属性的值传给应用或检验有效性之前，XML处理器必须将其规范化：
如果被声明的值不是CDATA，那么XML处理器必须继续处理规范化后的值，去掉其前导和尾随空格(#x20)字符，并将空格(#x20)字符序列替换成单个空格(#x20)字符。
不进行验证的语法分析器应该将所有尚未读到声明部分的属性当成被声明为CDATA。
条件段是文件类型声明外部子集的一部分，取决于相应的关键字，它们或被包含在DTD逻辑结构之内，或被排除在DTD逻辑结构之外。
| 条件段 | ||||||||||||||||||||
|
同内部或外部DTD子集一样，条件段可以包含一个或多个完整的声明，注释，处理指令，或嵌套的条件段，其间可以夹杂空白。
如果条件段的关键字是INCLUDE，那么条件段的内容是DTD的一部分，如果条件段的关键字是IGNORE，那么条件段的内容逻辑上不是DTD的一部分。注意对于可靠的语法分析过程，甚至必须读取被忽略的条件段的内容以检测嵌套的条件段，保证最外层(被忽略)的条件段的结尾被恰当地检测到。如果一个关键字为INCLUDE的条件段出现在更大的关键字为IGNORE的条件段中，内外两个条件段都被忽略。
如果条件段的关键字是一个参数实体引用，处理器在决定是否包含或忽略此条件段前，必须先将该参数实体置换成其内容。
一个例子：
<!ENTITY % draft 'INCLUDE' > |
一个XML文件可能包含一个或多个存储单元。它们被称为实体(entity);它们都具有内容并且都用名字进行标识(除了文件实体，见下，和外部DTD子集之外)。每一个XML文件有一个称为文件实体的实体，它作为XML处理器处理的起点并可能包含了整个文件。
实体可以是已析的或未析的。已析实体(parsed entity)的内容被称为它的置换文本;此文本被看成是文件整体的一部分。
未析实体(unparsed entity)是一种资源，其内容可以是也可以不是文本，并且，如果是文本的话，可以不是XML。每一个未析实体有一个相关联的用名字标识的记法。除了要求XML处理器能向应用提供实体和记法的标识符之外，XML对未析实体的内容不作任何限制。
已析实体以实体引用的方式使用名字来调用;未析实体用ENTITY或ENTITIES属性中给出的名字调用。
普通实体(general entity)是那些在文件内容中使用的实体。在本规范中，普通实体有时用未修饰的术语entity来表示。参数实体是用于DTD内的已析实体。这两类实体用不同形式的引用，在不同的上下文中识别。另外，它们使用不同的名字空间;具有相同名字的参数实体和普通实体是两个截然不同的两个实体。
一个字符引用引用ISO/IEC 10646字符集中的一个字符。例如不能用输入设备直接输入的字符。
| 字符引用 | ||||||||||
|
规范性约束: 合法字符
用字符引用引用的字符必须匹配Char产生式。
如果字符引用以"&#x"开头，直到终结;的数字和字母提供了某字符在ISO/IEC
10646中代码的一个十六进制表示。如果它仅以"&#"开头，直到终结;的数字提供了某字符的代码的十进值表示。
实体引用(entity reference)引用一个命名实体的内容。对已析普通实体的引用使用"and"号(&)和分号(;)作为定界符。参数实体引用则使用百分号(%)和分号(;)作为定界符。
| 实体引用 | ||||||||||||||||||||||||||||||||||||||||||||||
|
规范性约束:
声明实体
在一个没有任何DTD的文件，或一个只有不包含参数实体引用的内部DTD子集的文件，或一个"standalone='yes'"的文件内，在实体引用中给出的Name必须与实体声明中所给出的相匹配，但规范的文件不需要声明以下的这些实体：amp，lt，gt，apos和quot。参数实体的声明必须先于任何对它的引用。类似地，普通实体的声明必须先于任何在属性表声明中的缺省值中出现的对它的引用。注意对于在外部子集或外部参数实体中声明的实体，不进行验证的处理器不必要读取和处理它们的声明;对这些文件，仅当standalone='yes'时，实体必须被声明的规则才是一个规范性约束。
有效性约束:
声明实体
在一个有外部子集或外部参数实体且"standalone='no'"的实体中，实体引用中给出的Name必须与实体声明中所给出的相匹配。出于互操作性考虑，有效的文件应该以"4.6 预定义实体"中的简化形式声明实体amp，lt，gt，apos和quot。参数实体的声明必须先于任何对它的引用。类似地，普通实体的声明必须先于任何在属性表声明中的缺省值中出现的对它的引用。
规范性约束: 已析实体
实体引用不能包含一个未析实体的名字。未析实体只能在声明为ENTITY或ENTITIES的属性值中引用。
规范性约束: 无递归
已析实体不能直接或间接地包含对自身的递归引用。
规范性约束: 在DTD内
参数实体引用只能在DTD中出现。
字符引用和实体引用的例子：
Type <key>less-than</key> (<) to save options. |
参数实体引用的例子：
<!-- declare the parameter entity "ISOLat2"... --> |
| 实体声明 | ||||||||||||||||||||
|
实体引用中的Name标识了该实体;对于未析实体，ENTITY或ENTITIES属性的值标识了该实体。如果同一实体被声明了不止一次，绑定第一个遇到的声明。由用户选择，如果实体被多次声明，XML处理器可以给出警告。
如果实体定义是一个EntityValue，被定义的实体被称为内部实体。内部实体没有单独的物理存储对象，实体的内容在声明中给出。注意常量实体值中一些实体和字符引用的处理可能要求产生正确的置换文本：参见"4.5 内部置换文本的构造"。
内部实体是已析实体。
内部实体声明的例子：
<!ENTITY Pub-Status "This is a pre-release of the |
| 外部实体声明 | ||||||||||||||
|
如果有NDataDecl，那么这是一个普通未析实体;否则它是一个已析实体。
SystemLiteral被称为该实体的系统标识符。这是一个URI，可以用于存取此实体。注意井号(#)和URI中常用的片断标识符形式上而言不是URI的一部分；如果一个片断标识符作为系统标识符的部分给出，XML处理器可以给出一个错误。除非在本规范范围之外另外给出(如，一个特殊DTD中定义的专用XML元素类型，或一个特殊应用规范中定义的处理指令)，相对URI指相对于实体声明所在资源的位置。因此，一个URI可能是相对于文件实体，或相对于包含外部DTD子集的实体，或相对于其他一些外部参数实体。
XML处理器处理URI中的非ASCII字符时，应该将UTF-8中的字符用一个或多个字节表示，然后将这些字符用URI转义机制转义(即，将每个字节转换成%HH，其中HH是字节值的十六进制记法)。
除了系统标识符之外，外部标识符还可以包含公共标识符。试图存取实体内容的XML处理器可以用公共标识符试着产生一个可选URI。如果处理器无法做到这一点，它必须使用系统常量中的URI。在试着匹配之前，公共标识符中所有空白字符串必须被规范为单个空格字符(#x20)，同时必须去掉前导和尾随空白。
外部实体声明的例子：
<!ENTITY open-hatch |
每个外部已析实体可以以文本声明作为开始。
| 文本声明 | ||||
|
文本声明必须以常量形式给出，而不能使用已析实体的引用。文本声明只能在外部已析实体的开头出现，不允许在其他任何地方出现。
如果文件实体匹配document产生式，那么它是规范的。如果外部普通已析实体匹配extParsedEnt产生式，那么它是规范的。如果外部参数实体匹配extPE产生式，那么它是规范的。
| 规范的外部已析实体 | ||||||||
|
如果内部普通已析实体的置换文本匹配content产生式，那么它是规范的。根据定义，所有内部的参数实体都是规范的。
实体符合规范性的一个结果是XML文件的逻辑和物理结构是严格嵌套的;起始标签，结束标签，空元素标签，元素，注释，处理指令，字符引用，或实体引用都不能在一个实体中开始而在另一个实体中结束。
XML文件中的每个外部已析实体都可以对其字符采用一种不同的编码方案。所有XML处理器必须能读编码为UTF-8或UTF-16的实体。
以UTF-16编码的实体必须以ISO/IEC 10646增补E和Unicode附录B(零宽度不间断空格字符，#xFEFF)中所描述的字节次序标记(Byte Order Mark)开头。这是一个编码签名，即不是XML文件中标记的一部分，也不是XML文件字符数据的一部分。XML处理器必须能用此字符区分UTF-8编码和UTF-16编码的文件。
虽然XML处理器只被要求能读取UTF-8和UTF-16编码的实体，已有共识认为世界上还有其他的编码方案。有时可能想让XML处理器读取以那些编码方案编码的实体。以不同与UTF-8和UTF-16的编码方案存储的实体必须以包含编码声明的文本声明开头：
| 编码声明 | ||||||||||
|
在文件实体中，编码声明是XML声明的一部分。EncName是所用编码方案的名字。
在一个编码声明中，值"UTF-8"，"UTF-16"，"ISO-10646-UCS-2"和"ISO-10646-UCS-4"应该用于表示Unicode或ISO/IEC
10646中的各种不同编码和变换方案，值"ISO-8859-1"，"ISO-8859-2"，...
"ISO-8859-9"应该用于表示ISO
8859的各个部分，而值"ISO-2022-JP"，"Shift_JIS"和"EUC-JP"应该用于表示JIS
X-0208-1997的各种编码。XML处理器可以识别其他编码方案;建议对于在Internet Assigned Numbers Authority [IANA]注册的字符编码方案(以字符集(charset)的方式)，除了以上所列的之外，引用时应使用其注册名。注意这些注册名定义为大小写敏感，因此欲与之匹配的处理器要以大小写敏感的方式进行匹配。
在缺少外部传输协议(如HTTP或MIME)所提供的信息时，以下情况均是错误：XML处理器接收到的实体的编码方案与实体所含编码声明中指出的编码方案不同，编码声明不在外部实体的开头，既不以字节次序标记开头也不以编码声明开头的实体使用了不同于UTF-8的编码。注意因为ASCII是UTF-8的一个子集，严格说来普通ASCII字符不需要编码声明。
当XML处理遇到的实体使用了它不能处理的编码时，是一个严重错误。
编码声明的例子：
<?xml encoding='UTF-8'?> |
下表汇总了字符引用，实体引用，和对未析实体的调用可以出现的上下文，以及每种情况下XML处理器的动作。最左边一列的标签指明了识别时的上下文：
content。
AttValue。
Name而不是以引用的形式出现，作为声明为ENTITY类型的属性的值，或可以作为声明为ENTITIES类型的属性值中的以空白分隔的记号之一。
EntityValue。
EntityValue和AttValue之外。
| 实体类型 | 字符 | ||||
| 参数 | 内部普通 | 外部已析普通 | 未析 | ||
| 内容中的引用 | 不被识别 | 被包含 | 进行验证时被包含 | 被禁止 | 被包含 |
| 属性值中的引用 | 不被识别 | 作为常量被包含 | 被禁止 | 被禁止 | 被包含 |
| 作为属性值 | 不被识别 | 被禁止 | 被禁止 | 通知 | 不被识别 |
| 实体值中的引用 | 作为常量被包含 | 不处理 | 不处理 | 被禁止 | 被包含 |
| DTD中的引用 | 作为PE被包含 | 被禁止 | 被禁止 | 被禁止 | 被禁止 |
在DTD之外，百分号字符%没有特殊含义;因此在DTD中的参数实体引用在content中不被当成标记识别。类似地，除非未析实体的名字出现在已适当声明的属性的值中，否则它们不被识别。
当一个实体的置换文本被当成出现在引用所在位置的文件的一部分一样被存取和处理时，称此实体被包含。其置换文本可以包含字符数据和标记(不包括参数实体)，其中标记必须以通常的方式识别，但用于转义标记定界符(实体amp，lt，gt，apos和quot)的实体的置换文本总是被当成数据。(字符串"AT&T;"展开为"AT&T;"尚存的"and"号&不被识别为实体引用的定界符。)当被表示的字符被当成出现在引用所在位置一样被处理时，称此字符引用被包含。
当XML处理器识别出一个对已析实体的引用，为了验证该文件，处理器必须包含此实体的置换文本。如果实体是外部的，而处理器不试图验证该XML文件，那么处理器可以，但不是必须，包含此实体的置换文本。如果一个不验证的语法分析器不包含此置换文本，它必须通知应用它识别出但没有读取此实体。
这条规范基于这样一个共识：由SGML和XML的实体机制提供的起初设计用于支持模块化创作的自动包含不一定适合于其他应用，尤其是文件浏览。例如，当浏览器遇到一个外部已析实体引用时，可能选择用可视方式表示其存在但只在被请求时才读取它进行显示。
以下情况被禁止，并构成一个严重错误：
EntityValue或AttValue中。
当实体引用出现在属性值中或参数实体引用出现在常量实体值中时，它们的置换文本被当成出现在引用所在位置的文件的一部分一样被存取和处理，置换文本中的单双引号总是被当成正常的数据字符而不会结束此常量。例如，下面的例子是规范的：
<!ENTITY % YN '"Yes"' > |
而这个例子不是：
<!ENTITY EndAttr "27'" > |
当未析实体名字作为记号在声明为ENTITY或ENTITIES类型的属性的值中出现时，进行验证的处理器必须将此实体和它的相关记法的系统和公共(如果有的话)标识符通知给应用。
当实体声明内一个普通实体引用出现在EntityValue中时，它不被处理，保持不变。
和外部已析实体一样，参数实体只需在进行验证时被包含。当参数实体引用在DTD中被识别并被包含时，它的置换文本被前后各加上一个空格字符;其目的在于强制参数实体的置换文本包含整数个DTD中的语法记号。
在讨论内部实体的处理时，区分两种形式的实体值是有帮助的。常量实体值(literal entity
value)是实际出现在实体声明中用引号扩起的字符串。对应于非终结符EntityValue。置换文本(replacement text)是置换了字符引用和参数实体引用后的实体内容。
在内部实体声明(EntityValue)中给出的常量实体值可以包括字符引用，参数实体引用和普通实体引用。这些引用必须被整个包含于常量实体值中。如前述方式被包含的实际置换文本必须包含所有被引用的参数实体的置换文本，同时所有被引用的字符必须在常量实体值中字符引用所在位置被包含。但普通实体的引用必须保持不变，不被展开。例如，如果有以下的声明：
<!ENTITY % pub "Éditions Gallimard" > |
那么实体"book"的置换文本为：
La Peste: Albert Camus, |
一旦引用"&book;"出现在文件的内容或属性值中时，普通实体引用"&rights;"应该被展开。
这些简单的规则将可能会有复杂的相互作用;参见"D. 实体和字符引用的展开"中对一个难的例子的详细讨论。
实体和字符引用都可以用于转义左尖括号，"and"号(&)和其他定界符。普通实体集合(amp，lt，gt，apos，quot)专门用于此目的。也可以使用数值字符引用;
一旦被识别，它们立即被展开，同时它们必须被当成字符数据，因此数值字符引用"<"和"&"可以用于转义出现在字符数据中的<和&。
不管这些实体是否被声明，所有的XML处理器必须能识别它们。出于互操作性考虑，有效的XML文件应该如其他实体一样，在使用这些实体前先声明它们。如果声明的话，这些实体必须被声明为内部实体，其置换文本是被转义的单个字符或指向这个字符的字符引用。如下所示。
<!ENTITY lt "&#60;"> |
注意在"lt"和"amp"的声明中，<和&被两次转义，这是为了满足实体置换的规范性要求。
记法用名字标识了未析实体的格式，具有记法属性的元素的格式以及处理指令所针对的应用的格式。
记法声明赋予记法一个名字用于实体中，属性表声明中和属性值说明中，同时也给出了一个记法的外部标识符使得XML处理器或它的客户应用可以定位能以给定记法的格式处理数据的助理应用。
| 记法声明 | ||||||||
|
XML处理器必须向应用提供任何在属性值中，属性定义中或实体声明中定义或引用的记法的名字和外部标识符。它们还可以将外部标识符解析成系统标识符，文件名，或是应用调用相应处理器处理给定记法格式的数据的所需的其他信息。(但如果XML处理器或应用所运行的系统中没有处理XML文件声明和引用的记法的相应应用的情况，不是一个错误。)
文件实体(document entity)是实体树的根和XML处理器的处理起点。本规范没有规定XML如何定位文件实体;与其他实体不同，文件实体没有名字，而且可以完全不带任何标识地出现在处理器的输入流中。
合乎规范的XML处理器可以分为两类：进行验证的和不进行验证的。
进行验证和不进行验证的处理器都必须报告在文件实体的内容中和任何其他它们读到的已析实体中对规范性约束的违反。
进行验证的处理器必须报告违反DTD声明中所述约束的情况以及不满足本规范中给出的有效性约束的情况。要完成这一点，进行验证的XML处理器必须读取和处理整个DTD和所有在文件中引用的外部已析实体。
不进行验证的处理器只被要求检查文件实体和整个内部DTD子集的规范性。虽然它们不被要求检查文件的有效性，但它们必须处理它们读取的所有内部DTD子集中的声明和所有参数实体，直到遇到第一个对它们没有读取的参数实体的引用;也就是说，它们必须根据这些声明中的信息规范化属性值，包含内部实体的置换文本，并提供缺省属性值。它们在遇到第一个对它们没有读取的参数实体的引用后，不应处理其后的实体声明或属性表声明，因为此实体中包含的声明可能覆盖前面的声明。
进行验证的处理器的行为是高度可预测的;它必须读取文件的所有部分，报告所有对规范性和有效性的违反。对一个不进行验证的处理器的要求要低一点;它不需要读取文件实体以外的任何文件部分。这对XML的处理器的用户而言可能会有两个重要的影响：
为了使不同XML处理器间的互操作有最大的可靠性，使用不进行验证的处理器的应用不应依赖于不要求这些处理器具备的动作。那些要求使用如缺省值或在外部实体中声明内部实体等功能的应用应该使用进行验证的XML处理器。
本规范中XML的形式化文法用一种简单的扩展巴科斯范式(Extended Backus-Naur Form，EBNF)给出。文法中的每一条规则定义了一个符号，形式如下：
symbol ::= expression |
如果符号用正则表达式定义，则它以大写字母开头，否则以小写字母开头。字符串常量(literal strings)用引号括起。
在规则右边的表达式中，以下表达式用于匹配一个或多个字符的字符串：
#xN
N是一个十六进制的整数，当ISO/IEC
10646中某个字符的规范(UCS-4)代码值作为无符号二进制数与N相等时，此表达式匹配这个字符。#xN中的前导0没有意义，在相应的代码值中的前导0的个数则由所用字符编码方案决定，对XML没有意义。
[a-zA-Z]， [#xN-#xN]
[^a-z]， [^#xN-#xN]
[^abc]， [^#xN#xN#xN]
"string"
'string'
这些符号可以按下列方式组合，以匹配更复杂的模式，其中A和B表示简单表达式：
expression)
expression被当成一个单元，可以向本表描述的那样进行组合。
A?
A相匹配，即A可选。
A B
A后跟B的模式相匹配。
A | B
AB之一相匹配，但不同时匹配。
A - B
A但不匹配B的字符串相匹配。
A+
A相匹配。
A*
A相匹配。 其他在产生式中使用的记法有：
/* ... */
[ wfc: ... ]
[ vc: ... ]
根据Unicode标准中定义的特征，字符被分为基字符(其中包括没有变音符的拉丁字母)，表意字符和组合字符(其中包括大多数的变音符);这些类合起来组成了字母类。数字和扩展符(extender)也各自被分成类。
| 字符 | ||||||||||||||||||||||||
|
在此定义的字符类可以从Unicode字符库中如下导出：
XML被设计为SGML的一个子集，表现在每一个有效的XML文件应该也是一个合乎规范的SGML文件。对XML在SGML之外对文件所加的限制的详细讨论参见[Clark]。
本附录中举例说明了在 "4.4 XML处理器对实体和引用的处理"一节中规定的实体和字符引用的识别和展开的次序。
如果声明包含在DTD中
<!ENTITY example "<p>An ampersand (&#38;) may be escaped |
那么XML处理器将在对实体声明进行语法分析时识别出字符引用，并在将下面的字符串存为实体"example"的值前解析这些字符引用:
<p>An ampersand (&) may be escaped |
文件中对"&example;"的引用会导致对文本的重新分析，此时元素"p"的起始和结束标签被识别，三个引用被识别和展开，其结果是一个包含下面内容(所有数据，无定界符或标记)"p"元素：
An ampersand (&) may be escaped |
一个更复杂的例子可以完整地说明这些规则和它们的作用。在下面的例子中，行号仅仅是为了方便说明。
1 <?xml version='1.0'?> |
这个例子会导致下列动作：
xx"以值"%zz;"存于符号表中。因为置换文本不被再次扫描，对参数实体"zz"的引用不会被识别。(而且如果它被识别的话则是一个错误，因为"zz"还没有被声明。)
<"被立即展开，而参数实体"zz"以置换文本"<!ENTITY
tricky "error-prone" >"被存储，此置换文本是一个规范的实体声明。
xx"的引用被识别，"xx"的置换文本(即"%zz;")被分析。对"zz"的引用随后被识别，它的置换文本("<!ENTITY
tricky "error-prone"
>")被分析。此时普通实体"tricky"被声明，它的置换文本是"error-prone"。
tricky"的引用被识别，并被展开，因此"test"元素的全部内容为一个自说明的(也不合语法)字符串This
sample shows a error-prone method.。 出于兼容性考虑，要求元素类型声明中的内容模型是确定型的。
SGML要求内容模型是确定型的(它称为"无歧义的"); 用SGML系统生成的XML处理器可能会把非确定型内容模型标为错误。
例如，内容模型((b, c) | (b,
d))是非确定型的，因为给定一个初始b，分析器没有在向前看以知道b后是什么元素之前，无法知道匹配模型中的哪个b。在这种情况下，两个对b的引用可以简化成单个的引用，使得模型成为(b,(c
|
d))。此时初始的b只和内容模型中的一个名字明确匹配。分析器不需要向前看其后的内容。c或d都能被接受。
更形式化的说法：使用Aho，Sethi和Ullman所著[Aho/Ullman]3.9节中的标准算法3.5，可以从内容模型构造出一个有限状态自动机。在很多这样的算法中，对应正则表达式中的每一个位置(即正则表达式的语法树中的每个叶子节点)，都构造一个随集(follow set)；如果任一位置的随集中不止一个后继位置被标为同一元素类型时，那么此内容模型出错，并且可以被报为错误。
存在将许多但不是所有非确定型内容模型自动规约为等价的确定型模型的算法；参见Br黦gemann-Klein 1991 [Br黦gemann-Klein].
XML编码声明在实体中以内部标签的方式工作，用于指出使用了何种字符编码。然而，在XML处理器能读取这个内部标签前，显然它必须知道当前使用的是何种字符编码－而这正是此内部标签要试图指出的。通常情况下，这是一种无法解决的情况。但在XML中并非如此，因为XML在两个方面对这种情形作出了限制：假定每一种实现只支持一个有限的字符编码集，并且，为了使得正常情况下自动检测每个实体中所用字符编码成为可能，限制了XML编码声明的位置和内容。同时，很多情况下除了XML数据流本身之外，另外还有可用的信息源。根据XML实体交给处理器时没有或有任何的附带(外部)信息，可以区分出两种情况。我们先考虑第一种情况。
因为每一个非UTF-8或UTF-16格式的XML实体必须以XML编码声明开头，其开始的几个字符必须为'<?xml'，任何合乎规范的处理器可以在两到四个八位组的输入后，检测出适用于下列何种情况。在读这张表时，知道这些是有帮助的：在UCS-4中，'<'是"#x0000003C"，'?'是"#x0000003F"，UTF-16数据流的字节次序标记要求为"#xFEFF"。
00 00 00 3C: UCS-4，big-endian编码的计算机(1234次序)
3C 00 00 00: UCS-4，little-endian编码的计算机(4321次序)
00 00 3C 00: UCS-4，异常的八位组次序(2143)
00 3C 00 00: UCS-4，异常的八位组次序(3412)
FE FF: UTF-16，big-endian
FF FE: UTF-16，little-endian
00 3C 00 3F: UTF-16，big-endian，无字节次序标记(因此严格说来出错)
3C 00 3F 00: UTF-16，little-endian，无字节次序标记(因此严格说来出错)
3C 3F 78 6D: UTF-8，ISO 646，ASCII，ISO
8859的一些部分，Shift-JIS，EUC，及其他任何7位，8位或混合宽度的能保证ASCII字符有它们正常的位置，宽度，取值的编码;具体其中哪一个适用需读取实际的编码声明来检测确定，但因为所有这些编码中ASCII字符的位模式相同，所以能够可靠地读取编码声明本身。
4C 6F A7 94: EBCDIC(在某些变种中，完整的编码声明必须能用于确定使用了哪一代码页)
这种层次的自动检测足以用于读取XML编码声明和分析字符编码标识符。字符编码标识符仍然是必须的，它用于区分编码方案集中的单个成员(例如从8859中区分出UTF-8，8859各个部分间的相互区分，以及区分所用的特定EBCDIC代码页，等等)。
因为编码声明的内容限于ASCII字符，一旦处理器检测到使用的是哪一个编码方案集，它能够可靠地读取整个编码声明。因为在实际中，所有广泛使用的字符编码都可以归于上述种类中，XML编码声明保证了可靠的内嵌(in-band)字符编码标注，即使是在操作系统或传输协议级的外部信息源并不可靠的情况下。
一旦处理器检测到所用的字符编码，它就可以作出合适的动作，或是针对每种情况调用单独的输入例程，或是对每个输入的字符调用版本合适的转换函数。
和任何自标注(self-labeling)的系统一样，一旦任何软件改变了实体的字符集或其编码而没有相应修改编码声明的话，XML的编码声明将无法工作。字符编码方案的实现者必须小心仔细，以保证用于标注实体的内部和外部信息的正确性。
第二种可能的情况是XML实体有附带的信息，如在一些文件系统和网络协议中。当具有多个信息源时，它们间的相对优先级和首选冲突处理方法必须在传输XML的高层协议中给出。例如，内部标签和外部文件头中的MIME类型标签的相对优先级应该是定义text/xml和application/xml MIME类型的RFC文档的一部分。然而出于互操作性考虑，建议使用下列规则。
charset参数决定了字符编码方法;所有其他信息源和推断都仅仅用于错误恢复。
这些规则只适用于缺少协议级文档时的情况；特别是，当相关RFC中定义了这些text/xml和application/xml MIME类型时，RFC中的建议取代这些规则。
本规范由W3C XML工作组(WG)完成并批准发表。工作组批准本规范并一定表示所有的工作组的成员都一致同意本规范。现有和以前的XML工作组成员包括：
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