可擴展標記語言(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)
把所有的“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中的術語,定義參見這里]為所有非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])。
•
名稱中不應包含變奏選擇字符。
•
不應使用無意義的、不能發音的、難讀的或容易与其他名稱混淆的名稱。