XML 1.1候选推荐标准 Unicode简体中文版

** 译文:

**

|

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日

可扩展标记语言( XML ) 1.1

W3C 候选推荐标准 2002 年 10 月 15 日

** 当前版本 ** ** : ** **

**

http://www.w3.org/TR/2002/CR-xml11-20021015

http://www.w3.org/TR/2002/CR-xml11-20021015

可扩展标记语言( XML ) 1.1

W3C 候选推荐标准 2002 年 10 月 15 日

** 当前版本 ** ** : ** **

**

http://www.w3.org/TR/2002/CR-xml11-20021015

可扩展标记语言( XML ) 1.1

W3C 候选推荐标准 2002 年 10 月 15 日

** 当前版本 ** ** : ** **

**

http://www.w3.org/TR/2002/CR-xml11-20021015

** 最新版本 ** ** : ** **

**

http://www.w3.org/TR/xml11/ _

_

** 上一版本: ** **

**

http://www.w3.org/TR/2002/WD-xml11-20020425/

** 编者: ** **

**

John Cowan, Reuters < [email protected] >


摘要

本文档是 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 disclosur _ e _ 页面找到。

我们明确请求对本文档进行评论。候选推荐标准的复审期在 UTC 时间 2003 年 2 月 14 日 23 点 59 分结束。请将评论发送至 [email protected] 。这是提供反馈的首选方式。公众评论以及回复可以从以下网址获得: 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 字符( Characters )

将产生式 [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 。

2.3 普通语法构造元素( Common Syntactic Constructs )

修改产生式 [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+


 


2.8 序言和文档类型声明(Prolog and Document Type Declaration)


2.8 序言和文档类型声明(Prolog and Document Type Declaration)

把所有的 “1.0” 改为 “1.1” 。

增加下面这段文字:

XML 1.1 处理器也应可以处理 XML 1.0 文档。如果一个文档是良构的( well-formed )或有效的( valid ) XML 1.0 文档,并且不直接包含任何 [#x7F-#x9F] 中的字符(以转义字符形式出现的除外),则只要将文档的 XML 版本号改为 “1.1” 就可使之成为一个良构的或有效的 XML 1.1 文档。

2.11 行尾处理( End-of-Line Handling )

将第二段替换为以下文字: :

为了简化应用程序的任务, XML 处理器传给应用程序的字符必须是就像 XML 处理器在进行解析之前已将输入中的外部已解析实体( external parsed entities )(包括文档实体)中的所有换行符规范化过了一样。这里的规范化是通过将下列字符全部替换为字符 #xA 完成的:

· 双字符序列 #xD #xA

· 双字符序列 #xD #x85

· 单个字符 #x85

· 单个字符 #x2028

· 所有没有被字符 #xA 或字符 #x85 跟随的字符 #xD 。

2.13 规范化检查( Normalization Checking ) [ 新 ]

所有的 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 中的术语 ,定义参见 <span lang="EN-US" st *[

    W3C
   
  ]: World Wide Web Consortium

*[

    MIT
   
  ]: Massachusetts Institute 

of Technology *[

    INRIA
   
  ]: Institut National de Recherche en Informatique et 

Automatique

Published At
Categories with Web编程
Tagged with
comments powered by Disqus