| 更多信息请访问 W3CHINA.ORG讨论区 |
|
|
|
|
A website dedicated to promoting the widespread deployment of W3C technologies. A website designed to propagate information on the future of the Web. A website ideally suited for discussions and the exchange of relevant information. |
|
|
译文： |
XML
1.1候选推荐标准Unicode简体中文版（http://xml1p1.w3china.org） |
|
原文： |
XML
1.1 Candidate Recommendation（http://www.w3.org/TR/2002/CR-xml11-20021015） |
|
说明： |
l
本文档是根据2002年10月15日发布的XML 1.1候选推荐标准翻译的。 l
本文档的英文版是唯一的正式版本。 l
虽然译者已为翻译之精确付出努力，不足之处仍难免存在。欢迎来信指正。 l
译注的内容是非正式的，仅代表译者个人观点。 l
著作权声明位于： Copyright
© 2002 W3C
® ( MIT
, INRIA
, Keio), All Rights Reserved. W3C liability,
trademark,
document
use and software
licensing rules apply. |
|
译者： |
徐涵（Collin Hsu） |
|
时间： |
首次发布于2003年10月28日/最后更新于2003年10月28日 |
当前版本：
http://www.w3.org/TR/2002/CR-xml11-20021015
最新版本：
上一版本：
http://www.w3.org/TR/2002/WD-xml11-20020425/
编者：
John Cowan, Reuters < jcowan@reutershealth.com >
本文档是XML Core Working Group交付的工作成果，它根据XML Blueberry Requirements中的定义对XML 1.1进行了描述。XML 1.1即过去所说的XML Blueberry。本文档的描述将采取对XML 1.0推荐标准[XML1.0]进行一系列改动的方式。本文档的篇章编号对应于它们在XML 1.0推荐标准中的篇章编号。对于那些XML 1.0推荐标准中有、而本文档中没有的篇章，表示它们没有被改动。
这一部分描述本文档在发布时的状态。本文档可能会被其他文档替代。本文档序列的最新状态由W3C维护。
本文档是XML 1.1的W3C候选推荐标准（W3C Candidate Recommendation）。W3C将技术报告（technical report）[译注//技术报告即W3C官方发布的文档]的状态置为候选推荐标准，意味着该文档被认为是稳定的，并鼓励开发团体去实现它。关于候选推荐标准状态的描述，请参见Process Document的5.3.2节。
一旦XML Core Working Group（属于XML Activity的一部分，参见摘要）证实至少存在两个可以互操作的实现，他们将会提请W3C Director将本规范提升为建议推荐标准（Proposed Recommendation）。这两个实现必须是由不同的组织实现的。
当前的实现报告记录了到目前为止我们已经收到的实现方面的反馈。
状态为候选推荐标准的文档不表明它已被W3C成员认可。它是一个草案，随时可能被其他文档更新、替换或作废。在引用本文档时应注明“work in process”。
本文档以及它的后续文档将采用对XML 1.0推荐标准进行修改的形式来书写，以便于编辑和检查。最终的XML 1.1推荐标准（XML 1.1 Recommendation）可能采取对XML 1.0推荐标准进行必要修改的形式进行陈述。
与本文档有关的知识产权方面的记录可以在Working Group’s public IPR disclosure页面找到。
我们明确请求对本文档进行评论。候选推荐标准的复审期在UTC时间2003年2月14日23点59分结束。请将评论发送至www-xml-blueberry-comments@w3.org。这是提供反馈的首选方式。公众评论以及回复可以从以下网址获得：http://lists.w3.org/Archives/Public/www-xml-blueberry-comments/。
本文档的发布不表明它已被W3C成员认可。它是一个草案，随时可能被其他文档更新、替换或作废。在引用本文档时应注明“work in process”。W3C推荐标准及其他技术文档（technical document）的最新列表可从以下网址获得：http://www.w3.org/TR。
2.2 字符
2.3 普通的语法构造元素
2.8 序言和文档类型声明
2.11 行尾处理
2.13 W3C规范化检查[新]
4.1 字符引用和实体引用
4.3.4 实体中的版本信息[新]
附录A 参考资料
附录B 字符类[替代的]
W3C的XML 1.0推荐标准最初发布于1998年。尽管XML 1.0（第二版）的发布更正了许多勘误，但XML 1.0在关于什么是良构的（well-formed）XML方面仍（有意）保持不变。这一稳定对互操作是极为有用的。然而Unicode标准作为XML 1.0所依赖的字符规范并没有保持不变，它已经从2.0版升级到了3.1版甚至更高。许多在Unicode 2.0中没有的字符可能已经被使用于XML 1.0的字符数据（character data）中了。然而，他们是不允许出现在XML名称（XML name）（比如元素类型名、属性名、枚举属性值、PI目标等等）中的。此外，有些本应允许在XML名称中出现的字符，由于疏忽或是与Unicode 2.0不一致等原因没有被允许。
在XML 1.0之后，关于名称（name）的总体看法已有所改变。然而XML 1.0给名称（name）提供的是一个严格的定义：其中任何不被允许的，就是禁止的。XML 1.1的名称却是这样设计的：任何不被禁止的（由于某个特定原因），就是允许的。考虑到Unicode版本的发展将越过3.1版，为避免对XML进行更进一步的改动，XML 1.1几乎允许所有字符（包括那些尚未被指定的）在名称中出现。
另外，XML 1.0试图适应各种现代操作系统的行尾处理规则（convention），但却没有考虑IBM（或IBM兼容）大型机（mainframe）的行尾处理规则。因此，根据本地规则，大型机上的XML文档不是简单的文本文件。大型机生成的XML 1.0文档必须违反本地的行尾处理规则，或者在解析和生成前使用其他多余的转换过程。当数据要在大型机和非大型机（不同于从一个机器复制到另一个机器）间共享时，允许直接的互操作显得尤为重要。因此XML 1.1在行尾字符列表中增加了一个NEL(#x85)字符。出于完备性考虑，XML 1.1也支持Unicode的行分隔符#x2028。
最后，为XML文档中的任意Unicode字符定义一个标准的表示是一个应重视的需求。因此，XML 1.1允许使用字符引用（character references）来引用从#x1到#x1F的控制字符（其中大部本在XML 1.0中是被禁止的）。出于健壮性（robustness）考虑，这些字符仍不能直接在文档中使用。为了提高字符编码识别的健壮性，原先在XML 1.0文档中允许自由出现的附加控制字符（从#x7F到#x9F）现在必须以字符引用的形式出现（空白字符当然是除外的），牺牲少许向后兼容性影响并不大。由于APIs方面潜在的问题，#x0仍是被禁止的（即不能直接使用，也不能以字符引用的形式使用）。
没有为XML 1.0发布一组勘误，而是创建一个新版本的XML，是因为这些改动影响了良构的（well-formed）XML文档这个定义。XML 1.0处理器必须继续拒绝那些XML名称中含有新字符、使用新的行尾处理规则和对控制字符进行字符引用的文档。对XML 1.0文档和XML 1.1文档的区分可以通过文档首部XML声明（XML declaration）中的版本号信息来判断。
将产生式[2]改为：
[2] Char ::= #x9 | #xA | #xD | [#x20-#x7E] | #x85 | [#xA0-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
将产生式[2]的注释改为：
任何Unicode字符，除去大部分ISO控制字符、代用区（surrogate blocks）[译注//代用区（surrogate blocks）为Unicode术语，关于它的简要说明请参见Tim Bray撰写的Unicode Surrogates]、FFFE和FFFF。
修改产生式[4]，并增加新的产生式[4a]:
[4] NameStartChar := ":" | [A-Z] | "_" | [a-z] | [#xC0-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xEFFFF][4a] NameChar := NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
将产生式[5]改为：
[5] Name ::= NameStartChar NameChar*
在产生式[5]后面插入下面三段文字：
名称（Name）的第一个字符必须是一个NameStartChar，其余字符必须是NameChars；这一机制保证了名称不会以拉丁（ASCII）数字或基本组合字符（combing characters）[译注//Unicode术语，定义参见这里。]开头。几乎所有字符都可以在名称中出现（除了那些被用作或可能被用作分隔符的字符）。其目的是为了使之成为相容的（inclusive）而不是排他的（exclusive），这样还没有被Unicode编码的书写系统（writing systems）[译注//Unicode术语，定义参见这里。]也能在XML名称中被使用。关于名称创建方面的建议，请参见附录B。
建议文档作者使用在自然语言中有意义的字词作为XML名称，并避免在名称中使用符号字符（symbolic characters）或空白字符（whitespace characters）。注意：冒号（：）、连字符（-）、句号（.）、下划线（_）和圆点（·）是明确允许的。
禁止ASCII符号字符（symbols）、标点符号以及一大批Unicode符号字符在XML名称中出现，是为了在XML文档外的语境中使用XML名称时可以把这些字符作为分隔符。字符#0x037E（希腊字符的问号）被禁止出现是因为该字符在规范化后将成为分号（；），而这会改变实体引用的含义。
把产生式[7]改为:
[7] Nmtoken ::= NameChar+
把所有的“1.0”改为“1.1”。
增加下面这段文字：
XML 1.1处理器也应可以处理XML 1.0文档。如果一个文档是良构的（well-formed）或有效的（valid）XML 1.0文档，并且不直接包含任何[#x7F-#x9F]中的字符（以转义字符形式出现的除外），则只要将文档的XML版本号改为“1.1”就可使之成为一个良构的或有效的XML 1.1文档。
将第二段替换为以下文字：:
为了简化应用程序的任务，XML处理器传给应用程序的字符必须是就像XML处理器在进行解析之前已将输入中的外部已解析实体（external parsed entities）（包括文档实体）中的所有换行符规范化过了一样。这里的规范化是通过将下列字符全部替换为字符#xA完成的：
·
双字符序列 #xD #xA
·
双字符序列 #xD #x85
·
单个字符#x85
·
单个字符#x2028
·
所有没有被字符#xA或字符#x85跟随的字符#xD 。
所有的XML已解析实体（包括文档实体）都应按照[Charmod]中的定义以及下面对XML相关构造成分（relevant constructs）[译注//Charmod中的术语，定义参见这里。]的补充定义被完全规范化（fully normalized）[译注//Charmod为文本（text）定义了三个层次的规范化，它们依次为：Unicode规范化（Unicode Normalization）、嵌入规范化（Include Normalization）和完全规范化（Fully Normalization）。]：
·
所有已解析实体（parsed
entities）的替换文本（replacemane text）
·
所有在上下文中匹配下列产生式的文本
o
CData
o
CharData
o
content
o
Name
o
Nmtoken
然而，即使文档未被完全规范化，它仍是良构的。XML处理器应让用户选择是否要验证被处理的文档有没有处于完全规范化形式（fully normalized form），并向应用程序报告验证的结果。根据[Charmod]中的规定，只有在输入文本是已鉴定的（certified）[译注//Certified Text为Charmod中的术语，定义参见这里。]的情况下，才应选择不进行验证。
对完全规范化的验证必须（或就像是）首先验证实体是嵌入规范化（include-normalized）（参见[Charmod]）的，然后验证上面所列出的相关构造成分没有以构件字符（composing character）开头（在字符引用被展开之后）（参见[Charmod]）。无验证的处理器（non-validating processors）必须忽略嵌入未读外部实体时可能造成的非规范化（denormalization）。
注意：构件字符（composing characters）[译注//Charmod中的术语，定义参见这里]为所有非0号组合类（non-zero
combining class）[译注//Unicode为每个组合类指定了一个号码，用以区分各个组合类。这些号码仅作标识用，并不具有任何含义。]中的字符，加上少量0号组合类（class-zero）中的字符（指那些在某些标准分解中不作为首字符的字符）。由于构件字符是用来跟随基准字符（base characters）[译注//Unicode术语，定义参见这里]的，因此，限制相关构造成分（包括内容）不能以构件字符开头并不会实质减少XML的表达能力。
如果XML处理器在完全规范化的验证过程中遇到不能确定其规范化特征的字符（即引入这些字符的[Unicode]版本是在实现该处理器时所考虑的那个Unicode版本之后发布的），那么处理器可以（根据用户的选择）忽略可能由这些字符导致的非规范化（denormalizations）问题。在可靠性和安全性极为重要的情况下，应用程序不应选择忽略这些非规范化。
XML处理器必须把输入转换为完全规范化形式。创建XML 1.1输出的XML应用程序（无论输入是XML 1.0还是XML 1.1的）应确保输出是完全规范化的；而对于内部的处理形式，则可以不是完全规范化的。
本节的意图是强烈建议XML处理器确保XML文档的创建者已经完成了完全规范化，这样XML应用程序就可以进行字符串比较，而不必担心字符串的多种不同拼写形式（这是Unicode允许的）。
将Well-formedness constraint: Legal Character替换为下面这段文字：
以字符引用（character reference）方式被引用的字符必须符合产生式Char，或者是一个在范围[#x1-#x1F]或[#x7F-#x9F]内的ISO控制字符。
每个实体（包括文档实体）可以各自被声明为XML 1.0或XML 1.1。文档实体中的版本声明确定了整个XML文档的版本。一个XML 1.1文档可以调用XML 1.0外部实体，这样就不需要维护外部实体版本的重复（特别是DTD外部子集）。但在这种情况下，XML 1.1的规则被应用于整个文档。
如果一个实体（包括文档实体）没有标明版本号，则认为它的版本号为1.0。
增加以下规范性参考资料：
[XML1.0]
Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Maler (editors), Extensible Markup Language (XML) 1.0 (Second Edition), 6 October 2000. (See http://www.w3.org/TR/REC-xml .)
[Charmod]
Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Asmus Freytag, Tex Texin Character Model for the World Wide Web, W3C Working Draft, 30 April 2002. (See http://www.w3.org/TR/charmod/.)
将附录B的标题由“Character Classes”（normative）改为“Suggestions for XML Names”（non-normative），并将其内容改为下面的文字：
下面为如何给元素名(element names)、属性名(attribute names)、PI目标（PI targets）、实体名（enity names）、格式名（notation names）和ID类型的属性值(values of attributes of type ID)创建XML名称（XML names）给出了最佳方法（best practice）。
前两个建议直接取自Unicode标准3.0版中的规则，去除了其中的所有控制字符、环绕非空白符号、非十进制数字、私有用途字符、标点符号（例外的标点符号将在下面注明）、符号字符、未赋值的代码点（codepoints）以及空白字符等。其他的建议主要来自XML 1.0的附录B。
· 所有名称的首字符都应要么是Ll、Lu、Lo、Lm、Lt或Nl类[译注//这些类别是在Unicode总体分类（General Category）中定义的。]中的字符，要么是字符 '_'（#x5F）。
· 首字符以外的字符都应要么是Ll、Lu、Lo、Lm、Lt、Mc、Mn、Nl、Nd、Pc、或Cf类中的字符，要么是下列字符之一：'-' #x2D、'.' #x2E、':' #x3A或'·' #xB7 (圆点)。由于Cf类中的字符不是直接可见的，因此使用它们时应给出警告、并且只有在必要情况下才能使用，以避免被创建的名称在XML处理器看来不同、而在人看来却是相同的。
· 名称中不应包含存在标准分解（canonical decomposition）[译注//Unicode术语，定义参见这里。]的象形文字（包括在[#xF900-#xFAFF]和[#x2F800-#x2FFFD]范围中的，其中有十二个字符例外）。
· 名称中不应包含存在相容分解（compatibility decomposition）[译注//Unicode术语，定义参见这里。]的字符（即那些在Unicode字符库中第五个字段有相容格式标签的字符——以第五个字段的首字符为“<”为标志）。这一条并不应用于#x0E33 THAI CHARACTER SARA AM或#x0EB3 LAO CHARACTER AM（尽管它们的相容分解在书写它们的字符时被正常使用）。
· 名称中不应包含那些仅用于符号的组合字符（包括那些在[#x20D0-#x20EF]和[#x1D165-#x1D1AD]中的字符）。
· 名称中不应包含行间标记字符（[#xFFF9-#xFFFB]）。
· 名称中不应包含变奏选择字符。
· 不应使用无意义的、不能发音的、难读的或容易与其他名称混淆的名称。