REC-xml-19980210-tw
可擴展標示語言(XML) 1.0
W3C 建議書 1998年2月10日
- 本版本:
- http://www.w3.org/TR/1998/REC-xml-19980210
- http://www.w3.org/TR/1998/REC-xml-19980210.xml
- http://www.w3.org/TR/1998/REC-xml-19980210.html
- http://www.w3.org/TR/1998/REC-xml-19980210.pdf
- http://www.w3.org/TR/1998/REC-xml-19980210.ps
- 最新版本:
- http://www.w3.org/TR/REC-xml
- 上一版本:
- http://www.w3.org/TR/PR-xml-971208
- 編者:
- Tim Bray (Textuality and Netscape) <tbray@textuality.com>
- Jean Paoli (Microsoft) <jeanpa@microsoft.com>
- C. M. Sperberg-McQueen (University of Illinois at Chicago) <cmsmcq@uic.edu>
摘要
本文件完整地描述了可擴展標示語言 (Extensible Markup Language,XML)
的各項資訊。XML可說是標準通用標示語言 (Standard Generalized Markup
Language,SGML) 的子集合,其作用主要是讓通用的 SGML
也能像現有的超鏈結標示語言 (HyperText Markup Language,HTML)
一樣,可以在 Web 上提供服務、接收及處理資料等工作。XML
被設計成十分容易實作 (Implementation),並且也提供 XML 與 SGML 或 HTML
之間的互通功能。
本文件的制定始末與狀態
本文件已經由 W3C
組織中的成員及相關團體審閱過,並已被組織中的理事批准為 W3C
建議書 (W3C Recommendation)。此為一份穩定的文件 (譯註:
表示不會經常修改),可以當作參考資料,也可作為其他文件的正式參考文獻。W3C
在制定建議書過程中的角色是為了吸引對於 XML
規格的注意,以促進其被廣泛地使用。如此便能增強 Web
的功能及互動性。
本規格書規定了一種可用於全球資訊網 (World Wide Web)
的語法,此語法是根據一個已存在並廣泛使用的國際文字處理標準 (就是
Standard Generalized Markup Language,SGML,標準通用標示語言,為經過修正過的
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。
可擴展標示語言(XML) 1.0
目錄
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文件由稱為實體的儲存單元所組成,而實體可以包含剖析過
(Parsed) 或未剖析過 (Unparsed) 的資料。已剖析過的資料由字元組成,其中一些字元組成字元資料,另一些字元組成標示。標示中包含了對於文件儲存格式 (Storage layout)
和邏輯結構 (Logical structure) 的描述。因此 XML
可說是提供了一種可用於規範及限制儲存格式和邏輯結構的機制。
一種稱為XML 處理器 (XML Processor)
的軟體模組是用來讀取 XML文件,並提供存取文件內容及結構的方法。它也可以處理 應用程式 (Application)。針對 XML
處理器應如何讀取 XML
資料,以及應提供哪些資訊給應用程式兩方面,本規格書描述了其所需擁有的動作與操作方式。
XML由 XML 工作組 (原先的 SGML 編輯審查委員會) 所開發,此工作組在
1996 年由全球資訊網協會 ( World Wide Web Consortium,W3C)
所成立。該工作組的負責人是 Sun Microsystems的 Jon Bosak,同樣 W3C
組織的 XML Special Interest Group (原先為 SGML工作組)
也積極參與了這項工作。有關 XML
工作組之成員姓名請參考附錄。工作組與 W3C 的聯繫人為 Dan Connolly。
XML 的設計目標如下:
- XML 應該可以直接在 Internet 上使用。
- XML 應該可以支援多種不同的應用。
- XML 應該要能與 SGML 相容。
- 處理 XML 文件的程式應該要很容易撰寫。
- XML 中可選擇性的功能 (optional features)
應儘可能地減至最少,理想狀況下應該 0 個。
- XML 文件應該能夠讓人直接閱讀,並且能夠清楚的被理解。
- XML 的設計應盡速完成。
- XML 的設計應該是正式的 (formal) 及簡潔的 (concise)。
- XML 文件應該能很容易的建立。
- XML 標示 (Markup) 的簡化部分是不重要的。(譯註:此目標是為了解決
SGML 有關簡化 (Minimization) 的問題)
本規格書與其他相關的標準 (Unicode 和 ISO/IEC 10646 定義字元集,Internet
RFC1766 定義語言識別碼,ISO 639 定義語言名稱代碼,ISO 3166
定義國家名稱代碼),一起提供能了解 XML 版本 1.0
規格及建立其處理程式需要的所有資訊。
只要能完整地保留 XML 1.0 規格書中所有的文字內容及版權注意事項
(legal notices),則此版本的 XML 規格書便可自由散佈 (distributed freely)。
在說明 XML
文件時所使用的術語都會在此規格書的內文中定義。在建立這些定義及描述一個
XML 處理器的動作時,使用下面列表中的術語:
- 可以 (may)
- 允許符合規格的文件和 XML
處理器依照所描述的方式進行運作,但不要求必須如此。
- 必須 (must)
- 要求符合規格的文件和 XML
處理器依照所描述的方式進行運作;否則會出現錯誤。
- 錯誤 (error)
- 若違背本規格書中的規則;則得到的結果是沒有定義的。符合規格的軟體可以偵測及告知錯誤,且可以從錯誤中恢復。
- 嚴重錯誤 (fatal error)
- 此種錯誤是符合規格的XML處理器必須能檢測出來,並向應用程式告知的。為了幫助修正錯誤,處理器可將文件中未經處理的資料
(混合字元資料和標示資料)
傳送給應用程式。然而一旦檢測到一個嚴重的錯誤,則處理器必須終止一般的資料處理
(也就是說,它必須停止以一般的方式,傳遞有關文件邏輯結構的字元資料及資訊給應用程式)。
- 由使用者選擇 (at user option)
- 符合規格的軟體可以或必須 (端視於句子中的語態動詞 modal verb)
按照所描述的行為來運作;如果它符合此運作行為,
則必須提供使用者一種方法,此方法能夠決定是否使用 (Enable)
或禁用 (Disable) 所描述的行為運作方式。
- 正確合法性限制 (validity constraint)
- 此為能適用於所有正確合法的 (valid) XML文件之規則。若違背正確合法性的限制就視為錯誤;進行正確合法性驗證的 XML 處理器必須經由使用者選擇
(At user option) 是否告知這些錯誤。
- 形式合法性限制 (well-formedness constraint)
- 此為能適用於所有形式合法的 (well-formed) XML
文件之規則。若違背形式合法性的限制就視為嚴重錯誤。
- 相符 (match)
- (針對於字串和名稱:)
被比較的兩個字串或名稱必須完全相同 (Identical)。在 ISO/IEC 10646
中有多種可能表示方式的字元 (例如:預先定義 (Precomposed) 形式及基礎
(Base) + 變音符 (Diacritic) 形式的字元)
只在於兩個字串的表示方式相同時才表示相符。由使用者選擇,處理器可將這些字元的某種規範
(Canonical) 形式標準化。但此處並不會轉換字元的大小寫。(針對文法中的字串和規則:)
如果字串屬於某個文法產生規則式所產生的語言,則它相符於這個產生規則式。(針對內容和內容模型:)
當一個元素符合"元素正確合法性"限制的描述時,此元素會符合於本身的宣告
(declaration)。
- 針對相容性考量 (for compatibility)
- 此特性僅使用於確保 XML 仍舊相容於 SGML。
- 針對互通性考量 (for interoperability)
- 本規格書包含一個不具效力的建議內容,目的是為了增加XML文件,能被
ISO 8879 WebSGML 改編附件 (WebSGML Adaptation Annex) 之前就存在的 SGML
處理器處理的機會。
如果一個資料物件符合本規格書中形式合法 (well-formed) 的定義時,它就是一份XML文件
(XML document)。一份形式合法的XML文件,如果它滿足某些額外的限制,則可進一步成為正確合法的 (valid) 文件。
每份 XML 文件都有邏輯上 (Logical) 及物理上 (Physical)
的結構。就物理上而言,文件是由稱為 實體 (Entity)的單元所組成。一個實體可以
引用 (refer)其他實體並將之包括在文件中。
文件開始於"根元素 (Root 或 Root element) " 或文件實體
(document entity) 中。就邏輯上而言,就邏輯上而言,文件由宣告
(Declarations)、元素 (Elements)、註解 (Comments)、字元參引 (Character
references) 與處理指示 (Processing Instructions,PI)
所組成,所有這些組成單元都會在文件中使用明顯的標示來代表。邏輯和物理結構必須像"
4.3.2 形式合法的剖析過實體"中所描述那樣嚴格地處理巢狀結構
(nest)。
若一個文本物件 (textual object)
是一份形式合法的 XML 文件,它需要滿足以下要件:
- 相符於
document
的產生規則式。
- 滿足本規格書中所定義的所有形式合法性限制。
- 此文件中直接或間接引用的每個剖析過實體都是形式合法的。
相符document
產生規則式意謂著:
- 它包含一個或多個元素.
- 文件中僅有一個元素稱為根元素 (Root element)或文件元素
(document element),根元素不出現在其他任何元素的內容
(content)中。對於其他元素而言,如果起始標籤 (start-tag)
在另一個元素的內容中,則其結束標籤 (end-tag)
也會在同一元素的內容中。換個更簡單的說法,使用起始標籤和結束標籤作為分隔的各個元素,必須嚴格地依照巢狀的次序來放置
(譯註:不同組的起始標籤與結束標籤不可交叉重疊)。
如此做的結果是,針對每個非根的元素
C
,文件中另有一個元素 P
,C
位於 P
的內容中,而不位於其他被
P
所包含的任何元素的內容中。P
則稱為 C
的父元素
(parent or parent element),而 C
則稱為 P
的子元素
(child or child element) 。
一個剖析過實體包含文本 (text),文本為一串
字元(character)序列,可代表標示或字元資料。一個
字元是 ISO/IEC 10646[ISO/IEC
10646]中定義的文本最小基本單元。合法的字元包括跳位字元 (Tab)、歸位字元
(Carriage return)、換行字元 (Line feed) 以及 Unicode 和 ISO/IEC 10646
中定義的合法圖形字元。不建議使用[Unicode] 6.8
節中定義的"相容字元(compatibility characters)"。
字元範圍 (Character Range) |
[2] |
Char |
::= |
#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD]
| [#x10000-#x10FFFF] |
/* |
除了代用區域 (surrogate block) FFFE 及 FFFF 以外的任意
Unicode 字元。*/ |
|
將字元代碼指定成位元型態的機制,各實體間可能不盡相同。所有的
XML 處理器必須都能接受 10646 中的 UTF-8 和 UTF-16
編碼;指定使用此兩種編碼的其中一種或指定使用其他編碼的機制,將在稍後的"
4.3.3 實體中的字元編碼 "中討論。
本節中定義了一些在文法中廣泛使用的符號。
S
(空白 White space)
包括一個或多個空格字元 (#x20)、歸位字元,換行字元及跳位字元。
空白 (White Space) |
[3] |
S |
::= |
(#x20 | #x9 | #xD | #xA)+ |
|
為了方便起見,字元被分類成字母 (Letters),數字 (Digits)
和其他字元三類。字母可以是英文字母表中的字母,或是一個音節字元
(Syllabic base character)
後面跟著一或多個組合字元,也可以是一個表意字元 (Ideographic
character)。在"B. 字元的分類"中會給予每類字元的完整定義。
名稱(name)是以字母或某些標點符號字元開頭的符記(token),後面會接著字母、數字、連字元、底線、冒號或句號,這些符號統稱為名稱字元(Name
character)。以"xml
"或其他任何相符於 (('X'|'x')
('M'|'m') ('L'|'l'))
的字串開頭名稱,在此版本或後續版本的規格書中被保留使用。(譯註:
表示名稱字元不能以 xml,Xml,...XML 為開頭)
注意:XML 名稱中的冒號被保留給名稱空間 (name space)
測試實驗時使用。它的意義必須等待未來名稱空間的規格標準化,而那時將冒號用於實驗用途的文件可能需要更新。(不保證未來
XML 的名稱空間機制,會採用冒號作為定界符。)實際上,這意謂著除非在測試名稱空間測試實驗時使用,XML
文件作者不應該在 XML 名稱中使用冒號,但 XML
處理器應該接受將冒號視為一個名稱字元 (Name Character)。
Nmtoken
(名稱記符,name token)
是任何名稱字元的混合體。
字面資料 (Literal data)
是任何使用引號括起來的字串,但不包括用來作定界符 (Delimiter)
的引號。字面資料用來指明內部實體的內容 (EntityValue
)、屬性值
(AttValue
)以及外部識別字 (SystemLiteral
)。注意:對於 SystemLiteral
的語法分析不需掃描標示,
也能夠作剖析。
字面資料 (Literals) |
[9] |
EntityValue |
::= |
'"' ([^%&"] | PEReference
| Reference)* '"' |
|
|
|
| "'" ([^%&'] | PEReference
| Reference)* "'" |
[10] |
AttValue |
::= |
'"' ([^<&"] | Reference)*
'"' |
|
|
|
| "'" ([^<&'] | Reference)*
"'" |
[11] |
SystemLiteral |
::= |
('"' [^"]* '"') | "'" [^']* "'")
|
[12] |
PubidLiteral |
::= |
'"' PubidChar* '"' | "'"
(PubidChar - "'")* "'" |
[13] |
PubidChar |
::= |
#x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%] |
|
文本由字元資料和標示混合構成。標示包括起始標籤、結束標籤、空元素標籤(Empty-element tags)、實體參引(Entity references)、字元參引(Character
references)、註解、CDATA 段(CDATA
section delimiters)定界符,文件類型宣告(Document type
declarations) 和處理指示。
所有非標示的文本組成文件的字元資料。
" And " 符號 (&) 和左三角括弧 (<) 只有
作為標示定界符,或在註解、處理指示,或CDATA段中時才能以字面資料形式出現。它們在一個內部實體宣告的字面資料實體數值中也是合法的,參見"4.3.2 形式合法的剖析過實體"。如果在其他地方需要使用到此兩字元,它們必須用數字字元參引來跳脫 (escaped)
本意或分別用字串 "&
" 和 "<
"
來表示。右三角括弧(>)可以用 ">
"
字串來表示,而當它出現在文件內容的"]]>
"
字串中,而此字串並不代表一個CDATA 段的結束定界符時,為了相容性的考量,必須使用 ">
"
或一個字元參引來跳脫本意 (或轉義)。
在元素的內容中,字元資料是不可包括任何標示的起始定界符之任意字串。在一個
CDATA段中,字元資料則為不包括 CDATA 段結束定界符"]]>
"的任意字串。
為了允許在屬性值中包含單引號和雙引號,省略符號或稱單引號
(')可以被表示為 "'
",而雙引號 (")
可以被表示為 ""
"。
字元資料 (Character Data) |
[14] |
CharData |
::= |
[^<&]* - ([^<&]* ']]>' [^<&]*) |
|
註解可以出現在文件中其他標示外的任何位置上。此外,它們可放置在文件類型宣告中文法所允許出現的位置。它們不是文件中字元資料的一部分,XML處理器可以,但不必須提供,讓一個應用能夠檢索出註解文字。針對相容性的考量,字串 "--
" (雙連字元)
不能在註解中出現。
註解 (Comments) |
[15] |
Comment |
::= |
'<!--' ((Char - '-') | ('-' (Char - '-')))* '-->' |
|
註解的一個例子:
<!-- declarations for <head> & <body> --> |
處理指示 (PIs)允許文件中能夠包含應用的指令。
處理指示 (Process Instructions) |
[16] |
PI |
::= |
'<?' PITarget (S
(Char* - (Char* '?>' Char*)))?
'?>' |
[17] |
PITarget |
::= |
Name - (('X' | 'x') ('M' | 'm')
('L' | 'l')) |
|
PI 並不是文件字元資料的一部分,但必須傳遞給應用程式處理。PI
以一個目標名稱(PITarget
)為開頭,此目標名稱
(target) 是用來辨別指示所指向的應用程式,目標名稱"XML
","xml
",等等,保留用於本規範的此版本或後續版本的標準化。XML記法 (notation)機制可以用於 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>
|
下面此例也同樣如此:
<greeting>Hello, world!</greeting>
|
版本編號 "1.0
"是用來表示該文件符合此版本的規格書規定,如果文件中使用版本編號
"1.0
" 不過並不符合此版本的規格書,則會有錯誤。XML
工作組計劃開發本規格書的後續版本,而該版本編號就會不同於"1.0
"
(譯註: 可能為 1.1 或 1.2),但這並不表示一定會開發後續版本,也不表示如果有了後續版本,會使用任何特殊版本編號的命名方式。由於並不排除有後續版本的可能,因此提供本建構
(Construct)
作為一旦需要時能自動識別版本的方法。當處理器接收的文件標籤中有處理器不支援的版本時,會送出一個錯誤訊息。
XML文件中標示的功能是描述文件的儲存格式和邏輯結構,並將屬性與值組(Attribute-value
pairs) 和邏輯結構做關聯。XML提供一種文件類型宣告
(Document type declaration)
的機制,用來定義邏輯結構的限制,並支援使用預先定義儲存單元。如果一個 XML
文件有對應的文件類型宣告並且遵循其中所描述的限制,則稱此文件是正確合法的
(valid)。
文件類型宣告必須位於文件第一個元素 (譯註:
即根元素) 之前。
XML文件類型宣告包含或指向標示宣告,此標示宣告提供某一類文件的文法。此種文法被稱為文件類型定義
(Document type definition,DTD)。文件類型定義可以指向一個包含標示宣告的外部子集
(一種特殊類型的外部實體),或可以在一個內部子集中直接包含標示宣告,或兩者混合使用。一個文件的文件格式定義由此兩子集合一同組成。
標示宣告可以是元素類型宣告(Element
type declaration)、屬性表宣告(Attribute-list declaration)、實體宣告或是記法宣告。這些宣告可以全部或部分地包含在參數實體中,如同接下來要說明的形式合法性
(well-formedness) 和正確合法性 (valid) 的限制,完整的資訊參見"4. 物理結構"。
文件類型定義 (Document Type Definition) |
|
標示宣告可以全部或部分地由參數實體的置換文本 (replacement text)
所組成。本規格書稍後個別非終端符號(elementdecl
,AttlistDecl
,等等)
的產生規則式會描述將所有參數實體被包含(include)之後的宣告。
正確合法性限制: 根元素類型 (Root Element Type)
文件類型宣告中的Name
必須相符根元素的類型。
正確合法性限制: 嚴格的宣告 / PE 巢狀結構
參數實體的置換文本必須用標示宣告嚴格地使用巢狀次序來排列。也就是說,如果一個標示宣告
(上面的markupdecl
)
的第一個,或者最後一個字元被包含於一個參數實體參引的置換文本中,兩者必須都包含在此置換文本中。
形式合法性限制: 內部子集中的 PEs
在內部 DTD 子集中,參數實體參引只能出現在標示宣告可以出現的地方,而不能在標示宣告內部出現。(這個限制不適用於出現在外部參數實體內的參引,也不適用於外部子集。)
如同內部子集一樣,外部子集和任何DTD中參引的外部參數實體,必須由一系列非終端符號markupdecl
所允許的完整標示宣告所組成,其中可以混雜空白字元或參數實體參引。然而,外部子集和外部參數實體的部分內容可以經由使用條件段 (conditional section)有條件地將之忽略,在內部子集中則不允許這項動作。
外部子集和外部參數實體與內部子集還有不同之處在於:參數實體參引不僅只能出現在標示宣告之間,也允許出現在標示宣告之內。
以下是一個擁有文件類型宣告的 XML文件例子:
<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>Hello, world!</greeting>
|
系統識別字 (system identifier) "hello.dtd
"提供了文件
DTD 的 URI。
也可如同下面例子一樣在同個文件上 (locally) 直接提供宣告:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
<!ELEMENT greeting (#PCDATA)>
]>
<greeting>Hello, world!</greeting>
|
如果同時使用外部和內部子集,內部子集會在外部子集之前發生,這表示內部子集中的實體和屬性列表宣告的優先順序要比外部子集為先。
當文件從XML 處理器傳遞給應用程式來處理時,標示宣告會影響它的內容,屬性預設值和實體宣告就是其中的例子。獨立文件宣告為
XML 宣告的一部份,它能指出文件實體是否存在外部的宣告。
獨立文件宣告 (Standalone Document Declaration) |
[32] |
SDDecl |
::= |
S 'standalone' Eq
(("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no')
'"')) |
[ |
VC: 獨立文件宣告 ] |
|
在一個獨立文件宣告中,設定值"yes
"表示文件實體沒有外部的標示宣告 (不論是在 DTD
外部子集中,還是從內部子集中的外部參數實體參引),如此會影響從
XML 處理器傳遞給應用程式的資訊。設定值"no
"表示有或可能存在外部標示宣告。請注意獨立文件宣告只是表示外部宣告的存在,如果文件中存在對外部實體的引用,而當這些實體在內部宣告時,並不影響文件的獨立狀態。
如果沒有外部標示宣告,獨立文件宣告沒有意義。如果有外部標示宣告,但沒有獨立文件宣告,則假定設定值為
"no
"。
任何擁有standalone="no"
設定的 XML
文件可通過演算法將之轉換成獨立文件。而某些網路傳輸應用程式可能需要獨立的文件,
正確合法性限制 : 獨立文件宣告
獨立文件宣告必須將值設定為 "no
",如果任何外部標示宣告中包含:
- 有預設值的屬性宣告,如果套用這些屬性的元素出現在文件中而沒有給予這些屬性設定值的話,或
- 實體 (除了
amp
,lt
,gt
,apos
,quot
的實體之外)
參引出現在文件中的話,或
- 需要規範化的屬性值宣告,如果這些出現在文件中的屬性值,會因為規範化而改變的話,或
- 具有元素型內容的元素類型宣告,如果在這些類型的任一實例中直接出現空白的話。
具有獨立文件宣告的 XML宣告例子:
<?xml version="1.0" standalone='yes'?> |
在編輯 XML 文件時,使用"空白"(空格、跳位字元及空行,在本規格書中用非終端符號S
來表示)
來將標示分隔以增進可讀性是很方便的。一般文件可交付的版本
(delivered version)
中並不想要包括這些空白。另一方面,在可交付的版本中必須保留有意義的空白字元也是蠻常見的,例如在詩歌及原始碼中的空白字元。
XML 處理器總是必須將所有不是標示的字元傳送給應用程式。一個驗證正確合法的 XML 處理器必須同時通知應用程式在這些字元中,那些字元組成了出現在元素內容中的空白。
可在元素中附加一個名稱為xml:space
的特殊屬性,以通知應用程式應該保留此元素中的空白。在正確合法的文件中,此屬性和其他屬性一樣,使用時必須先宣告。宣告時它必須被設定為列舉類型
(enumerated type),此類型只有"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],"為了辨識語言的標籤"中定義的語言識別字:
語言辨識 (Lang Identification) |
[33] |
LanguageID |
::= |
Langcode ('-' Subcode)* |
[34] |
Langcode |
::= |
ISO639Code | IanaCode | UserCode |
[35] |
ISO639Code |
::= |
([a-z] | [A-Z]) ([a-z] | [A-Z]) |
[36] |
IanaCode |
::= |
('i' | 'I') '-' ([a-z] | [A-Z])+ |
[37] |
UserCode |
::= |
('x' | 'X') '-' ([a-z] | [A-Z])+ |
[38] |
Subcode |
::= |
([a-z] | [A-Z])+ |
|
Langcode
可以是如下設定值:
- 由[ISO 639],"表示語言名稱的代碼"中定義兩個字母的語言碼。
- 在 Internet Assigned Numbers Authority [IANA]註冊的語言辨識碼,使用"
i-
"(或"I-
")的前置字
(prefix) 為開頭。
- 使用者自訂或經由各方同意的專用語言識別字,必須使用 "
x-
"或"X-
"
的前置字為開頭,以保證它們不會和未來經由 IANA 標準化或在 IANA
註冊的名稱相衝突。
可以有任意多個子代碼(Subcode)
區段,如果存在第一個子代碼區段,並且子代碼由兩個字母組成,則此子代碼必須是[ISO3166],"表示國家名稱的代碼"中定義的國家代碼。如果第一個子代碼多於兩個字母,則它必須是在
IANA 註冊語言的子代碼,除非Langcode
是使用"x-
"或"X-
"前置字為開頭。
習慣上語言代碼會使用小寫字母,國家代碼 (如果有的話)
會使用大寫字母。請注意這些值與 XML
文件中其他名稱不同,它們是與大小寫無關的。
舉例如下:
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
<p xml:lang="en-GB">What colour is it?</p>
<p xml:lang="en-US">What color is it?</p>
<sp who="Faust" desc='leise' xml:lang="de">
<l>Habe nun, ach! Philosophie,</l>
<l>Juristerei, und Medizin</l>
<l>und leider auch Theologie</l>
<l>durchaus studiert mit hei遝m Bem黨'n.</l>
</sp> |
xml:lang
表示所指定的語言設定能套用於所處元素的所有屬性和內容,除非被內容中元素內的另一個xml:lang
屬性的設定值所取代。
一個簡單的xml:lang
宣告可以採用如下形式:
xml:lang NMTOKEN #IMPLIED |
然而若在適當的情況下也可以指定特定的預設值。在一本給英國學生使用的法文詩歌選集中,評註
(glosses) 和註解 (notes) 使用英語,則 xml:lang屬性可以如下列方式宣告:
<!ATTLIST poem xml:lang NMTOKEN 'fr'>
<!ATTLIST gloss xml:lang NMTOKEN 'en'>
<!ATTLIST note xml:lang NMTOKEN 'en'> |
每個XML文件包含一個或多個元素,這些元素的邊界使用起始標籤和結束標籤分隔,或者對於空元素來說,使用一個空元素標籤來分隔。每一個元素使用名稱來辨識種類,這些名稱有時稱為元素的"通用識別字
(generic identifier)"(GI),同時它可以有一個屬性值設定 (attribute
specification)集。每一個屬性值設定有一個名稱和一個設定值。
除了那些開頭相符 (('X'|'x')('M'|'m')('L'|'l'))
的字串,在此版本或後續版本的規格書中被保留使用外,本規格書不對元素種類和屬性的語義,用法和名稱
(語法之外) 做任何限制。
形式合法性限制: 元素種類相符
元素結束標籤中的名稱
必須和起始標籤中的元素種類相符。
正確合法限制: 元素正確合法性
如果有一個與elementdecl
相符的宣告名稱
與元素類型相符且下述任一項成立時,則稱此元素是正確合法的:
- 此宣告與
EMPTY
相符,同時此元素沒有內容。
- 此宣告與
children
相符,同時子元素的序列屬於內容模型中的正則運算式所產生的語言,在每對子元素間允許有空白(相符非終端符號S
的字元)。
- 此宣告與
Mixed
相符,並且內容由種類相符於內容模型中名稱的字元資料和子元素組成。
- 此宣告與
ANY
相符,並且任何子元素的種類都已經宣告。
每個不是空的 XML 元素使用一個起始標籤作為開始標示。
起始標籤和結束標籤中的Name
提供元素的種類。Name
-AttValue
對被稱為元素的屬性值設定,其中每一對中的Name
被稱為屬性名稱,AttValue
的內容(在'
或"
定界符之間的文字)
被稱為屬性值。
形式合法性限制: 唯一的屬性值設定
一個屬性名稱只能在同一個起始標籤或空元素標籤中出現一次。
正確合法限制: 屬性值種類
屬性必須被宣告,其值必須是具有宣告的種類。(屬性種類參見"3.3 屬性表宣告"。)
形式合法性限制: 無外部實體參引
屬性值不能包含對外部實體直接或間接的實體參引。
正確合法性限制: 在屬性值中沒有<
在一個屬性值中直接或間接實體參引的置換文本
(除了"<
")不能包含<
。
起始標籤的一個例子:
<termdef id="dt-dog" term="dog"> |
每個由一個起始標籤開始的元素必須使用一個結束標籤標示其結束,結束標籤中的名稱必須與起始標籤中給予的元素種類相同:
結束標籤 (End-tag) |
[42] |
ETag |
::= |
'</' Name S? '>' |
|
結束標籤的一個例子:
在起始標籤和結束標籤中的文本被稱為元素的內容:
元素的內容 (Content of Elements) |
|
如果元素的內容是空的,它必須被表示為一個起始標籤緊跟一個結束標籤或空元素標籤。空元素標籤採用一種特殊的形式:
空元素標籤 (Tags for Empty Elements) |
|
不論元素是否用關鍵字EMPTY
來宣告,空元素標籤都可以用於任何沒有內容的元素。若針對於互通使用,則空元素必須用於且只能用於宣告成EMPTY
的元素。
空元素的例子:
<IMG align="left"
src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/> |
為了驗證 (validation)
的目的,可以使用元素類型和屬性表宣告來限制XML文件中元素的結構。元素類型宣告限制了元素的內容。
元素類型宣告通常限制了子元素可以出現的類型。由使用者選擇,當宣告提到的元素類型沒有相對應的宣告時,XML
處理器可以提出警告,但這並不是一個錯誤。
元素類型宣告形式如下:
元素類型宣告 (Element type declaration) |
|
其中Name
設定了所宣告的元素類型。
正確合法性限制: 唯一的元素類型宣告
元素類型只能宣告一次。
元素類型宣告的例子:
<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY> |
當某一類型的元素只能包含子元素(無字元資料),且可選用空白 (相符非終端符號S
) 來做分隔時,稱此元素類型具有元素型內容。在這種情況下,這限制包含了內容模型,內容模型是用來控制子元素可出現的類型和子元素可出現順序的一種簡單文法。此文法用內容粒子(Content Particles,cp
)來建構,內容粒子由名稱,內容粒子的選擇表(choice
list)或內容粒子的序列表(sequence list)組成:
元素型內容的模型 (Element-content Models) |
|
其中每個Name
是可以出現的子元素元素類型。任何在選擇表中出現的內容粒子在元素型內容中允許出現的位置對應於選擇表在文法中的位置。序列表中出現的所有內容粒子必須以相同的順序出現在元素型內容中。在名稱或列表之後的可選字元
(optional character) 決定了表中元素或內容粒子可以出現一次或多次(+
),還是零次或多次(*
),或是零次或一次(?
)。若沒有使用如此的操作符號表示元素或內容粒子必須恰好出現一次。這種語法和意義和本規格書中的產生規則式中所使用的相同。
只有當元素的內容可以透過內容模型的追蹤路徑,及遵守序列,選擇與重複操作符號,並且內容中的每一個元素與內容模型中的一種元素類型相符時,則此元素的內容與該內容模型相符。針對相容性的考量,若文件的某個元素可以與內容模型中的元素類型不只一次相符,則會發生錯誤。更詳細的資訊參見"E. 確定型內容模型"。
正確合法性限制: 嚴格的群組/PE巢狀結構
參數實體的置換文字嚴格地以巢狀結構使用括弧來組成。這就是說,如果choice
,seq
或Mixed
組成文字的開始或結束括弧出現在某個參數實體的置換文字中,則兩者必須包含在同一個置換文字中。基於互通性考量,如果一個參數實體參引出現在choice
,seq
或Mixed
組成文字中時,它的置換文字不應該為空,同時其置換文字的第一個和最後一個非空字元不應為一個連接符號
(|
或,
)。
以下是元素型內容模型的實例:
<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*> |
當某類型的元素可以包含字元資料,且其間可以任意插入子元素時,稱此元素類型具有混合型內容。在這種情況下,對子元素的類型可能有所限制,但對順序和出現次數則並無限制:
其中Name
給予子元素可出現的元素類型。
正確合法性限制: 無重覆類型
同一名稱在單個混合型內容宣告中只能出現一次。
混合內容宣告的例子:
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)> |
屬性是用於將一對名稱與值 (name-value pair)和元素關聯起來。屬性值設定只能在起始標籤和空元素標籤中出現;
因此,用於識別它們的產生規則式會在"3.1 起始標籤、結束標籤和空元素標籤"中出現。屬性表宣告可以用於:
屬性表宣告設定了給定元素類型相關聯的每個屬性之的名稱,資料類型和預設值
(如果有的話):
屬性表宣告 (Attribute-list Delcaration) |
|
AttlistDecl
規則中Name
是元素的類型。由使用者選擇,當屬性宣告的相關元素類型並沒有被宣告時,XML
處理器可以發生警告,但這並非是個錯誤。AttDef
規則中的Name
是屬性的名稱。
當給定元素類型的AttlistDecl
超過一個時,這些宣告的內容會被合併起來。當給定元素類型的同一個屬性的定義超過一個時,會連結到第一個定義,往後的定義會被忽略。基於互動性的考量,DTD
的撰寫者可能會選擇對於給定的元素類型,最多有一個屬性表宣告,一個給定的屬性名稱最多一個屬性定義,以及每個屬性表宣告最少有一個屬性定義。基於互動性的考量,當給定元素有超過一個的屬性表宣告或給定屬性有超過一個的屬性定義時,XML
處理器可以依照使用者選擇給予警告,不過這並非是個錯誤。
XML 屬性有三種類型:字串類型、一組符記化 (tokenized) 類型和列舉
(enumerated) 類型。字串類型可以使用任意字面資料字串為值;各個符記化類型有不同的詞彙法和語意限制,如下所示:
正確合法性限制: ID
ID
類型的值必須相符於Name
的產生規則式。作為
ID 類型值的名稱在 XML 文件中只能出現一次;亦即 ID
的值必須是唯一能標別元素的值。
正確合法性限制: 每種屬性類型一個 ID
每種屬性類型只能有一個 ID 屬性。
正確合法性限制: ID 屬性的預設值
ID 屬性必須有一個宣告為#IMPLIED
或#REQUIRED
的預設值。
正確合法性限制: IDREF
IDREF
類型的值必須相符於Name
的產生規則式,IDREFS
類型的值必須相符Names
的產生規則式;每一個Name
必須相符
XML 文件中某些元素 ID 屬性的值;也就是說,IDREF
類型的值必須相符某些
ID 屬性的值。
正確合法性限制: 實體名稱
ENTITY
類型的值必須相符於Name
的產生規則式,ENTITIES
類型的值必須相符於Names
的產生規則式;每一個Name
必須相符DTD中宣告的未剖析實體的名稱。
正確合法性限制: 名稱符記
NMTOKEN
類型的值必須相符於Nmtoken
的產生規則式;NMTOKENS
類型的值必須相符於Nmtokens的產生規則式。
列舉類型的屬性可以在宣告提供的值列表中取得其中的設定值。有兩種列舉類型:
列舉屬性類型 (Enumerated Attribute Types) |
|
一個NOTATION
類型的屬性可識別一種記法,在
DTD 中宣告中,此記法使用相關的系統 (system) 和/或公共 (public)
識別字,且用於解譯此屬性的相關元素。
正確合法性限制: 記法屬性
此類型的值必須與宣告中所包含的記法名稱之一相符合;宣告中的所有記法名稱都必須宣告。
正確合法性限制: 列舉
此類型的值必須與宣告中包含的Nmtoken
記號之一相符合。
基於互通性考量,同一Nmtoken
只能在單個元素類型的列舉屬性類型中出現一次。
屬性宣告提供某屬性是否須要出現的資訊,若不需出現的話,且文件中沒有出現此宣告的屬性時
XML 處理器應如何處理。
屬性預設值 (Attribute Defaults) |
|
在一個屬性宣告中,#REQUIRED
表示必須永遠提供屬性,#IMPLIED
表示不提供預設值。如果宣告既不是#REQUIRED
,也不是#IMPLIED
,則AttValue
值包含了所宣告的預設值;關鍵字#FIXED
規定此屬性必須永遠有預設值。如果宣告了一個預設值,當
XML 處理器遇到屬性被省略時,此屬性會以宣告時的預設值存在
正確合法性限制: 必須的屬性
如果預設值宣告使用關鍵字#REQUIRED
,則屬性表宣告所指類型的元素中都必須有此屬性。
正確合法性限制: 合法的屬性預設值
被宣告的屬性預設值必須滿足被宣告屬性類型的詞法限制。
正確合法性限制: 固定的屬性預設值
如果某屬性的預設值用關鍵字#FIXED
宣告,此屬性的實例必須相符於該預設值。
屬性表宣告的例子:
<!ATTLIST termdef
id ID #REQUIRED
name CDATA #IMPLIED>
<!ATTLIST list
type (bullets|ordered|glossary) "ordered">
<!ATTLIST form
method CDATA #FIXED "POST"> |
在將屬性值傳送給應用程式或檢驗正確合法性之前,XML
處理器必須依照下列將其規範化:
- 對字元參引的處理方式是將被引用的字元附加在屬性值之後
- 對實體參引的處理是遞迴地處理實體的置換文字
- 對空白字元 (#x20、#xD、#xA 與 #x9) 的處理是將 #x20
附加於規範化的值之後,例外是對作為內部剖析過實體或內部剖析過實體字面實體值一部分的
"#xD#xA" 字元序列只會附加一個 #x20。
- 對於其他字元的處理是將它們附加於規範化的值之後
如果被宣告的值不是 CDATA,則 XML
處理器必須進一步處理規範化後屬性的值,去掉其前置和尾隨的空格
(#x20) 字元,並將空格 (#x20) 字元序列替換成單個空格 (#x20) 字元。
所有未宣告的屬性,應該被非進行驗證剖析器 (non-validating parser)
當成宣告為CDATA
。
條件段是文件類型宣告外部子集的一部分,它們被包含在
DTD 邏輯結構之內,或被排除在 DTD
邏輯結構之外,根據於支配它們的關鍵字。
條件段 (Conditional Section) |
|
就像內部或外部 DTD
子集一樣,條件段可以包含一個或多個完整的宣告,註解,處理指示,或巢狀的條件段,其中可以夾雜空白。
如果條件段的關鍵字是 INCLUDE
,則條件段的內容是 DTD
的一部分,如果條件段的關鍵字是IGNORE
,則條件段的內容不是
DTD
邏輯上的一部分。針對可靠的剖析過程來說,被忽略的條件段內容必須被讀取,目的是為了檢測條件段的巢狀結構,並保證能適當地檢測到最外層的
(被忽略的) 條件段結尾。如果一個使用關鍵字INCLUDE
的條件段出現在使用關鍵字IGNORE
的更大條件段中,內外兩個條件段都會被忽略。
如果條件段的關鍵字是一個參數實體參引,處理器在決定是否包含或忽略此條件段前,必須先將該參數實體置換成其內容。
一個例子:
<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >
<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>
<![%final;[
<!ELEMENT book (title, body, supplements?)>
]]>
|
一個 XML
文件可能包含一個或多個儲存單元。它們被稱為實體(entity);它們都具有內容並且都以名稱來做識別
(除了文件實體和外部 DTD 子集之外,詳見下面說明)。每一個
XML 文件都有一個稱為文件實體 (document entity)的實體,它作為XML 處理器的處理起點,並可以包含了整個文件。
實體可以是已剖析的或未剖析的。剖析過實體(parsed
entity)的內容被稱為它的置換文本;此文本被看成是文件整體的一部分。
未剖析實體(unparsed entity)是一種資源,其內容可以是也可以不是文字,且若為文字的話,可以不是 XML。每個未剖析實體有一個相關的記法,此記法使用名稱來做識別。除了要求 XML
處理器能向應用程式提供實體和記法的識別字之外,XML
對未剖析實體的內容不作任何限制。
剖析過實體以實體參引的方式使用名稱來做引用;未剖析實體用ENTITY
或ENTITIES
屬性中所提供的名稱來引用。
通用實體 (general entity)是那些在文件內容中使用的實體。在本規格書中,通用實體有時會使用未核可的術語entity來表示。參數實體是用於DTD
內的剖析過實體。這兩類實體用不同形式的參引方式,且在不同的上下文中被識別。此外,它們使用不同的名稱空間;具有相同名稱的參數實體和通用實體是完全不同的兩個實體。
一個字元參引會引用 ISO/IEC 10646
字元集中的一個字元。例如不能用輸入設備直接輸入的字元。
字元參引 (Character and Entity References) |
[66] |
CharRef |
::= |
'&#' [0-9]+ ';' |
|
|
|
| '&#x' [0-9a-fA-F]+ ';' |
[ |
WFC: 合法字元 ] |
|
形式合法性限制: 合法字元
用字元參引引用的字元必須相符於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.
This document was prepared on &docdate; and
is classified &security-level;. |
參數實體引用的例子:
<!-- declare the parameter entity "ISOLat2"... -->
<!ENTITY % ISOLat2
SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... now reference it. -->
%ISOLat2; |
實體使用下列方式宣告:
實體宣告 (Entity Declaration) |
|
Name
辨識了在實體參引中的實體;或針對未剖析實體的情況,辨識了ENTITY
或ENTITIES
屬性值中的實體。如果同樣的實體被宣告了不止一次,則會連結到第一個遇到的宣告。由使用者選擇,如果實體被多次宣告,XML處理器可以提出警告。
如果實體定義是一個EntityValue
,被定義的實體被稱為內部實體。內部實體沒有單獨的物理
(Physical) 儲存物件,實體的內容在宣告中提供。注意字面實體值中一些實體和字元參引的處理可能要求產生正確的置換文字:參見"4.5 內部置換文字的構造"。
內部實體是剖析過實體。
內部實體宣告的例子:
<!ENTITY Pub-Status "This is a pre-release of the
specification."> |
如果實體不是內部的,則它是一個外部實體,宣告如下:
如果有NDataDecl
,則此為一般的未剖析實體;否則它是一個剖析過實體。
正確合法性限制: 宣告記法
Name
必須與記法的名稱相符。
SystemLiteral
被稱為該實體的系統識別字。此為一個
URI,可以用來存取此實體。注意井號 (#
) 和 URI
中常使用的識別字片段在形式上並非 URI
的一部分;如果所提供的識別字片段為系統識別字的一部分,則 XML
處理器可以送出一個錯誤訊息。除非在本規範書範圍之外的資訊,所提供的例外情況
(例如一個特殊 DTD 中定義的特定使用的 XML
元素類型,或一個特殊應用程式規範中定義的處理指示),相對 URI
是指相對於實體宣告發生的資源位置。因此,一個 URI 可能相對於文件實體,或相對於包含外部 DTD
子集的實體,或相對於一些其他的外部參數實體。
XML 處理器處理 URI 中的非 ASCII 字元時,應該將 UTF-8
中的字元用一個或多個位元組表示,然後將這些字元使用 URI
跳脫機制來跳脫本意 (即為將每個位元組轉換成 %HH,其中 HH
是位元組值的十六進位記法)。
除了系統識別字之外,外部識別字還可以包含公共識別字。試圖存取實體內容的
XML 處理器,可以使用公共識別字試著產生另一個不同的 URI。如果處理器無法做到此點,則它必須使用系統識別字
(systemLiteral) 所指定的 URI。在試圖相符之前,公共識別字中所有空白字串必須被規範成為單獨的空格字元(#x20),同時必須將前置及尾隨空白移除。
外部實體宣告的例子:
<!ENTITY open-hatch
SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY open-hatch
PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
"http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY hatch-pic
SYSTEM "../grafix/OpenHatch.gif"
NDATA gif > |
每個外部剖析過實體可使用文本宣告作為開始。
文本宣告必須以字面上的形式來提供,而不能透過剖析過實體的引用。文本宣告除了能出現在外部剖析過實體的開頭之外,並不允許在其他任何位置出現。
如果文件實體相符document
產生規則式,則它是形式合法的。如果外部普通剖析過實體相符extParsedEnt
產生規則式,則它是形式合法的。如果外部參數實體相符extPE
產生規則式,則它是形式合法的。
規範的外部剖析過實體 (Well-Formed Parsed Entity) |
|
如果內部普通剖析過實體的置換文字相符content
產生規則式,則它是形式合法的。根據定義,所有內部的參數實體都是形式合法的。
在實體中符合形式合法性的結果是,XML
文件中的邏輯和物理結構是嚴格符合巢狀結構的;起始標籤,結束標籤,空元素標籤,元素,註解,處理指示,字元參引,或實體參引都不能在一個實體中開始而在另一個實體中結束。
XML
文件中的每個外部剖析過實體都可以對其字元採用不同的編碼。所有
XML 處理器必須能讀取 UTF-8 或 UTF-16 編碼的實體。
以 UTF-16 編碼的實體必須以 ISO/IEC 10646 增補 E 和 Unicode 附錄 B (零寬度不中斷空格字元
ZERO WIDTH NO-BREAK SPACE,#xFEFF)中所描述的位元組順序標示(Byte Order Mark)
開頭。此為一個編碼簽名,即不是 XML 文件中標示的一部分,也不是
XML文件字元資料的一部分。XML 處理器必須能使用此字元來區別 UTF-8
編碼和 UTF-16 編碼的文件。
雖然 XML 處理器只被要求能讀取 UTF-8 和 UTF-16
編碼的實體,不過對於世界上還有使用其他的編碼方式 (譯註:
例如國內使用的繁體中文 Big5 碼) 則已有共識。有時可能會想讓 XML
處理器讀取以其他編碼方式編碼的實體。以不同於 UTF-8 和 UTF-16
的編碼方式儲存的實體必須以包含編碼宣告的文本宣告做開頭:
編碼宣告 (Encoding Declaration) |
[80] |
EncodingDecl |
::= |
S 'encoding' Eq ('"' EncName '"' | "'" EncName
"'" ) |
[81] |
EncName |
::= |
[A-Za-z] ([A-Za-z0-9._] | '-')* |
/* |
編碼的名稱只包含拉丁字母 */ |
|
在文件實體中,編碼宣告是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)的方式),除了上面所列的之外,引用時應該使用其註冊名稱。注意這些註冊名稱是定義為不區別大小寫的
(case-insensitive),因此欲與之相符的處理器要使用不區分大小寫的方式。
在缺少外部傳輸協定 (如 HTTP 或 MIME)
所提供的資訊時,以下情況皆為錯誤:XML
處理器接收到的實體編碼方式與實體所含編碼宣告中指出的編碼方式不同,編碼宣告不在外部實體的開頭,或既不以位元組順序標示開頭,也不以編碼宣告開頭的實體使用了不同於
UTF-8 的編碼。注意因為 ASCII 是UTF-8 的一個子集,一般的 ASCII
字元實體並不嚴格地需要編碼宣告。
當 XML 處理器遇到的實體使用了它不能處理的編碼時,則會是個嚴重錯誤。
編碼宣告的例子:
<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?> |
下表針對了字元參引,實體參引及對未剖析實體的叫用,將之彙總可以出現的上下文,以及每種情況下XML 處理器所需進行的動作。
最左邊一欄的標籤描述了識別時的上下文:
- 內容中的引用
- 可以在元素的起始標籤之後,結束標籤之前的任何地方以引用形式出現,對應於非終端符號
content
。
- 屬性值中的引用
- 可以在起始標籤內的屬性值中,或屬性宣告內的預設值中以引用形式出現;對應於非終端符號
AttValue
。
- 當作屬性值時
- 可以使用
Name
而並不是以引用的方式,作為宣告ENTITY
類型的屬性值,或可以作為宣告ENTITIES
類型的屬性值中的以空白分隔的符記之一。
- 實體值中的引用
- 可以在參數中或內部實體的實體宣告內字面實體值中以引用形式出現;對應於非終端符號
EntityValue
。
- DTD中的引用
- 可以在DTD的內部或外部子集中以引用形式出現,但須在
EntityValue
和AttValue
之外。
在 DTD 之外,百分比字元%
沒有特殊含義;因此在 DTD
中的參數實體參引在content
中不被當成標示識別。同樣地,除非未剖析實體的名稱出現在已適當宣告的屬性值中,否則它們不被識別。
當一個實體的置換文字被當成在引用位置的文件一部分一樣被存取和處理時,稱此實體被包含。其置換文字可以包含字元資料和標示(不包括參數實體),其中標示必須使用一般的方式來識別,但用於跳脫本意標示定界符(實體amp
,lt
,gt
,apos
和quot
)的實體置換文字總是被當成資料。(字串"AT&T;
"展開成"AT&T;
"尚存的"and"符號&不被識別為實體參引的定界符。)當所指的字元被當成引用位置的文字一樣被處理時,稱此字元參引被包含。
當 XML 處理器識別出一個針對剖析過實體的引用,為了驗證該文件,處理器必須包含此實體的置換文字。如果實體是外部的,而處理器不試圖驗證該
XML文件,則處理器可以,但不是必須,包含此實體的置換文字。如果一個非驗證剖析器不包含此置換文字,它必須通知識別出但沒有讀取此實體的應用程式。
此條規則基於一個共識:由 SGML 和 XML 的實體機制提供的自動包含
(Automatic inclusion)
機制,起初是設計用來支援模組化創作的,不一定適合於其他應用程式,特別在文件瀏覽上。例如,當瀏覽器遇到一個外部剖析過實體引用時,可能選擇用視覺化方式表示其存在,並且只會在被請求時才讀取它進行顯示。
下列的情況會被禁止,並構成一個嚴重錯誤:
當實體引用出現在屬性值中或參數實體引用出現在字面資料實體值中時,它們的置換文本被當成出現在引用所在位置文件的一部分一樣被存取和處理,置換文本中的單雙引號總是被當成正常的資料字元而不會結束此字面上資料。例如,下面的例子是形式合法的:
<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said &YN;" > |
而下面的例子則不是形式合法的:
<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;> |
當未剖析實體名稱當成符記在宣告為ENTITY
或ENTITIES
類型的屬性值中出現時,進行驗證的處理器必須將此實體和它的相關記法的系統和公共(如果有的話)識別字通知給應用程式。
當實體宣告內一個通用實體引用出現在EntityValue
中時,它不會被處理且維持不變。
正如同外部剖析過實體一樣,參數實體只需在進行驗證時被包含。當參數實體引用在
DTD 中被識別並且被包含時,它的置換文本藉由前後各加上一個空格字元
(#X20) 來擴大範圍;其目的在於強制參數實體的置換文本包含整數個 DTD
中的文法記符。
在討論內部實體的處理時,區分兩種形式的實體值是有幫助的。字面資料實體值(literal entity value)是實際出現在實體宣告中用引號擴起的字串。對應於非終端符號EntityValue
。置換文字(replacement
text)是置換了字元參引和參數實體引用後的實體內容。
在內部實體宣告(EntityValue
)中提供的字面上資料實體值可以包括字元參引,參數實體引用和通用實體引用。如此的引用必須整個被包含在字面上資料實體值中。如前述方式被包含的實際置換文字必須包含所有被引用的參數實體的置換文字,同時所有被引用的字元必須在字面上資料實體值中字元參引所在位置被包含。但通用實體的引用必須保持不變,不被展開。例如,如果有以下的宣告:
<!ENTITY % pub "Éditions Gallimard" >
<!ENTITY rights "All rights reserved" >
<!ENTITY book "La Peste: Albert Camus,
© 1947 %pub;. &rights;" > |
則實體"book
"的置換文本為:
La Peste: Albert Camus,
?nbsp;1947 蒬itions Gallimard. &rights; |
一旦引用"&book;
"出現在文件的內容或屬性值中時,通用實體引用"&rights;
"應該被展開。
這些簡單的規則將可能會出現複雜的相互作用;參見"D. 實體和字元參引的展開"中會對於一個較為困難的例子做詳細討論。
實體和字元參引都可以用於跳脫左尖括弧,"and"號(&)和其他定界符。通用實體集合(amp
,lt
,gt
,apos
,quot
)特別針對於此目的。也可以使用數值字元參引;
它們一旦被識別就會立即被展開,同時它們必須被當成字元資料,因此數值字元參引"<
"和"&
"可以用於跳脫本意出現在字元資料中的<
和&
。
不管這些實體是否被宣告,所有的 XML 處理器必須能識別它們。基於互通性考量,正確合法的 XML
文件應該如同其他實體一樣,在使用這些實體前先宣告它們。如果宣告的話,這些實體必須被宣告為內部實體,其置換文字是被跳脫本意的單個字元或指向這個字元的字元參引。如下所示。
<!ENTITY lt "&#60;">
<!ENTITY gt ">">
<!ENTITY amp "&#38;">
<!ENTITY apos "'">
<!ENTITY quot """>
|
注意在"lt
"和"amp
"的宣告中,<
和&
跳脫本意兩次,這是為了滿足實體置換的形式合法性要求。
記法用名稱標識了未剖析實體的格式,具有記法屬性的元素的格式,以及處理指示所針對的應用程式的格式。
記法宣告提供記法一個可用於實體中,屬性表宣告中和屬性值說明中的名稱,同時也提供了一個記法的外部識別字,使得
XML
處理器或它的客戶應用程式,可以將給定記法中處理資料的助理應用程式來定位。
記法宣告 (Notation Declarations) |
|
XML
處理器必須向應用程式提供任何在屬性值中,屬性定義中或實體宣告中定義或引用的記法的名稱和外部識別字。它們還可以將外部識別字解析成系統識別字,檔案名稱,或是允許應用程式呼叫處理器處理記法描述資料的其他所需資訊。(然而
XML 處理器或應用程式所執行的系統中,沒有處理 XML文件宣告和引用的特定記法應用程式,此並非是一個錯誤。)
文件實體 (document entity)視為實體樹的根和XML 處理器的處理起點。本規格書沒有規定 XML
如何定位文件實體;它與其他實體不同,文件實體沒有名稱,而且可以完全不帶任何標識地出現在處理器的輸入資料流中。
合乎規範的XML 處理器可以分為兩類:進行驗證的和不進行驗證的。
進行驗證和不進行驗證的處理器都必須告知在文件實體和任何剖析過實體的內容,違反本規格書形式合法性限制的情況。
進行驗證的處理器必須告知違反DTD宣告中所述限制的情況以及不滿足本規格書中提供的正確合法性限制的情況。
要完成這一點,進行驗證的 XML 處理器必須讀取和處理整個 DTD
和所有在文件中引用的外部剖析過實體。
不進行驗證的處理器只被要求檢查文件實體和整個內部
DTD 子集的形式合法性。雖然它們不被要求檢查文件的正確合法性,不過它們必須處理讀取的所有內部
DTD 子集中的宣告和所有參數實體,直到遇到第一個尚未讀取的參數實體引用;也就是說,它們必須根據這些宣告中的資訊來將屬性值規範化,包含內部實體的置換文本,並提供預設屬性值。它們在遇到第一個對尚未讀取的參數實體之引用後,不應處理其後的實體宣告或屬性表宣告,因為此實體中包含的宣告可能覆蓋前面的宣告。
進行驗證的處理器之行為是高度可預測的 (highly predictable);它必須讀取文件的所有部分,告知所有違反形式合法與正確合法的情況。對一個不進行驗證處理器的要求會比較低一點;因為它不需要讀取文件實體以外的任何文件部分。這對
XML 的處理器的使用者而言,可能會有兩個重要的影響:
為了使不同 XML
處理器間的互擁通有最大的可靠性,使用不進行驗證的處理器的應用程式不應依賴於不要求這些處理器具備的動作。那些要求使用如預設值或在外部實體中宣告內部實體等功能的應用程式應該使用進行驗證的XML處理器。
本規格書中 XML 的形式化文法 (formal grammar)
使用一種簡單的擴展巴克斯格式 (Extended Backus-Naur Form,EBNF)給出。文法中的每一條規則定義了一個符號,形式如下:
如果符號用正規運算式 (Regular expression)
定義,則它以大寫字母開頭,否則以小寫字母開頭。字串字面上資料
(literal strings)用引號括起。
在規則右邊的運算式中,以下運算式用於相符一個或多個字元的字串:
#xN
N
是一個十六進位的整數,當ISO/IEC 10646中某個字元的規範(UCS-4)代碼值作為無符號二進位數字與N
相等時,此運算式相符這個字元。#xN
格式中的前導
0 並沒有意義,在相應的代碼值中的前導 0
的個數則由所用字元編碼方式來決定,對 XML 沒有意義。
[a-zA-Z]
, [#xN-#xN]
- 與其值在指定範圍內的任何字元相符 (包含邊界,inclusive)。
[^a-z]
, [^#xN-#xN]
- 與其值在指定範圍之外的任何字元相符。
(譯註:[^a-z] 表示除了 a 到 z 之外的任何字元)
[^abc]
, [^#xN#xN#xN]
- 與任何不在給定字元集內的字元相符。 (譯註:[^abc]
表示除了 abc 之外的任何字元)
"string"
- 與相符雙引號中所給字串的字面上資料字串相符。
'string'
- 與相符單引號中所給字串的字面上資料字串相符。
這些符號可以按下列方式組合,以相符更複雜的模式,其中A
和B
表示簡單運算式:
- (
expression
)
expression
被當成一個單元,可以向本表描述的那樣進行組合。
A?
- 與零個或一個
A
相符,即A
可有可無。 (譯註:A
可出現一次或不出現)
A B
- 與
A
後跟B
的模式相符。 (譯註:出現順序必須先
A 後 B)
A | B
- 與
A
B之一相符,但不同時相符。 (譯註:可出現 A 或 B)
A - B
- 與任何相符
A
但不相符B
的字串相符。 (譯註:只能出現
A 不能出現 B)
A+
- 與一個或多個
A
相符。 (譯註:A
一定要出現,且可出現多次)
A*
- 與零個或多個
A
相符。 (譯註:A 可不出現,也可出現多次)
其他在產生規則式中使用的記法有:
/* ... */
- 註解
[ wfc: ... ]
- 形式合法限制;用名稱標識一個對與某個產生規則式相關聯的形式合法/a>文件的限制。
[ vc: ... ]
- 正確合法性限制;用名稱標識一個對與某個產生規則式相關聯的正確合法文件的限制。
附錄
- IANA
- (Internet Assigned Numbers Authority) Official Names for Character Sets, ed.
Keld Simonsen et al. See ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
- IETF RFC 1766
- IETF (Internet Engineering Task Force). RFC 1766: Tags for the Identification of
Languages, ed. H. Alvestrand. 1995.
- ISO 639
- (International Organization for Standardization). ISO 639:1988 (E). Code for the
representation of names of languages. [Geneva]: International Organization for
Standardization, 1988.
- ISO 3166
- (International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the
representation of names of countries and their subdivisions -- Part 1: Country codes
[Geneva]: International Organization for Standardization, 1997.
- ISO/IEC 10646
- ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E).
Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1:
Architecture and Basic Multilingual Plane. [Geneva]: International Organization for
Standardization, 1993 (plus amendments AM 1 through AM 7).
- Unicode
- The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.:
Addison-Wesley Developers Press, 1996.
- Aho/Ullman
- Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles,
Techniques, and Tools. Reading: Addison-Wesley, 1986, rpt. corr. 1988.
- Berners-Lee et al.
- Berners-Lee, T., R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI):
Generic Syntax and Semantics. 1997. (Work in progress; see updates to RFC1738.)
- Br黦gemann-Klein
- Br黦gemann-Klein, Anne. Regular Expressions into Finite Automata. Extended
abstract in I. Simon, Hrsg., LATIN 1992, S. 97-98. Springer-Verlag, Berlin 1992. Full
Version in Theoretical Computer Science 120: 197-213, 1993.
- Br黦gemann-Klein and Wood
- Br黦gemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages.
Universit鋞 Freiburg, Institut f黵 Informatik, Bericht 38, Oktober 1991.
- Clark
- James Clark. Comparison of SGML and XML. See http://www.w3.org/TR/NOTE-sgml-xml-971215.
- IETF RFC1738
- IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource Locators (URL),
ed. T. Berners-Lee, L. Masinter, M. McCahill. 1994.
- IETF RFC1808
- IETF (Internet Engineering Task Force). RFC 1808: Relative Uniform Resource Locators,
ed. R. Fielding. 1995.
- IETF RFC2141
- IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats.
1997.
- ISO 8879
- ISO (International Organization for Standardization). ISO 8879:1986(E). Information
processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML).
First edition -- 1986-10-15. [Geneva]: International Organization for Standardization,
1986.
- ISO/IEC 10744
- ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E).
Information technology -- Hypermedia/Time-based Structuring Language (HyTime). [Geneva]:
International Organization for Standardization, 1992. Extended Facilities Annexe.
[Geneva]: International Organization for Standardization, 1996.
根據 Unicode 標準中所定義的特性,字元被分類為基礎字元 (其中包括沒有變音符號的拉丁字母),表意字元和組合字元
(其中包括大多數的變音符號);
這些類別結合起來組成了字母類別。數字 (digits) 和擴展符號
(extenders) 也各自被分類。
字元 (Characters) |
[84] |
Letter |
::= |
BaseChar | Ideographic |
[85] |
BaseChar |
::= |
[#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] |
[#x00D8-#x00F6] | [#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] |
[#x014A-#x017E] | [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] |
[#x0250-#x02A8] | [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1] |
[#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE | #x03E0 | [#x03E2-#x03F3] |
[#x0401-#x040C] | [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481] | [#x0490-#x04C4] |
[#x04C7-#x04C8] | [#x04CB-#x04CC] | [#x04D0-#x04EB] | [#x04EE-#x04F5] | [#x04F8-#x04F9] |
[#x0531-#x0556] | #x0559 | [#x0561-#x0586] | [#x05D0-#x05EA] | [#x05F0-#x05F2] |
[#x0621-#x063A] | [#x0641-#x064A] | [#x0671-#x06B7] | [#x06BA-#x06BE] | [#x06C0-#x06CE] |
[#x06D0-#x06D3] | #x06D5 | [#x06E5-#x06E6] | [#x0905-#x0939] | #x093D | [#x0958-#x0961] |
[#x0985-#x098C] | [#x098F-#x0990] | [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2 |
[#x09B6-#x09B9] | [#x09DC-#x09DD] | [#x09DF-#x09E1] | [#x09F0-#x09F1] | [#x0A05-#x0A0A] |
[#x0A0F-#x0A10] | [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33] | [#x0A35-#x0A36] |
[#x0A38-#x0A39] | [#x0A59-#x0A5C] | #x0A5E | [#x0A72-#x0A74] | [#x0A85-#x0A8B] | #x0A8D |
[#x0A8F-#x0A91] | [#x0A93-#x0AA8] | [#x0AAA-#x0AB0] | [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] |
#x0ABD | #x0AE0 | [#x0B05-#x0B0C] | [#x0B0F-#x0B10] | [#x0B13-#x0B28] | [#x0B2A-#x0B30] |
[#x0B32-#x0B33] | [#x0B36-#x0B39] | #x0B3D | [#x0B5C-#x0B5D] | [#x0B5F-#x0B61] |
[#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92-#x0B95] | [#x0B99-#x0B9A] | #x0B9C |
[#x0B9E-#x0B9F] | [#x0BA3-#x0BA4] | [#x0BA8-#x0BAA] | [#x0BAE-#x0BB5] | [#x0BB7-#x0BB9] |
[#x0C05-#x0C0C] | [#x0C0E-#x0C10] | [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39] |
[#x0C60-#x0C61] | [#x0C85-#x0C8C] | [#x0C8E-#x0C90] | [#x0C92-#x0CA8] | [#x0CAA-#x0CB3] |
[#x0CB5-#x0CB9] | #x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C] | [#x0D0E-#x0D10] |
[#x0D12-#x0D28] | [#x0D2A-#x0D39] | [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30 |
[#x0E32-#x0E33] | [#x0E40-#x0E45] | [#x0E81-#x0E82] | #x0E84 | [#x0E87-#x0E88] | #x0E8A |
#x0E8D | [#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3] | #x0EA5 | #x0EA7 |
[#x0EAA-#x0EAB] | [#x0EAD-#x0EAE] | #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD | [#x0EC0-#x0EC4] |
[#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5] | [#x10D0-#x10F6] | #x1100 |
[#x1102-#x1103] | [#x1105-#x1107] | #x1109 | [#x110B-#x110C] | [#x110E-#x1112] | #x113C |
#x113E | #x1140 | #x114C | #x114E | #x1150 | [#x1154-#x1155] | #x1159 | [#x115F-#x1161] |
#x1163 | #x1165 | #x1167 | #x1169 | [#x116D-#x116E] | [#x1172-#x1173] | #x1175 | #x119E |
#x11A8 | #x11AB | [#x11AE-#x11AF] | [#x11B7-#x11B8] | #x11BA | [#x11BC-#x11C2] | #x11EB |
#x11F0 | #x11F9 | [#x1E00-#x1E9B] | [#x1EA0-#x1EF9] | [#x1F00-#x1F15] | [#x1F18-#x1F1D] |
[#x1F20-#x1F45] | [#x1F48-#x1F4D] | [#x1F50-#x1F57] | #x1F59 | #x1F5B | #x1F5D |
[#x1F5F-#x1F7D] | [#x1F80-#x1FB4] | [#x1FB6-#x1FBC] | #x1FBE | [#x1FC2-#x1FC4] |
[#x1FC6-#x1FCC] | [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC] | [#x1FF2-#x1FF4] |
[#x1FF6-#x1FFC] | #x2126 | [#x212A-#x212B] | #x212E | [#x2180-#x2182] | [#x3041-#x3094] |
[#x30A1-#x30FA] | [#x3105-#x312C] | [#xAC00-#xD7A3] |
[86] |
Ideographic |
::= |
[#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029] |
[87] |
CombiningChar |
::= |
[#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486] |
[#x0591-#x05A1] | [#x05A3-#x05B9] | [#x05BB-#x05BD] | #x05BF | [#x05C1-#x05C2] | #x05C4 |
[#x064B-#x0652] | #x0670 | [#x06D6-#x06DC] | [#x06DD-#x06DF] | [#x06E0-#x06E4] |
[#x06E7-#x06E8] | [#x06EA-#x06ED] | [#x0901-#x0903] | #x093C | [#x093E-#x094C] | #x094D |
[#x0951-#x0954] | [#x0962-#x0963] | [#x0981-#x0983] | #x09BC | #x09BE | #x09BF |
[#x09C0-#x09C4] | [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7 | [#x09E2-#x09E3] | #x0A02 |
#x0A3C | #x0A3E | #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48] | [#x0A4B-#x0A4D] |
[#x0A70-#x0A71] | [#x0A81-#x0A83] | #x0ABC | [#x0ABE-#x0AC5] | [#x0AC7-#x0AC9] |
[#x0ACB-#x0ACD] | [#x0B01-#x0B03] | #x0B3C | [#x0B3E-#x0B43] | [#x0B47-#x0B48] |
[#x0B4B-#x0B4D] | [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2] | [#x0BC6-#x0BC8] |
[#x0BCA-#x0BCD] | #x0BD7 | [#x0C01-#x0C03] | [#x0C3E-#x0C44] | [#x0C46-#x0C48] |
[#x0C4A-#x0C4D] | [#x0C55-#x0C56] | [#x0C82-#x0C83] | [#x0CBE-#x0CC4] | [#x0CC6-#x0CC8] |
[#x0CCA-#x0CCD] | [#x0CD5-#x0CD6] | [#x0D02-#x0D03] | [#x0D3E-#x0D43] | [#x0D46-#x0D48] |
[#x0D4A-#x0D4D] | #x0D57 | #x0E31 | [#x0E34-#x0E3A] | [#x0E47-#x0E4E] | #x0EB1 |
[#x0EB4-#x0EB9] | [#x0EBB-#x0EBC] | [#x0EC8-#x0ECD] | [#x0F18-#x0F19] | #x0F35 | #x0F37 |
#x0F39 | #x0F3E | #x0F3F | [#x0F71-#x0F84] | [#x0F86-#x0F8B] | [#x0F90-#x0F95] | #x0F97 |
[#x0F99-#x0FAD] | [#x0FB1-#x0FB7] | #x0FB9 | [#x20D0-#x20DC] | #x20E1 | [#x302A-#x302F] |
#x3099 | #x309A |
[88] |
Digit |
::= |
[#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9] |
[#x0966-#x096F] | [#x09E6-#x09EF] | [#x0A66-#x0A6F] | [#x0AE6-#x0AEF] | [#x0B66-#x0B6F] |
[#x0BE7-#x0BEF] | [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] | [#x0D66-#x0D6F] | [#x0E50-#x0E59] |
[#x0ED0-#x0ED9] | [#x0F20-#x0F29] |
[89] |
Extender |
::= |
#x00B7 | #x02D0 | #x02D1 | #x0387 | #x0640 | #x0E46 | #x0EC6 |
#x3005 | [#x3031-#x3035] | [#x309D-#x309E] | [#x30FC-#x30FE] |
|
在此處定義的字元類別可從 Unicode 字元資料庫中得到,如下所示:
- 名稱的起始字元必須屬於 Ll,Lu,Lo,Lt,Nl 中的一類。
- 除了起始字元之外的名稱字元必須屬於 Mc,Me,Mn,Lm 或 Nd
中的一類。
- 在相容區 (即字元代碼大於 #xF900 及小於 #xFFFE 的字元)
中的字元不允許在 XML 名稱中出現。
- 不允許出現具有字型或相容分解 (即字元資料庫的第 5 欄有"compatibility
formatting tag"的字元 -- "<" 標示著第 5 欄的開始)
的字元。
- 下列字元被當成名稱起始字元而非只是名稱字元,因為特性文件中將它們歸類於字母類別
(Alphabetic) : [#x02BB-#x02C1],#x0559,#x06E5,#x06E6。
- 不允許出現字元 #x20DD-#x20E0 (與 Unicode 的 5.14 節保持一致)。
- 字元 #x00B7
被分類成為一個擴展符號,因為特性文件中是如此來辨識它的。
- 字元 #x0387 被加入成為一個名稱字元,因為 #x00B7
是相當於它的規範形式。
- 字元 ':' 和 '_' 允許做為名稱起始字元。
- 字元 '-' 和 '.' 允許做為名稱字元。
XML被設計成 SGML 的一個子集,每一個正確合法的
(valid) XML 文件也應該是一個符合規格的 SGML 文件。對於 SGML 來說 XML文件額外限制的詳細比較請參考[Clark]。
本附錄中包含許多實例來說明了在 "4.4 XML
處理器對於實體和引用的處理"一節中規定的實體- 和字元-參引的辨識和展開的次序。
如果 DTD 中包含宣告
<!ENTITY example "<p>An ampersand (&#38;) may be escaped
numerically (&#38;#38;) or with a general entity
(&amp;).</p>" >
|
XML
處理器會在剖析實體宣告時辨識出字元參引,並在將下列字串儲存成實體"example
"的值之前,解析這些字元參引:
<p>An ampersand (&) may be escaped
numerically (&#38;) or with a general entity
(&amp;).</p>
|
在文件中對於"&example;
"的引用會導致文件重新被剖析,此時"p
"
元素的起始和結束標籤會被識別,三個引用會被識別和展開,結果會變成包含下面內容
(所有資料,無定界符或標示) 的 "p
"元素:
An ampersand (&) may be escaped
numerically (&) or with a general entity
(&).
|
一個更複雜的例子會完整地展示這些規則和它們的效果。在下面的例子中,行號只是為了說明參考方便。
1 <?xml version='1.0'?>
2 <!DOCTYPE test [
3 <!ELEMENT test (#PCDATA) >
4 <!ENTITY % xx '%zz;'>
5 <!ENTITY % zz '<!ENTITY tricky "error-prone" >' >
6 %xx;
7 ]>
8 <test>This sample shows a &tricky; method.</test>
|
此例子會產生下列動作:
- 在第 4 行,對字元 37 的引用會被立即展開,參數實體"
xx
"使用值"%zz;
"來儲存於符號表中。因為置換文字不會再次被掃描,對參數實體"zz
"的引用不會被識別。(而且如果它被識別的話則會是一個錯誤,因為"zz
"還沒有被宣告。)
- 在第 5 行,字元參引"
<
"會被立即展開,而參數實體"zz
"使用置換文字"<!ENTITY
tricky "error-prone" >
"被儲存,此置換文字是一個形式合法的實體宣告。
- 在第 6 行,"
xx
"的引用會被識別,"xx
"的置換文字(即"%zz;
")會被剖析。隨後對於"zz
"的引用會被識別,它的置換文字("<!ENTITY
tricky "error-prone" >
")會被剖析。此時通用實體"tricky
"會被宣告,其置換文字為"error-prone
"。
- 在第8行,對通用實體"
tricky
"的引用會被識別並展開,因此"test
"元素的完整內容為一個自我描述
(self-describing) 及不合文法的字串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,可以從內容模型建構一個有限狀態自動機
(finite state automation)。在很多這樣的演算法中,在規則運算式 (regular
expression) 中的每一個位置 (即規則運算式的語法樹中的每個葉子節點),會建構一個隨集
(follow set);如果任何一個位置的隨集中不止一個隨後位置被標為同一元素類型時,則此內容模型會發生錯誤,並且會報告錯誤。
存在將許多但不是所有非決定型內容模型自動地簡化成等價的決定型模型演算法;請參考
Bruggemann-Klein 1991 [Bruggemann-Klein].
XML
編碼宣告功能在每個實體中當成一個內部的標籤,用於指出使用了何種字元編碼。然而,在
XML
處理器能讀取這個內部標籤前,顯然它必須知道目前使用的是哪種字元編碼-而這正是此內部標籤要試著表示出來的。在一般的情況下,此為毫無助益的情況。不過在
XML 中並非完全沒有助益,這是因為 XML
在兩個方面上限制了一般的情況:每種實作假設只支援一個有限的字元編碼集,並且為了讓正常情況下可以自動檢測每個實體中所用字元編碼,限制了
XML 編碼宣告的位置和內容。很多情況下除了 XML 資料流 (data stream)
本身之外,另外還有其他可用的資訊來源。端視於 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 (在某些種類中,完整的編碼宣告必須能用於區別使用了哪一編碼表)
- 其他:無編碼宣告的 UTF-8,或是資料流已損壞,不完整或被包含在某種外層資料中。
此種程度的自動檢測足夠於讀取 XML
編碼宣告和剖析字元編碼識別字。字元編碼識別字仍是必須用於區分每個編碼集合中的個別成員
(例如從 8859 中區分出 UTF-8,8859
各個部分間的相互區分,以及區分所用的特定 EBCDIC 內碼表,等等)。
因為編碼宣告的內容受限於 ASCII
字元,一旦處理器檢測到使用的是哪個編碼集合,它能夠可靠地讀取整個編碼宣告。因為實際中,所有廣泛使用的字元編碼都可以歸納在上述的分類中,XML
編碼宣告合理地允許可靠的內嵌標籤 (in-band labeling)
的字元編碼,即使是在作業系統或傳輸協定層級的外部資訊來源並不可靠的時候。
一旦處理器檢測到所使用的字元編碼,則它就會作出合適的動作,不論是針對每種情況呼叫
(invorking)
單獨的輸入常式,或是對每個輸入的字元呼叫適合的轉換函數。
就像任何自我標註 (self-labeling)
的系統一樣,若任何軟體改變實體字元集或其編碼而沒有跟著修改編碼宣告的話,XML
編碼宣告將無法正常運作。字元編碼常式的實作人員必須小心地確保標註實體所使用的內部和外部資訊的精確性。
第二個可能的情況在於 XML
實體伴隨的編碼資訊,如同在一些檔案系統及網路協定。當多個資訊來源都可使用時,相對之間的優先順序和偏好的處理衝突方法應該在傳輸
XML
時所使用的高階協定中指定。例如,內部標籤的相對優先順序規則和在外部標頭中的
MIME 類型標籤應該是定義 text/xml 和 application/xml MIME 類型的 RFC
文檔的一部分。然而基於互通性考量,建議使用下列規則。
- 如果 XML 實體是在一個檔案中,用位元組順序標示和編碼宣告 PI (如果有的話)
來確定字元編碼。所有其他推斷和資訊來源都只是用於錯誤修復。
- 如果 XML 實體使用 text/xml MIME 類型來傳遞時,則 MIME 類型的
charset
參數決定了字元編碼方法;所有其他推斷和資訊來源都只是用於錯誤修復。
- 如果 XML 實體使用 application/xml MIME
類型來傳遞時,則用位元組順序標示和編碼宣告 PI (如果有的話)來確定字元編碼。所有其他推斷和資訊來源都只是用於錯誤修復。
這些規則只適用於缺少協定層級文件時的情況;特別是當相關 RFC
中定義了這些 text/xml 和application/xml MIME 類型時,RFC
中的建議書會取代這些規則。
本規格書由 W3C XML工作組 (WG)
完成並批准發表。工作組批准本規格書並非意指所有工作組成員都一致贊同本規範
(譯註:表示本規格書是獲得大多數的 XML
工作組成員同意,少數成員仍有不同意見)。現有和以前的 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