：
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 < 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 字符（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
STag, Etag, EmptyElemTag, Comment, CDStart, CData, CDEnd, Name, Nmtoken, AttValue, extDeclSubset SystemLiteral, PI, PITarget, content, CharData, -->
然而，即使文檔未被完全規范化，它仍是良構的。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允許的）。
4.1 字符引用和實體引用（Character and Entity References）
將Well-formedness constraint: Legal Character替換為下面這段文字：
以字符引用（character reference）方式被引用的字符必須符合產生式Char，或者是一個在范圍[#x1-#x1F]或[#x7F-#x9F]內的ISO控制字符。
4.3.4 實體中的版本信息（Version Information in EntitIEs）[新]
每個實體（包括文檔實體）可以各自被聲明為XML 1.0或XML 1.1。文檔實體中的版本聲明確定了整個XML文檔的版本。一個XML 1.1文檔可以調用XML 1.0外部實體，這樣就不需要維護外部實體版本的重復（特別是DTD外部子集）。但在這種情況下，XML 1.1的規則被應用於整個文檔。
如果一個實體（包括文檔實體）沒有標明版本號，則認為它的版本號為1.0。
附錄A 參考資料(References)
增加以下規范性參考資料：
[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 關於XML名稱的建議（Suggestions for XML Names）(非規范性)
將附錄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]）。
· 名稱中不應包含變奏選擇字符。
· 不應使用無意義的、不能發音的、難讀的或容易與其他名稱混淆的名稱。