Los Angeles Chinese Learning Center, providing private Chinese Mandarin classes, Chinese tutors, Mandarin interpreter and translators, China investment report, investment opportunity report, China intelligence report, information on Chinese herbal medicines in Los Angeles
Corporate Services Other Services
Private Instruction Invest in China
Curriculum FAQ
Business Culture Health Education
Textbooks Our Staff
Hours and Location Contact Us
 

W3C 可擴展標記語言(XML)1.0(第二版)

W3C 建議 2000年10月6日

Extensible Markup Language (XML) 1.0 (Second Edition)

本文檔是 W3C 建議 XML 1.0 第二版(2000 年 10 月 6 日)的簡体中文翻譯版,其中可能有錯誤和不妥之處。

英文版是唯一的正式版,位于:

http://www.w3.org/TR/2000/REC-xml-20001006

本文檔經譯者同意放于此處,深表謝意。本文檔還可見于譯者网站:

http://chinese-school.netfirms.com/XML10-TC.html

譯者:
  • 裘強(qqiu@yeah.net
  • Traditional Chinese Code Conversion: Samuel Chong

著作權聲明位于:http://www.w3.org/Consortium/Legal/copyright-documents.html

Copyright  © 1998 W3C® (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

 

本版本:
http://www.w3.org/TR/2000/REC-xml-20001006XHTML 格式XML 格式PDF 格式,用不同顏色標示增刪改的 XHTML 審閱版
最新版本:
http://www.w3.org/TR/REC-xml
以前版本:
http://www.w3.org/TR/2000/WD-xml-2e-20000814
http://www.w3.org/TR/PR-xml-971208
編者:
Tim Bray,Textuality and Netscape mailto:tbray@textuality.com
Jean Paoli,Microsoft mailto:jeanpa@microsoft.com
C. M. Sperberg-McQueen,University of Illinois at Chicago and Text Encoding Initiative mailto:cmsmcq@uic.edu
Eve Maler, Sun Microsystems, Inc. mailto:elm@east.sun.com - 第二版

摘要

本文檔完整地描述了可擴展標記語言(Extensible Markup Language,XML),它是標准通用標記語言(Standard Generic Markup Language,SGML)的一個子集。其目的在于使得在 Web 上能以現有超文本標記語言(Hypertext Markup Language,HTML)的使用方式提供,接收和處理通用的 SGML 成為可能。XML 的設計既考慮了實現的方便性,同時也顧及了与 SGML 和 HTML 的互操作性。

本文檔的狀態

本文檔已由 W3C 組織成員和其他相關各方審閱,并已被組織理事批准為 W3C 建議。這是一份穩定的文檔,可以用作參考材料,也可以作為其他文檔的正式參考文獻。W3C 在建議制定過程中的作用是吸引對本建議的注意并促進它的廣泛使用。這能增強Web的功能和互操作性。

本文檔規定了一种用于 World Wide Web 的語法,此語法是通過取一個業已存在并已廣泛使用的文本處理國際標准(標准通用標記語言,經增補和更正的 ISO 8879:1986(E))的子集而創建的。它是 W3C XML 行動組(XML Activity)的工作成果,關于 XML 行動組的詳細信息可以在 http://www.w3.org/XML 找到。英文版是唯一的正式版。本文檔的翻譯見 http://www.w3.org/XML/#trans。在 http://www.w3.org/TR 可以找到現有 W3C 建議和其他技術文檔的一個列表。

XML 1.0 第二版不是 XML 的一個新版本(1998 年 2 月 10 日首次發表);它只是為了方便讀者,并入了第一版勘誤表中指出的錯誤和修改(在 http://www.w3.org/XML/xml-19980210-errata)。 本第二版的勘誤表在 http://www.w3.org/XML/xml-V10-2e-errata

請將本文檔中的錯誤報告給 xml-editor@w3.org。可以在此找到相關的存檔。

注:

C. M. Sperberg-McQueen 在第一版發表之后供職之處已有變化。他現在供職于 W3C,可以通過 cmsmcq@w3.org 和他聯系。

目錄

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 不被識別
        4.4.2 被包含
        4.4.3 進行驗証時被包含
        4.4.4 被禁止
        4.4.5 作為常量被包含
        4.4.6 通知
        4.4.7 不處理
        4.4.8 作為參數實体被包含
    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. 字符編碼的自動檢測(非正式)
    F.1 無外部編碼信息時的檢測
    F.2 有外部編碼信息時的优先級
G. W3C XML 工作組(非正式)
H. W3C XML 核心工作組(非正式)
I. 文檔制作說明(非正式)


1. 緒論

可擴展標記語言,縮寫為 XML,描述了一類稱為 XML 文件的數据對象,同時也部分地描述了處理這些數据對象的計算机程序的動作。XML 是 SGML(標准通用標記語言 [ISO 8879])針對特定應用領域的一個子集,或者說是 SGML 的一种受限形式。根据定義,XML 文件是合乎規范的 SGML 文件。

XML 文件由稱為實体的存儲單元組成,實体可以包含已析(parsed)數据或未析(unparsed)數据。已析數据由字符組成,其中一些字符組成字符數据,另一些字符組成標記。標記中包含了對文件存儲格式(storage layout)和邏輯結构的描述。XML 提供了一种机制用于約束存儲格式和邏輯結构。

[定義:稱為 XML 處理器的軟件模塊用于讀取 XML 文件,存取其中的內容和結构。] [定義:XML 處理器被設想為是為另一個稱為應用的模塊作處理。] 本規范從 XML 處理器應如何讀取 XML 數据以及應向應用提供哪些信息的這兩個方面,描述了要求 XML 處理器作出的動作。

1.1 開發者和開發目標

XML 由 XML 工作組(原先的 SGML 編輯審查委員會)開發,此工作組由 World Wide Web Consortium (W3C) 在 1996 年主持成立。工作組由 Sun Microsystems 的 Jon Bosak 負責,同樣由 W3C 組織的 XML SIG (Special Interest Group)(原先的 SGML 工作組)積极參与了 XML 工作組的工作。XML 工作組的成員在附錄中給出。工作組与 W3C 的聯系人是 Dan Connolly。

XML 的設計目標如下:

  1. XML 應該可以直接在因特网(Internet)上使用。
  2. XML 應該支持大量不同的應用。
  3. XML 應該与 SGML 兼容。
  4. 處理 XML 文件的程序應該容易編寫。
  5. XML 中的可選項應無條件地保持最少,理想狀況下應該為 0 個。
  6. XML 文件應該能夠讓人直接閱讀,而且應該有足夠的可讀性。
  7. XML 的設計應快速完成。
  8. XML 的設計應該是形式化的,簡洁的。
  9. XML 文件應易于創建。
  10. XML 標記的簡洁性是最不重要的設計目標。

本規范与其他相關的標准一起(Unicode 和 ISO/IEC 10646 定義了字符集,Internet RFC1766 定義了語言識別碼,ISO 639 定義了語言名稱代碼,ISO 3166 定義了國家名稱代碼),提供了理解 XML 版本 1.0 和构建相應計算机處理程序所需的所有信息。

在完整保留所有文本和法律注意事項的前提下,本版本的 XML 規范可以自由分發。

1.2 術語

用于描述 XML 文件的術語在此規范的正文中定義。在這些定義中以及描述一個 XML 處理器的動作時,使用了下表中的術語:

可以(may)
[定義:允許合乎規范的文件和 XML 處理器按所描述的方式工作,但不要求必須如此。]
必須(must)
[定義:要求合乎規范的文件和 XML 處理器按所描述的方式工作; 否則它們出現錯誤。]
錯誤(error)
[定義:對本規范中的規則的違反;其結果不确定。合乎規范的軟件可以檢測和報告錯誤,并可以從中恢复。]
嚴重錯誤(fatal error)
[定義:合乎規范的 XML 處理器必須檢測到,并向應用報告的一類錯誤。在遇到嚴重錯誤之后,處理器可以繼續處理數据以發現更多的錯誤并可以向應用報告這些錯誤。為了支持錯誤的更正,處理器可以向應用提供文件中未經處理的數据(字符數据和標記的混合体)。但是,一旦檢測到一個嚴重錯誤,處理器必須停止正常的處理(也就是說,它必須停止以正常的方式向應用提供与文件邏輯結构有關的數据和信息)。]
由使用者選擇(at user option)
[定義:合乎規范的軟件可以或者必須(取決于句子中的情態動詞)按所描述的方式工作; 如果它滿足這個條件,它必須同時提供使用者一种手段,使得使用者能夠啟用和禁用所描述的工作方式。]
有效性約束(validity constraint)
[定義:适用于所有有效的 XML 文件的一种規則。違反有效性約束屬于錯誤;進行驗証的 XML 處理器必須,由使用者選擇,報告這些錯誤。]
格式正确性約束(well-formedness constraint)
[定義:适用于所有格式正确的 XML 文件的一种規則。違反格式正确性約束屬于嚴重錯誤。]
匹配(match)
[定義:(對于字符串和名字:)被比較的兩個字符串或名字必須完全相同。在 ISO/IEC 10646 中有多种可能表示方式的字符(例如,既有預定義 (precomposed) 形式和基字符 (base) + 變音符形式的字符)只在兩個字符串中的表示方式相同時才匹配。不進行字符的大小寫轉換。(對于文法中的字符串和規則:)如果一個字符串屬于一個文法產生式產生的語言,則它匹配這個產生式。(對于內容和內容模型:)當一個元素符合 "元素有效性"約束中的描述時,它匹配其聲明。]
出于兼容性考慮(for compatibility)
[定義:指出此句描述的 XML 特性完全只是為了和 SGML 保持兼容 。]
出于互操作性考慮(for interoperability)
[定義:指出此句是一個不具約束性的建議,目的是增加 XML 文件能被在 ISO 8879 的 WebSGML 改編附件之前已有的 SGML 處理器處理的可能性。]

2. 文件

[定義:如果一個數据對象滿足本規范中格式正确的之定義時,它是一個 XML 文件。一個格式正确的 XML 文件可以更進一步是有效的,如果它滿足某些進一步的約束的話。]

每一個 XML 文件都有邏輯和物理結构。物理上而言,文件由稱為實体的單元組成。一個實体可以引用(refer)其他實体,將它們包含在文件中。文件開始于"根(root)"或文件實体。邏輯上而言,文件由聲明,元素,注釋,字符引用和處理指令組成,所有這些都在文件中用顯式標記指明。邏輯和物理結构必須如"4.3.2 格式正确的已析實体"中所描述的那樣嚴格地嵌套。

2.1 格式正确的 XML 文件(Well-Formed XML Documents)

[定義:一個文本對象是一個格式正确的 XML 文件如果它滿足:]

  1. 作為一個整体,它匹配 document 產生式。
  2. 它滿足本規范中定義的所有格式正确性約束。
  3. 此文件中直接或間接引用的每一個已析實体都是格式正确的
文件
[1]    document    ::=    prolog element Misc*

匹配 document 產生式意味著:

  1. 它包含一個或多個元素
  2. [定義:有且僅有一個稱為根(root)或文件元素的元素,它不出現在其他任何元素的內容(content)中。] 對于其他所有元素,如果起始標簽在另一個元素的內容中,則其結束標簽也在同一元素的內容中。換一個更簡單的說法,以起始標簽和結束標簽為界的各個元素,必須嚴格地嵌套。

[定義:這樣做的結果是,對于每一個非根的元素 C,文件中另有一個元素 PCP 的內容中,而不在其他任何被 P 所包含的元素的內容中。P 被稱為 C父元素(parent),而 C 被稱為 P子元素(child)。]

2.2 字符

[定義:一個已析實体包含文本(text),文本是一個字符(character)序列,可以表示標記或字符數据。] [定義:一個字符是 ISO/IEC 10646 [ISO/IEC 10646](或 [ISO/IEC 10646-2000])中定義的文本最小單元。合法的字符包括制表符,回車,換行以及 Unicode 和 ISO/IEC 10646 中定義的合法字符。在制定本文檔時,在附錄 A.1 正式參考文獻中引用的標准都是當時的最新版本,在這些標准的增補版或新版中可能會加入新的字符。因此,XML 處理器必須能接受產生式 Char 中所定義范圍內的任意字符。不提倡使用 [Unicode] 6.8 節(或 [Unicode3] 3.6 節 D21 )中定義的"兼容字符(compatibility characters)"。]

字符范圍
[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 實体中的字符編碼"中討論。

2.3 通用語法成分

本節中定義了一些在文法中廣泛使用的符號。

S(空白)包括一個或多個空格字符(#x20),回車,換行和制表符。

空白
[3]    S    ::=    (#x20 | #x9 | #xD | #xA)+

為方便起見,字符被分為字母,數字和其他字符三類。字母可以是字母表中的字母,或是一個音節基字符(syllabic base character),也可以是一個表意字符。在"B. 字符的分類"中給出了每一類字符的完整定義。

[定義:名字(name)是以字母或某些標點符號開頭的記號,后跟字母,數字,連字符,下划線,冒號或句號,這些符號統稱為命名字符(name character)。] 以 "xml" 或其他任何匹配 (('X'|'x') ('M'|'m') ('L'|'l')) 的字符串開頭的名字,被保留用于本規范的此版本或后續版本的標准化。

注:

XML 建議中的名域 [XML Names] 賦予了包含冒號的名字某种含義。因此除非用于名域,XML 文件作者不應該在 XML 名字中使用冒號,但 XML 處理器應該接受冒號作為一個命名字符。

Nmtoken(名字記號,name token)是任何命名字符的混合体。

名字和記號
[4]    NameChar    ::=    Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5]    Name    ::=    (Letter | '_' | ':') (NameChar)*
[6]    Names    ::=    Name (S Name)*
[7]    Nmtoken    ::=    (NameChar)+
[8]    Nmtokens    ::=    Nmtoken (S Nmtoken)*

常量數据是任何用引號括起的字符串,不包括用作定界符的引號。常量用于指明內部實体的內容(EntityValue),屬性值(AttValue),以及外部標識符(SystemLiteral)。注意,對 SystemLiteral 的語法分析可以不掃描標記。

常量
[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] | [-'()+,./:=?;!*#@$_%]

注:

雖然產生式 EntityValue 允許定義只包含單個 < 的實体(如,<!ENTITY mylt "<">),但是強烈建議避免這种用法,因為對此實体的任何引用都會引起一個格式正确性錯誤。

2.4 字符數据和標記

文本字符數据和標記混合构成。[定義:標記包括起始標簽結束標簽空元素標簽實体引用字符引用注釋CDATA 段定界符,文件類型聲明處理指令XML 聲明文本聲明,以及任何在文件實体頂層的空白(即,在文件元素之外且不在任何其他的標記中)。]

[定義:其他所有非標記的文本組成文件的字符數据。]

"and"號(&)和左尖括號(<)只有作為標記定界符,或在注釋處理指令,或 CDATA 段中時才能以常量形式出現。如果在其他地方需要用到這兩個字符,它們必須用數值式字符引用轉義或分別用字符串"&amp;"和"&lt;"表示。右尖括號(>)可以用"&gt;"表示,而當它在內容中的字符串"]]>"中出現,但此字符串不表示一個 CDATA 段的結束時,出于兼容性考慮,必須用"&gt;"或一個字符引用轉義得到。

在一個元素的內容中,字符數据可以是不包括任何標記的起始定界符的任意字符串。在一個 CDATA 段中,字符數据可以是不包括 CDATA 段結束定界符"]]>"的任意字符串。

為了允許在屬性值中包含單引號和雙引號,省略符或稱單引號(')可以被表示為"&apos;",而雙引號(")可以被表示為"&quot;"。

字符數据
[14]    CharData    ::=    [^<&]* - ([^<&]* ']]>' [^<&]*)

2.5 注釋

[定義:注釋可以在其他標記之外的文件中的任何位置出現。另外,它們可以在文件類型聲明中文法允許的地方出現。它們不是文件字符數据的一部分,XML 處理器可以,但不是必須,允許一個應用檢索注釋的文本。出于兼容性考慮,字符串"--"(雙連字符)不能在注釋中出現。] 注釋中的參數實体不被識別。

注釋
[15]    Comment    ::=    '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'

注釋的一個例子:

<!-- declarations for <head> & <body> -->

注意,此文法不允許注釋以 ---> 結尾。下面的例子不是格式正确的。

<!-- B+, B, or B--->

2.6 處理指令

[定義:處理指令(PI)允許文件中包含由應用來處理的指令。]

處理指令
[16]    PI    ::=    '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17]    PITarget    ::=    Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

PI 不是文件字符數据的一部分,但必須傳遞給應用。PI 以用于指示傳遞給哪個應用的目標(PITarget)開頭。目標名字 "XML","xml",等等,保留用于本規范的此版本或后續版本的標准化。XML 記法机制可以用于 PI 目標的形式化聲明。參數實体在處理指令中不被識別。

2.7 CDATA 段

[定義:CDATA 段可以出現在字符數据可以出現的任何地方,它們用于轉義包含會被識別為標記的字符串的文本塊。CDATA 段以字符串 "<![CDATA[" 開始,以字符串 "]]>" 結束:]

CDATA 段
[18]    CDSect    ::=    CDStart CData CDEnd
[19]    CDStart    ::=    '<![CDATA['
[20]    CData    ::=    (Char* - (Char* ']]>' Char*))
[21]    CDEnd    ::=    ']]>'

在一個 CDATA 段內,只有 CDEnd 字符串被識別為標記,因此左尖括號和"&"可以以它們的常量形式出現,不需要(也不能)被換碼為"&lt;"和"&amp;"。CDATA 段不能嵌套。

一個 CDATA 段的例子,其中"<greeting>"和"</greeting>"被識別為字符數据,而不是標記

<![CDATA[<greeting>Hello, world!</greeting>]]>

2.8 序言(prolog)和文件類型聲明

[定義:XML 文件應該以一個 XML 聲明開始,其中指明了所用 XML 的版本。] 例如,以下是一個完整的 XML 文件,它是格式正确的,但不是有效的

<?xml version="1.0"?>
<greeting>Hello, world!</greeting>

下面這個也同樣:

<greeting>Hello, world!</greeting>

版本號 "1.0" 應該用于表明与本規范的本版本相一致,如果使用了值 "1.0" 但又与本規范的本版本不一致,那么這是文件的一個錯誤。XML 工作組打算賦予本規范的后續版本不同于 "1.0" 的數值,但這并不代表開發后續版本的承諾,也不代表如果有后續版本,會使用任何特殊的命名方案的承諾。因為不排除有后續版本的可能性,提供了本构造(construct)作為一旦需要時進行自動版本識別的手段。當處理器收到的文件標有它們不支持的版本時,可以給出一個錯誤。

XML 文件中標記的功能是描述文件的存儲格式和邏輯結构,并將屬性-值對和邏輯結构關聯起來。XML 提供一种稱為文件類型聲明的机制,用于定義對邏輯結构的約束,支持預定義存儲單元的使用。[定義:如果一個 XML 文件有相應的文件類型聲明并且它遵循其中的約束,則稱它是有效的(valid)。]

文件類型聲明必須位于文件第一個元素之前。

序言
[22]    prolog    ::=    XMLDecl? Misc* (doctypedecl Misc*)?
[23]    XMLDecl    ::=    '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'
[24]    VersionInfo    ::=    S 'version' Eq ("'" VersionNum "'" | '"' VersionNum '"')/* */
[25]    Eq    ::=    S? '=' S?
[26]    VersionNum    ::=    ([a-zA-Z0-9_.:] | '-')+
[27]    Misc    ::=    Comment | PI | S

[定義:XML 文件類型聲明包含或指向標記聲明,標記聲明提供某一類文件的文法。這种文法被稱為文件類型定義(document type difinition,DTD)。文件類型定義可以指向一個外部子集(一种特殊類型的外部實体),或者可以在一個內部子集中直接包含標記聲明,或者兩者兼用。一個文件的文件類型定義由這兩個子集合在一起組成。]

[定義:標記聲明可以是元素類型聲明屬性表聲明實体聲明,或是記法聲明。] 這些聲明可以如下面格式正确性和有效性約束中所述,全部或部分地包含在參數實体中,"4. 物理結构"中有更多的信息。

文件類型定義
[28]    doctypedecl    ::=    '<!DOCTYPE' S Name (S ExternalID)? S? ('[' (markupdecl | DeclSep)* ']' S?)? '>' [VC: 根元素類型]
[WFC: 外部子集]
/* */
[28a]    DeclSep    ::=    PEReference | S [WFC: 聲明間的參數實体]
/* */
[29]    markupdecl    ::=    elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | Comment [VC: 嚴格的聲明/參數實体嵌套]
[WFC: 內部子集中的參數實体]

注意,要构建包含了一個既不指向外部子集也不包含內部子集的 doctypedecl 而格式正确的文件是可能的。

標記聲明可以全部或部分地由參數實体置換文本組成。本規范后面的各個非終結符(elementdeclAttlistDecl,等等)產生式描述的是在所有的參數實体被包含(include)之后的聲明。

除了在常量,處理指令,注釋和被忽略的條件段的內容中出現的參數實体引用以外,DTD 中的其他任何地方(內部或外部子集以及外部參數實体)的參數實体引用都被識別(見 3.4 條件段)。在實体值常量中的參數實体引用也被識別。內部子集中參數實体引用的使用限制如下所述。

有效性約束: 根元素類型(Root Element Type)
文件類型聲明中的 Name 必須匹配根元素的類型。

有效性約束: 嚴格的聲明/參數實体嵌套
參數實体的置換文本必須用標記聲明嚴格嵌套。即,如果一個標記聲明(上面的 markupdecl)的第一個或最后一個字符被包含于一個參數實体引用的置換文本中,兩者必須都在此置換文本中。

格式正确性約束: 內部子集中的參數實体

在內部 DTD 子集中,參數實体引用只能出現在標記聲明可以出現的地方,而不能在標記聲明內部出現。(這個約束不适用于出現在外部參數實体內的引用,也不适用于外部子集。)

格式正确性約束: 外部子集

外部子集(如果有的話)必須匹配產生式 extSubset

格式正确性約束: 聲明間的參數實体

一個 DeclSep 內的參數實体引用的置換文本必須匹配產生式 extSubsetDecl

同內部子集一樣,外部子集和任何 DeclSep 中引用的外部參數實体,必須由一系列被非終結符 markupdecl 所允許的完整的標記聲明組成,其中可以夾雜空白字符或參數實体引用。但是,外部子集和外部參數實体的部分內容可以通過使用條件段(conditional section)被有條件地忽略,在內部子集中則不允許這么做。

外部子集
[30]    extSubset    ::=    TextDecl? extSubsetDecl
[31]    extSubsetDecl    ::=    ( markupdecl | conditionalSect | DeclSep)* /* */

外部子集和外部參數實体与內部實体不同之處還在于:在它們內,參數實体引用不僅可以出現在標記聲明,還可以出現在標記聲明

有文件類型聲明的 XML 文件的例子:

<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>Hello, world!</greeting>

系統標識符 "hello.dtd" 給出了此文件的 DTD 的地址(一個 URI 引用)。

聲明也可以如同下面這個例子一樣直接(locally)給出:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE greeting [
  <!ELEMENT greeting (#PCDATA)>
]>
<greeting>Hello, world!</greeting>

如果同時使用外部和內部子集,子集子集被看成出現在外部子集之前,這意味著內部子集中的實体和屬性表聲明的优先級要比在外部子集中的高。

2.9 獨立文件聲明

當文件從 XML 處理器遞給應用時,標記聲明可以影響它的內容,屬性缺省值和實体聲明是其中的例子。可以作為 XML 聲明一個成分的獨立文件聲明,指明了是否存在著在文件實体外或在參數實体中的聲明。[定義:外部標記聲明被定義為出現在外部子集或參數實体(外部或內部,包括內部參數實体是因為并不強制不進行驗証的處理器讀取其中的標記聲明)中的標記聲明。]

獨立文件聲明
[32]    SDDecl    ::=    S 'standalone' Eq (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"')) [VC: 獨立文件聲明]

在一個獨立文件聲明中,值 "yes" 表示對于文件實体沒有外部標記聲明(不論是在 DTD 外部子集中,還是在由內部實体引用的外部參數實体中)會影響從 XML 處理器傳遞給應用的信息。值 "no" 表示有或可能有這樣的外部標記聲明。注意,獨立文件聲明只是表示外部聲明的存在,如果文件中存在對外部實体的引用,而這些實体已在內部聲明時,不影響它的獨立狀態。

如果不存在外部標記聲明,獨立文件聲明沒有意義。如果存在外部標記聲明,但沒有獨立文件聲明,就假定取值 "no"。

某些网絡傳輸應用也許需要獨立的文件,任何滿足 standalone="no" 的 XML 文件可以通過一定的算法轉換為獨立文件。

有效性約束: 獨立文件聲明
獨立文件聲明必須取值為 "no",如果任何外部標記聲明中包含:

  • 缺省值的屬性的聲明,如果适用這些屬性的元素出現在文件中而又沒有給這些屬性賦值的話。
  • (除了 ampltgtaposquot 外的)實体的聲明,而對這些實体的引用出現在文件中的話。
  • 其值需要規范化的屬性的聲明,如果這些出現在文件中的屬性的值會因規范化而改變的話。
  • 具有元素型內容的元素類型的聲明,如果在這些類型的任一實例中直接出現空白的話。

具有獨立文件聲明的 XML 聲明的例子:

<?xml version="1.0" standalone='yes'?>

2.10 空白處理

在編輯 XML 文件時,使用"空白"(空格,制表符,空行)來分開標記以獲得更好的可讀性是很方便的。通常在文件的交付版本中不想包含這些空白。另一方面,必須保留在交付版本中的有意義的空白是很常見的,如在詩歌和源碼中的空白。

XML 處理器必須始終把不是標記的所有字符傳遞給應用。一個進行驗証的 XML 處理器必須同時通知應用這些字符中的那一些組成了出現在元素型內容中的空白。

可以在元素中附加一個名為 xml:space 的特殊屬性,以通知應用應該保留此元素中的空白。在有效的文件中,此屬性和其他屬性一樣,使用時必須聲明。它必須被聲明為枚舉類型,可以取值 "default" 和 "preserve" 兩者之一,也可以兩個都取。例如:

<!ATTLIST poem  xml:space (default|preserve) 'preserve'>

<!-- -->
<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

"default" 表示可以對此元素使用應用的缺省空白處理模式,"preserve" 表示應用應該保留所有的空白。這适用于其所處元素的內容中的所有元素,除非被另一個 xml:space 屬性的實例所覆蓋。

任何文件的根元素被認為對應用的空白處理方式不作要求,除非它給此屬性賦了值或將此屬性聲明為帶缺省值。

2.11 行尾處理

為編輯的方便起見,存儲 XML 已析實体的計算机文件經常用行來組織。通常這些行用回車符(#xD)和換行符(#xA)的一些組合來分隔。

為了使應用的工作簡單化,XML 處理器應在將字符傳給應用前,將外部已析實体(包括文件實体)中的兩字符序列 "#xD#xA" 或沒有尾隨 #xA 的 #xD 在進行語法分析前轉換成單個 #xA 字符。

2.12 語言標識

在進行文件處理時,標識出其內容所使用的自然或形式化語言經常是很有用的。可以在文件中插入一個名為 xml:lang 的特殊屬性用于指出 XML 文件中任何元素的內容和屬性所使用的語言。在有效的文件中,此屬性和其他屬性一樣,使用時必須聲明。此屬性的值是 [IETF RFC 1766]Tags for the Identification of Languages 或其后的 ITEF 標准中定義的語言標識符。

注:

[IETF RFC 1766] 中的標簽由 [ISO 639] 中定義的兩字母語言碼和 [ISO 3166] 中定義的兩字母國家碼构成,或者由 Internet Assigned Numbers Authority [IANA-LANGCODES] 注冊的語言標識符构成。 預計 [IETF RFC 1766] 的后繼標准將會引入三字母語言碼用于表示 [ISO 639] 中沒有涉及的語言。

(產生式 33 到 38 已被刪除。)

舉例如下:

<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 Bemh'n.</l>
  </sp>

xml:lang 所表示的語言選擇适用于它所處元素的所有屬性和內容,除非被此內容中的元素內的另一個 xml:lang 的實例所覆蓋。

xml:lang 的一個簡單聲明可以采用如下形式:

xml:lang  NMTOKEN  #IMPLIED

但是如果合适的話,也可以給出特定的缺省值。在一本供英國學生使用的法文詩歌集中,評注和注解使用英語,xml:lang 屬性可以這樣聲明:

    <!ATTLIST poem   xml:lang NMTOKEN 'fr'>
    <!ATTLIST gloss  xml:lang NMTOKEN 'en'>
    <!ATTLIST note   xml:lang NMTOKEN 'en'>

3. 邏輯結构

[定義:每個 XML 文件包含一個或多個元素,它們的邊界用起始標簽結束標簽分隔,或者,對于元素,用一個空元素標簽分隔。每一個元素有一個用名字標識的類型,有時稱之為它的"通用標識符(generic identifier)"(GI),同時它可以有一個屬性值說明(attribute specification)集。] 每一個屬性值說明有一個名字和一個

元素
[39]    element    ::=    EmptyElemTag
| STag content ETag [WFC: 元素類型匹配]
[VC: 元素有效性]

除了那些開頭匹配(('X'|'x')('M'|'m')('L'|'l'))的名字保留用于本規范的此版本和后繼版本的標准化外,本規范不對元素類型和屬性的語義,用法和名字(語法之外)作出限制。

格式正确性約束: 元素類型匹配
元素結束標簽中的 Name 必須和起始標簽中的元素類型相匹配。

有效性約束: 元素有效性
如果有一個与 elementdecl 相匹配的聲明的 Name 与元素類型相匹配,且下述之一成立時,稱此元素是有效的:

  1. 此聲明与 EMPTY 相匹配,同時此元素沒有內容
  2. 此聲明与 children 相匹配,同時子元素的序列屬于內容模型中的正則表達式所產生的語言,在起始標簽和第一個子元素之間,子元素之間以及最后一個子元素和結束標簽之間允許有空白(匹配非終結符 S 的字符)。注意,僅包括空白的 CDATA 段不匹配非終結符 S,因此不能在這些位置出現。
  3. 此聲明与 Mixed 相匹配,同時內容由其類型匹配內容模型中的名字的字符數据子元素組成。
  4. 此聲明与 ANY 相匹配,同時每個子元素的類型均已聲明。

3.1 起始標簽,結束標簽和空元素標簽

[定義:每一個非空 XML 元素以一個起始標簽作為開始的標記。]

起始標簽
[40]    STag    ::=    '<' Name (S Attribute)* S? '>' [WFC: 唯一的屬性值說明]
[41]    Attribute    ::=    Name Eq AttValue [VC: 屬性值類型]
[WFC: 無外部實体引用]
[WFC: 在屬性值中沒有<]

起始標簽和結束標簽中的 Name 給出了元素的類型。[定義:Name-AttValue 對被統稱為元素的屬性值說明],[定義:其中每一對中的 Name 被稱為屬性名],[定義:AttValue 的內容(在'"定界符間的文本)被稱為屬性值]。注意,在起始標簽和空元素標簽中各個屬性值聲明的次序沒有意義。

格式正确性約束: 唯一的屬性值說明
一個屬性名只能在同一個起始標簽或空元素標簽中出現一次。

有效性約束: 屬性值類型
屬性必須被聲明,其值必須具有所聲明的類型。(屬性類型參見"3.3 屬性表聲明"。)

格式正确性約束: 無外部實体引用
屬性值不能包含對外部實体直接或間接的實体引用。

格式正确性約束: 在屬性值中沒有 <
在一個屬性值中直接或間接引用的實体的置換文本不能包含 <

起始標簽的一個例子:

<termdef id="dt-dog" term="dog">

[定義:由一個起始標簽開始的每一個元素必須用一個結束標簽標記其結束,結束標簽中的名字必須与起始標簽中給出的元素類型相同:]

結束標簽
[42]    ETag    ::=    '</' Name S? '>'

結束標簽的一個例子:

</termdef>

[定義:在起始標簽和結束標簽中的文本被稱為元素的內容:] 元素的內容

[43]    content    ::=    CharData? ((element | Reference | CDSect | PI | Comment) CharData?)* /* */

[定義:稱沒有內容的元素其內容為。] 空元素可以用一個起始標簽緊跟一個結束標簽的方式或空元素標簽來表示。[定義:空元素標簽有一种特殊的形式:]

空元素標簽
[44]    EmptyElemTag    ::=    '<' Name (S Attribute)* S? '/>' [WFC: 唯一的屬性值說明]

不論元素是否用關鍵字 EMPTY 聲明,空元素標簽都可以用于任何沒有內容的元素。出于互操作性考慮,空元素應該用于,且只應用于聲明為 EMPTY 的元素。

空元素的例子:

<IMG align="left"
 src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/>

3.2 元素類型聲明

出于驗証的目的,可以用元素類型和屬性表聲明限制 XML 文件元素的結构。元素類型聲明限制了元素的內容

元素類型聲明通常限制了子元素的類型。由使用者選擇,當聲明提到的元素類型沒有相應的聲明時,XML 處理器可以給出警告,但這不是一個錯誤。

[定義:元素類型聲明的形式如下:]

元素類型聲明
[45]    elementdecl    ::=    '<!ELEMENT' S Name S contentspec S? '>' [VC: 唯一的元素類型聲明]
[46]    contentspec    ::=    'EMPTY' | 'ANY' | Mixed | children

其中 Name 給出了所聲明的元素類型。

有效性約束: 唯一的元素類型聲明
元素類型只能聲明一次。

元素類型聲明的例子:

<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY>

3.2.1 元素型內容

[定義:當某一類型的元素只能包含用可選空白(匹配非終結符 S)分隔的子元素(無字符數据)時,稱此元素類型具有元素型內容。] [定義:在這种情況下,有內容模型作為類型限制之一,內容模型是決定子元素類型和子元素出現順序的一种簡單文法。] 此文法用內容粒子( cp )构建,內容粒子由名字,內容粒子的選擇表(choice list)或內容粒子的序列表(sequence list)組成:

元素型內容的模型
[47]    children    ::=    (choice | seq) ('?' | '*' | '+')?
[48]    cp    ::=    (Name | choice | seq) ('?' | '*' | '+')?
[49]    choice    ::=    '(' S? cp ( S? '|' S? cp )+ S? ')' /* */
/* */
[VC: 嚴格的組/參數實体嵌套]
[50]    seq    ::=    '(' S? cp ( S? ',' S? cp )* S? ')' /* */
[VC: 嚴格的組/參數實体嵌套]

其中每一個 Name 是可以作為子元素的元素的類型。選擇表中出現的任意內容粒子在元素型內容中允許出現的位置對應于選擇表在文法中的位置。序列表中出現的所有內容粒子必須以相同的順序出現在元素型內容中。在名字或表之后的可選字符(optional character)決定了表中元素或內容粒子可以出現一次或多次(+),還是零次或多次(*),或是零次或一次(?)。沒有這樣一個操作符意味著元素或內容粒子必須恰好出現一次。這种語法和意義和本規范中的產生式中所使用的相同。

當且僅當一個元素的內容可以通過滿足內容模型中的選擇,序列和重复操作符得到,并且內容中的每一個元素与內容模型中的一种元素類型相匹配時,稱此元素的內容与該內容模型相匹配。出于兼容性考慮, 如果文件的某個元素可以和內容模型中的一种元素類型多次匹配,這是一個錯誤。 更詳細的信息參見"E. 确定型內容模型".

有效性約束: 嚴格的組/參數實体嵌套
參數實体的置換文本必須由括號括起的組嚴格嵌套。即,如果 choiceseqMixed 語法成分的開始或結束括號出現在某個參數實体的置換文本中,兩者必須同在此置換文本中。

出于互操作性考慮,如果一個參數實体引用出現在choiceseqMixed語法成分中時,它的置換文本至少應該包含一個非空字符,同時其置換文本的第一個和最后一個非空字符都不應為一個連接符(|,)。

元素型內容的模型舉例:

<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>

3.2.2 混合型內容(Mixed Content)

[定義:當某元素類型可以包含字符數据,其間可以隨意穿插子元素時,稱此元素類型具有混合型內容。] 在這种情況下,對子元素的類型可能有所限制,但對它們的次序和出現次數沒有限制:

混合型內容聲明
[51]    Mixed    ::=    '(' S? '#PCDATA' (S? '|' S? Name)* S? ')*'
| '(' S? '#PCDATA' S? ')' [VC: 嚴格的組/參數實体嵌套]
[VC: 無重复類型]

其中 Name 給出了子元素的元素的類型。關鍵字 #PCDATA 來自術語"已析字符數据(parsed character data)"而來

有效性約束: 無重复類型
同一名字在單個混合型內容聲明中只能出現一次。

混合內容聲明的例子:

<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)>

3.3 屬性表聲明

屬性用于關聯名字-值對和元素。屬性值說明只能在起始標簽空元素標簽中出現; 因此,用于識別它們的產生式出現在"3.1 起始標簽,結束標簽和空元素標簽"中。屬性表聲明可以用于:

  • 定義与一給定元素類型有關的屬性集。
  • 确定這些屬性的類型限制。
  • 提供屬性的缺省值

[定義:屬性表聲明詳細說明了与給定元素類型相關聯的每一個屬性的名字,數据類型和缺省值(如果有的話):]

屬性表聲明
[52]    AttlistDecl    ::=    '<!ATTLIST' S Name AttDef* S? '>'
[53]    AttDef    ::=    S Name S AttType S DefaultDecl

AttlistDecl 規則中 Name 是元素的類型。由使用者選擇,當屬性聲明相關的元素類型沒有被聲明時,XML 處理器可以給出一個警告,但這不是一個錯誤。AttDef 規則中的 Name 是屬性的名字。

當与某個給定元素類型相關的 AttlistDecl 超過一個時,這些聲明中的內容被合并在一起。當給定元素類型的某個屬性的定義超過一個時,綁定第一個定義,其余定義被忽略。出于互操作性考慮,DTD 的作者可以這樣做:一個給定的元素類型至多有一個屬性表聲明,一個屬性表中一個給定的屬性名至多有一個屬性定義,每個屬性表聲明至少有一個屬性定義。出于互操作性考慮,當一個給定元素有超過一個的屬性表聲明或一個給定屬性有超過一個的屬性定義時,XML 處理器可以,由使用者選擇,給出警告,但這不是一個錯誤。

3.3.1 屬性類型

XML 屬性有三种類型:字符串類型,一組記號化類型和枚舉類型。字符串類型可以以任意常量字符串為值; 各個記號化類型有不同的詞法和語義約束。文法中指出的有效性約束适用于屬性值已按 3.3 節 3.3 屬性表聲明中所述規范化了之后的情況。

屬性類型
[54]    AttType    ::=    StringType | TokenizedType | EnumeratedType
[55]    StringType    ::=    'CDATA'
[56]    TokenizedType    ::=    'ID' [VC: ID]
[VC: 每种元素類型一個 ID]
[VC: ID 屬性的缺省值]
| 'IDREF' [VC: IDREF]
| 'IDREFS' [VC: IDREF]
| 'ENTITY' [VC: 實体名]
| 'ENTITIES' [VC: 實体名]
| 'NMTOKEN' [VC: 名字記號]
| 'NMTOKENS' [VC: 名字記號]

有效性約束: ID
ID 類型的值必須匹配 Name 產生式。作為此類型值的名字只能在 XML 文件中出現一次;即,ID 類型的值必須能唯一標識元素。

有效性約束: 每种屬性類型一個ID
每种屬性類型只能有一個 ID 屬性。

有效性約束: ID 屬性的缺省值
ID 屬性必須有一個聲明為 #IMPLIED#REQUIRED 的缺省值。

有效性約束: IDREF
IDREF 類型的值必須匹配 Name 產生式,IDREFS 類型的值必須匹配 Names 產生式;每一個 Name 必須匹配 XML 文件中某些元素 ID 屬性的值;也就是說,IDREF 類型的值必須匹配某些 ID 屬性的值。

有效性約束: 實体名
ENTITY 類型的值必須匹配 Name 產生式,ENTITIES 類型的值必須匹配 Names 產生式;每一個 Name 必須匹配 未析實体的名字。

有效性約束: 名字記號
NMTOKEN 類型的值必須匹配 Nmtoken 產生式;NMTOKENS 類型的值必須匹配 Nmtokens 產生式。

[定義:枚舉類型的屬性可以在聲明中提供的取值表中取值。] 有兩种枚舉類型:

枚舉屬性類型
[57]    EnumeratedType    ::=    NotationType | Enumeration
[58]    NotationType    ::=    'NOTATION' S '(' S? Name (S? '|' S? Name)* S? ')' [VC: 記法屬性]
[VC: 每种屬性類型一种記法]
[VC: 空元素沒有記法]
[59]    Enumeration    ::=    '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')' [VC: 枚舉]

一個 NOTATION 類型的屬性標識了一种用于解釋与此屬性相關的元素的記法,此記法中用系統或公共標識符在 DTD 中聲明。

有效性約束: 記法屬性
此類型的值必須与聲明中所包含的記法名之一相匹配;聲明中的所有記法名都必須聲明。

有效性約束: 每种屬性類型一种記法

每种元素類型的 NOTATION 屬性不能多于一個。

有效性約束: 空元素沒有記法

出于兼容性考慮,聲明為 EMPTY 的元素不能聲明類型為 NOTATION 的屬性。

有效性約束: 枚舉
此類型的值必須与聲明中所包含的 Nmtoken 記號之一相匹配。

出于互操作性考慮,同一 Nmtoken 只能在單個元素類型的枚舉屬性類型中出現一次。

3.3.2 屬性缺省值

屬性聲明提供的信息指明了某屬性是否必須出現,同時指明了在被聲明的屬性不是必須出現而文件中沒有出現此屬性的情況下,XML 處理器應如何處理。

屬性缺省值
[60]    DefaultDecl    ::=    '#REQUIRED' | '#IMPLIED'
| (('#FIXED' S)? AttValue) [VC: 必須的屬性]
[VC: 合法的屬性缺省值]
[WFC: 在屬性值中無 < ]
[VC: 固定的屬性缺省值]

在一個屬性聲明中,#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">

3.3.3 屬性-值對的規范化(Attribute-Value Normalization)

在將屬性的值傳給應用或檢驗其有效性之前,XML 處理器必須使用下面的算法(或使用其他能使傳給應用的值与用此算法得到的值相同的方法)將其規范化。

  1. 所有的行尾必須在輸入時如 2.11 行尾處理中所述規范成 #xA,本算法的其余部分作用于以此方法規范化之后的文本。

  2. 開始時規范化之后的值包含空字符串。

  3. 對于未經規范化的屬性值中的每個字符,實体引用或字符引用,從第一個開始,直到最后一個,做如下操作:

    • 對于一個字符引用,將其所引用的字符加在規范化之后的值的末尾。

    • 對于一個實体引用,對此實体的置換文本遞歸地使用本算法的第 3 步。

    • 對于一個空白字符(#x20, #xD, #xA, #x9),在規范化之后的值的末尾加一個空格字符(#x20)。

    • 對于其他字符,將其加在規范化之后的值的末尾。

如果屬性值的類型不是 CDATA,那么 XML 處理器必須繼續處理規范化之后的值,去掉其前導和尾隨空格(#x20)字符,并將空格(#x20)字符序列替換成單個空格(#x20)字符。

注意,如果未經規范化的屬性值中包含對空格字符(#x20)以外的空白字符的引用,那么規范化之后的值包含被引用的字符本身(#xD, #xA or #x9),而不是空格(#x20)。這与未經規范化的屬性值中包含空白字符(不是引用)的情況不同,在那种情況下空白字符被置換成空格字符(#x20)。同時這也与未經規范化的屬性值中所包含的實体引用的置換文本中包含空白字符的的情況不同,在那种情況下,實体引用的置換文本被遞歸處理,空白字符被置換成空格字符(#x20)。

不進行驗証的處理器應該將所有尚未讀到其聲明的屬性當成聲明為 CDATA 處理。

以下是屬性規范化的例子。有如下聲明:

<!ENTITY d "&#xD;">
<!ENTITY a "&#xA;">
<!ENTITY da "&#xD;&#xA;">

下表中左邊一列中的屬性值說明在 a 聲明為 NMTOKENS 的情況下規范化為中間一列的字符序列,在 a 聲明為 CDATA 的情況下規范化為右邊一列中的字符序列。

未析實体TH>屬性值說明
a 聲明為 NMTOKENS a 聲明為 CDATA
a="

xyz"
x y z #x20 #x20 x y z
a="&d;&d;A&a;&a;B&da;"
A #x20 B #x20 #x20 A #x20 #x20 B #x20 #x20
a=
"&#xd;&#xd;A&#xa;&#xa;B&#xd;&#xa;"
#xD #xD A #xA #xA B #xD #xA #xD #xD A #xA #xA B #xD #xD

注意,在 a 聲明為 NMTOKENS 類型的情況下,最后一個例子不是有效的(但是是格式正确的)。

3.4 條件段(Conditional Sections)

[定義:條件段文件類型聲明外部子集的一部分,取決于相應的關鍵字,它們或被包含在 DTD 邏輯結构之內,或被排除在 DTD 邏輯結构之外。]

條件段
[61]    conditionalSect    ::=    includeSect | ignoreSect
[62]    includeSect    ::=    '<![' S? 'INCLUDE' S? '[' extSubsetDecl ']]>' /* */
[VC: 嚴格的條件段/參數實体嵌套]
[63]    ignoreSect    ::=    '<![' S? 'IGNORE' S? '[' ignoreSectContents* ']]>' /* */
[VC: 嚴格的條件段/參數實体嵌套]
[64]    ignoreSectContents    ::=    Ignore ('<![' ignoreSectContents ']]>' Ignore)*
[65]    Ignore    ::=    Char* - (Char* ('<![' | ']]>') Char*)

有效性約束: 嚴格的條件段/參數實体嵌套

如果一個條件段的 "<![","[" 或 "]]>" 中的任意一個包含在一個參數實体中的置換文本中,它們必須全部在此同一置換文本中。

同內部或外部 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?)>
]]>

4. 物理結构

[定義:一個 XML 文件可能包含一個或多個存儲單元。它們被稱為實体(entity);它們都具有內容并且都用名字進行標識(除了文件實体,見下,和外部 DTD 子集之外)。] 每一個 XML 文件有一個稱為文件實体的實体,它作為 XML 處理器處理的起點并可能包含了整個文件。

實体可以是已析的或未析的。[定義:已析實体(parsed entity)的內容被稱為它的置換文本;此文本被看成是文件整体的一部分。]

未析實体(unparsed entity)是一种資源,其內容可以是也可以不是文本,并且,如果是文本的話,可以不是 XML 文本。每一個未析實体有一個相關聯的用名字標識的記法。除了要求 XML 處理器能向應用提供實体和記法的標識符之外,XML 對未析實体的內容不作任何限制。]

已析實体以實体引用的方式使用名字來調用;未析實体用 ENTITYENTITIES 屬性中給出的名字調用。

[定義:普通實体(general entity)是那些在文件內容中使用的實体。在本規范中,普通實体有時用未修飾的術語entity來表示。] [定義:參數實体是用于 DTD 內的已析實体。]這兩類實体用不同形式的引用,在不同的上下文中識別。另外,它們使用不同的名域;具有相同名字的參數實体和普通實体是兩個截然不同的兩個實体。

4.1 字符和實体引用(Character and Entity References)

一個字符引用引用 ISO/IEC 10646 字符集中的一個字符。例如不能用輸入設備直接輸入的字符。

字符引用
[66]    CharRef    ::=    '&#' [0-9]+ ';'
| '&#x' [0-9a-fA-F]+ ';' [WFC: 合法字符]

格式正确性約束: 合法字符
用字符引用引用的字符必須匹配 Char 產生式。

如果字符引用以 "&#x" 開頭,直到終結 ; 的數字和字母提供了某字符在 ISO/IEC 10646 中代碼的一個十六進制表示。如果它僅以 "&#" 開頭,直到終結 ; 的數字提供了某字符的代碼的十進值表示。

實体引用(entity reference)引用一個命名實体的內容。對已析普通實体的引用使用 "and" 號(&)和分號(;)作為定界符。參數實体引用則使用百分號(%)和分號(;)作為定界符。

實体引用
[67]    Reference    ::=    EntityRef | CharRef
[68]    EntityRef    ::=    '&' Name ';' [WFC: 聲明實体]
[VC: 聲明實体]
[WFC: 已析實体]
[WFC: 無遞歸]
[69]    PEReference    ::=    '%' Name ';' [VC: 聲明實体]
[WFC: 無遞歸]
[WFC: 在 DTD 內]

格式正确性約束: 聲明實体
在一個沒有任何 DTD 的文件,或一個只有不包含參數實体引用的內部 DTD 子集的文件,或一個 "standalone='yes'" 的文件內,不在外部子集或參數實体內的實体引用中給出的 Name 必須与不在外部子集或參數實体內實体聲明中所給出的相匹配,但格式正确的文件不需要聲明以下的這些實体:ampltgtaposquot。普通實体的聲明必須先于任何在屬性表聲明中的缺省值中出現的對它的引用。注意,對于在外部子集或外部參數實体中聲明的實体,不進行驗証的處理器不必要讀取和處理它們的聲明;對這些文件,僅當 standalone='yes' 時,實体必須被聲明的規則才是一個格式正确性約束。

有效性約束: 聲明實体
在一個有外部子集或外部參數實体且 "standalone='no'" 的實体中,實体引用中給出的 Name 必須与實体聲明中所給出的相匹配。出于互操作性考慮,有效的文件應該以"4.6 預定義實体"中的簡化形式聲明實体 ampltgtaposquot。參數實体的聲明必須先于任何對它的引用。類似地,普通實体的聲明必須先于任何在屬性表聲明中的缺省值中出現的對它直接或間接的引用。

格式正确性約束: 已析實体
實体引用不能包含一個未析實体的名字。未析實体只能在聲明為 ENTITYENTITIES屬性值中引用。

格式正确性約束: 無遞歸
已析實体不能直接或間接地包含對自身的遞歸引用。

格式正确性約束: 在 DTD 內
參數實体引用只能在 DTD 中出現。

字符引用和實体引用的例子:

Type <key>less-than</key> (&#x3C;) 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;

4.2 實体聲明(Entity Declaration)

[定義:實体以如下方式聲明:]

實体聲明
[70]    EntityDecl    ::=    GEDecl | PEDecl
[71]    GEDecl    ::=    '<!ENTITY' S Name S EntityDef S? '>'
[72]    PEDecl    ::=    '<!ENTITY' S '%' S Name S PEDef S? '>'
[73]    EntityDef    ::=    EntityValue | (ExternalID NDataDecl?)
[74]    PEDef    ::=    EntityValue | ExternalID

實体引用中的 Name 標識了該實体;對于未析實体,ENTITYENTITIES 屬性的值標識了該實体。如果同一實体被聲明了不止一次,綁定第一個遇到的聲明。由使用者選擇,如果實体被多次聲明,XML 處理器可以給出警告。

4.2.1 內部實体(Internal Entities)

[定義:如果實体定義是一個 EntityValue,被定義的實体被稱為內部實体。] 內部實体沒有單獨的物理存儲對象,實体的內容在聲明中給出。注意常量實体值中一些實体和字符引用的處理可能要求產生正确的置換文本:參見"4.5 內部置換文本的构造"。

內部實体是已析實体

內部實体聲明的例子:

<!ENTITY Pub-Status "This is a pre-release of the
 specification.">

4.2.2 外部實体(External Entities)

[定義:如果實体不是內部的,那么它是一個外部實体,聲明如下:]

外部實体聲明
[75]    ExternalID    ::=    'SYSTEM' SSystemLiteral
| 'PUBLIC' S PubidLiteral S SystemLiteral
[76]    NDataDecl    ::=    S 'NDATA' S Name [VC: 聲明記法]

如果有 NDataDecl,那么這是一個普通未析實体;否則它是一個已析實体。

有效性約束: 聲明記法
Name必須与記法的名字相匹配。

[定義:SystemLiteral 被稱為該實体的系統標識符。這是一個 URI 引用(在 [IETF RFC 2396] 中定義,在 [IETF RFC 2732] 中更新),可以由此獲得 XML 處理器的輸入用于构建此實体的置換文本。] 片斷標識符(以 # 開頭)出現在系統標識符中是一個錯誤。如果一個片斷標識符作為系統標識符的部分給出,XML 處理器可以給出一個錯誤。除非在本規范范圍之外另外給出(如,一個特殊 DTD 中定義的專用 XML 元素類型,或一個特殊應用規范中定義的處理指令),相對 URI 指相對于實体聲明所在資源的位置。因此,一個 URI 可能是相對于文件實体,或相對于包含外部 DTD 子集的實体,或相對于其他一些外部參數實体

URI 引用需要對某些字符進行編碼和轉義。不允許出現的字符包括所有非 ASCII 字符,以及 [IETF RFC 2396] 第 2.4 節中列出的不被允許的字符,井號(#)、百分號(%)) 和 [IETF RFC 2732] 中允許的方括號除外。不被允許的字符必須用如下的方法轉義:

  1. 每個不被允許的字符首先被轉換成一個或多個字節的 UTF-8 [IETF RFC 2279] 編碼。

  2. 任何對應于一個不被允許的字符的八位組用 URI 轉義机制轉義(即,將其轉換成%HH,其中 HH 是字節值的十六進制記法)。

  3. 用得到的字符序列置換原來的字符。

除了系統標識符之外,外部標識符還可以包含公共標識符。試圖存取實体內容的 XML 處理器可以用公共標識符試著產生一個可選 URI 引用。如果處理器無法做到這一點,它必須使用系統常量中的 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 >

4.3 已析實体(Parsed Entities)

4.3.1 文本聲明(Text Declaration)

[定義:每個外部已析實体應該以文本聲明作為開始。]

文本聲明
[77]    TextDecl    ::=    '<?xml' VersionInfo? EncodingDecl S? '?>'

文本聲明必須以常量形式給出,而不能使用已析實体的引用。文本聲明只能在外部已析實体的開頭出現,不允許在其他任何地方出現。在外部已析實体中的文本聲明不被認為是其置換文本的一部分

4.3.2 格式正确的已析實体(Well-Formed Parsed Entities)

如果文件實体匹配 document 產生式,那么它是格式正确的。如果外部普通已析實体匹配 extParsedEnt 產生式,那么它是格式正确的。如果外部參數實体匹配 extPE 產生式,那么它是格式正确的。根据定義,外部參數實体是格式正确的。

格式正确的外部已析實体
[78]    extParsedEnt    ::=    TextDecl? content

如果內部普通已析實体的置換文本匹配 content 產生式,那么它是格式正确的。根据定義,所有內部的參數實体都是格式正确的。

實体符合格式正确性的一個結果是 XML 文件的邏輯和物理結构是嚴格嵌套的;起始標簽結束標簽空元素標簽元素注釋處理指令字符引用,或實体引用都不能在一個實体中開始而在另一個實体中結束。

4.3.3 實体中的字符編碼(Character Encoding in Entities)

XML 文件中的每個外部已析實体都可以對其字符采用一种不同的編碼方案。所有 XML 處理器必須能讀取編碼為 UTF-8 和 UTF-16 的實体。本規范中的術語 "UTF-8" 和 "UTF-16" 不适用于任何采用其他標識(label)的字符編碼,即使這种編碼或標識与 UTF-8 或 UTF-16 非常類似。

以 UTF-16 編碼的實体必須以 ISO/IEC 10646 增補 F,[ISO/IEC 10646-2000] 增補 H, [Unicode] 的 2.4 節和 [Unicode3] 2.7 節(零寬度不間斷空格字符,#xFEFF)中所描述的字節次序標記(Byte Order Mark)開頭。這是一個編碼簽名,即不是 XML 文件中標記的一部分,也不是 XML 文件字符數据的一部分。XML 處理器必須能用此字符區分 UTF-8 編碼和 UTF-16 編碼的文件。

雖然 XML 處理器只被要求能讀取 UTF-8 和 UTF-16 編碼的實体,不過對于世界上還有其他的編碼方案已有共識。有時可能想讓 XML 處理器讀取以那些編碼方案編碼的實体。在沒有外部字符編碼信息(如 MIME 頭)的情況時,以不同于 UTF-8 和 UTF-16 的編碼方案存儲的實体必須以包含編碼聲明的文本聲明(見 4.3.1 文本聲明)開頭:

編碼聲明
[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-n" (其中 n 是區塊號)應該用于表示 ISO 8859 的各個部分,而值 "ISO-2022-JP","Shift_JIS" 和 "EUC-JP" 應該用于表示 JIS X-0208-1997 的各种編碼。建議對于在 Internet Assigned Numbers Authority [IANA] 注冊的字符編碼方案(以字符集(charset)的方式),除了以上所列之外的編碼方案,應該用它們的注冊名引用。其他的編碼應該使用帶 "x-" 前綴的名稱。欲与之匹配的 XML 處理器應該以大小寫敏感的方式對字符編碼的名稱進行匹配。而且 XML 處理器處理字符編碼的名稱時,應該將在 IANA 注冊的編碼名稱解釋為在 IANA 注冊的相應編碼,不然就應該當成未知的編碼(當然,不要求處理器支持所有在 IANA 注冊的編碼)。

在缺少外部傳輸協議(如 HTTP 或 MIME)所提供的信息時,以下情況均是錯誤:XML 處理器接收到的實体的編碼方案与實体所含編碼聲明中指出的編碼方案不同,既不以字節次序標記開頭也不以編碼聲明開頭的實体使用了不同于 UTF-8 的編碼。注意,因為 ASCII 是 UTF-8 的一個子集,嚴格說來普通 ASCII 字符不需要編碼聲明。

TextDecl 出現在外部實体開頭以外的地方是一個嚴重錯誤。

當 XML 處理器遇到的實体使用了它不能處理的編碼時,是一個嚴重錯誤。如果一個 XML 實体被确認為使用了某种編碼(由默認值,編碼聲明或高層協議确定),但是它包含了在此編碼中非法的八位組序列的話,是一個嚴重錯誤。如果一個 XML 實体沒有編碼聲明而它的內容不是合法的 UTF-8 或 UTF-16 編碼的話,也是一個嚴重錯誤。

包含編碼聲明的文本聲明的例子:

<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>

4.4 XML 處理器對實体和引用的處理

下表匯總了字符引用,實体引用,和對未析實体的調用可以出現的上下文,以及每种情況下 XML 處理器的動作。最左邊一列的標識指明了識別時的上下文:

內容中的引用
可以在元素的起始標簽之后,結束標簽之前的任何地方以引用形式出現,對應于非終結符 content
屬性值中的引用
可以在起始標簽內的屬性值中,或屬性聲明內的缺省值中以引用形式出現;對應于非終結符 AttValue
作為屬性值
可以以 Name 而不是以引用的形式出現,作為聲明為 ENTITY 類型的屬性的值,或可以作為聲明為 ENTITIES 類型的屬性值中的以空白分隔的記號之一。
實体值中的引用
可以在參數中或內部實体的實体聲明內的常量實体值中以引用形式出現;對應于非終結符 EntityValue
DTD 中的引用
DTD 的內部或外部子集中的引用,但在 EntityValueAttValuePICommentSystemLiteralPubidLiteral 或被忽略的條件段的內容(見 3.4 條件段)之外。
實体類型 字符
參數 內部普通 外部已析普通 未析
內容中的引用 不被識別 被包含 進行驗証時被包含 被禁止 被包含
屬性值中的引用 不被識別 作為常量被包含 被禁止 被禁止 被包含
作為屬性值 不被識別 被禁止 被禁止 通知 不被識別
實体值中的引用 作為常量被包含 不處理 不處理 被禁止 被包含
DTD 中的引用 作為參數實体被包含 被禁止 被禁止 被禁止 被禁止

4.4.1 不被識別(Not Recognized)

在 DTD 之外,百分號字符 % 沒有特殊含義;因此在 DTD 中的參數實体引用在 content 中不被當成標記識別。類似地,除非未析實体的名字出現在已适當聲明的屬性的值中,否則它們不被識別。

4.4.2 被包含(Included)

[定義:當一個實体的置換文本被當成出現在引用所在位置的文件的一部分一樣被存取和處理時,稱此實体被包含。] 其置換文本可以包含字符數据標記(不包括參數實体),其中標記必須以通常的方式識別。(字符串 "AT&amp;T;" 展開為 "AT&T;",尚存的 "and" 號 & 不被識別為實体引用的定界符。)當被表示的字符被當成出現在引用所在位置一樣被處理時,稱此字符引用被包含

4.4.3 進行驗証時被包含(Included If Validating)

當 XML 處理器識別出一個對已析實体的引用,為了驗証該文件,處理器必須包含此實体的置換文本。如果實体是外部的,而處理器不試圖驗証該 XML 文件,那么處理器可以,但不是必須,包含此實体的置換文本。如果一個不進行驗証的處理器不包含此置換文本,它必須通知應用它識別出但沒有讀取此實体。

這條規則基于這樣一個共識:由 SGML 和 XML 的實体机制提供的起初設計用于支持模塊化創作的自動包含不一定适合于其他應用,尤其是文件瀏覽。例如,當瀏覽器遇到一個外部已析實体引用時,可能選擇用可視方式表示其存在但只在被請求時才讀取它進行顯示。

4.4.4 被禁止(Forbidden)

以下情況被禁止,并构成一個嚴重錯誤:

  • 出現對未析實体的引用。
  • 在 DTD 中出現任何字符或普通實体引用,除非它們出現在 EntityValueAttValue 中。
  • 屬性值中出現對外部實体的引用。

4.4.5 作為常量被包含(Included in Literal)

實体引用出現在屬性值中或參數實体引用出現在常量實体值中時,它們的置換文本被當成出現在引用所在位置的文件的一部分一樣被存取和處理,置換文本中的單雙引號總是被當成正常的數据字符而不會結束此常量。例如,下面的例子是格式正确的:

<!--  -->
<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" >

而這個例子不是:

<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>

4.4.6 通知(Notify)

未析實体名字作為記號在聲明為 ENTITYENTITIES 類型的屬性的值中出現時,進行驗証的處理器必須將此實体和它的相關記法系統公共(如果有的話)標識符通知給應用。

4.4.7 不處理(Bypassed)

當實体聲明內一個普通實体引用出現在 EntityValue 中時,它不被處理,保持不變。

4.4.8 作為參數實体被包含(Included as PE)

和外部已析實体一樣,參數實体只需在進行驗証時被包含。當參數實体引用在 DTD 中被識別并被包含時,它的置換文本被前后各加上一個空格字符;其目的在于強制參數實体的置換文本包含整數個 DTD 中的語法記號。這不适用于實体值內的參數實体;對它們的處理見 4.4.5 作為常量被包含

4.5 內部實体置換文本的构建(Construction of Internal Entity)

在討論內部實体的處理時,區分兩种形式的實体值是有幫助的。[定義:常量實体值(literal entity value)是實際出現在實体聲明中用引號擴起的字符串。] 對應于非終結符 EntityValue置換文本(replacement text)是置換了字符引用和參數實体引用后的實体內容。

在內部實体聲明(EntityValue)中給出的常量實体值可以包括字符引用,參數實体引用和普通實体引用。這些引用必須被整個包含于常量實体值中。如前述方式被包含的實際置換文本必須包含所有被引用的參數實体的置換文本,同時所有被引用的字符必須在常量實体值中字符引用所在位置被包含。但普通實体的引用必須保持不變,不被展開。例如,如果有以下的聲明:

<!ENTITY % pub    "&#xc9;ditions Gallimard" >
<!ENTITY   rights "All rights reserved" >
<!ENTITY   book   "La Peste: Albert Camus, 
&#xA9; 1947 %pub;. &rights;" >

那么實体 "book" 的置換文本為:

La Peste: Albert Camus, 
?nbsp;1947 丼itions Gallimard. &rights;

一旦引用 "&book;" 出現在文件的內容或屬性值中時,普通實体引用 "&rights;" 應該被展開。

這些簡單的規則將可能會有复雜的相互作用;參見 "D. 實体和字符引用的展開" 中對一個難的例子的詳細討論。

4.6 預定義實体(Predefined Entities)

[定義:實体和字符引用都可以用于轉義左尖括號,"and" 號(&)和其他定界符。普通實体集合(ampltgtaposquot)專門用于此目的。也可以使用數值字符引用;一旦被識別,它們立即被展開,同時它們必須被當成字符數据,因此數值字符引用 "&#60;" 和 "&#38;" 可以用于轉義出現在字符數据中的 <&。]

不管這些實体是否被聲明,所有的 XML 處理器必須能識別它們。出于互操作性考慮,有效的 XML 文件應該如其他實体一樣,在使用這些實体前先聲明它們。如果實体 ltamp 被聲明,它們必須被聲明為置換文本為相應被轉義字符的字符引用(小于號或 "and" 號)的內部實体;對這些實体需要轉義兩次以使對它們的引用能得到格式正确的結果。如果實体 gtaposquot 被聲明,它們必須被聲明為置換文本為相應被轉義的單個字符的內部實体(或指向被轉義字符的字符引用;這里轉義兩次是不必要的,但也是無害的)。例如:

<!ENTITY lt     "&#38;#60;"> 
<!ENTITY gt     "&#62;"> 
<!ENTITY amp    "&#38;#38;"> 
<!ENTITY apos   "&#39;"> 
<!ENTITY quot   "&#34;"> 

4.7 記法聲明(Notation Declarations)

[定義:記法用名字標識了未析實体的格式,具有記法屬性的元素的格式以及處理指令所針對的應用的格式。]

[定義:記法聲明賦予記法一個名字用于實体中,屬性表聲明中和屬性值說明中,同時也給出了一個記法的外部標識符使得 XML 處理器或它的客戶應用可以定位能以給定記法的格式處理數据的助理應用。]

記法聲明
[82]    NotationDecl    ::=    '<!NOTATION' S Name S (ExternalID | PublicID) S? '>' [VC: 唯一的記法名字]
[83]    PublicID    ::=    'PUBLIC' S PubidLiteral

有效性約束:唯一的記法名字

一個給定的 Name 只能被一個記法聲明所聲明.

XML 處理器必須向應用提供任何在屬性值中,屬性定義中或實体聲明中定義或引用的記法的名字和外部標識符。它們還可以將外部標識符解析成系統標識符,文件名,或是應用調用相應處理器處理給定記法格式的數据的所需的其他信息。(但如果 XML 處理器或應用所運行的系統中沒有處理 XML 文件聲明和引用的記法的相應應用的情況,不是一個錯誤。)

4.8 文件實体(Document Entity)

[定義:文件實体(document entity)是實体樹的根和 XML 處理器的處理起點。] 本規范沒有規定 XML 如何定位文件實体;与其他實体不同,文件實体沒有名字,而且可以完全不帶任何標識地出現在處理器的輸入流中。

5. 一致性(Conformance)

5.1 進行驗証和不進行驗証的處理器(Validating and Non-Validating Processors)

合乎規范的 XML 處理器可以分為兩類:進行驗証的和不進行驗証的。

進行驗証和不進行驗証的處理器都必須報告在文件實体的內容中和任何其他它們讀到的已析實体中對格式正确性約束的違反。

[定義:進行驗証的處理器必須,由使用者選擇,報告違反 DTD 聲明中所述約束的情況以及不滿足本規范中給出的有效性約束的情況。] 要完成這一點,進行驗証的 XML 處理器必須讀取和處理整個 DTD 和所有在文件中引用的外部已析實体。

不進行驗証的處理器只被要求檢查文件實体和整個內部 DTD 子集的格式正确性。[定義:雖然它們不被要求檢查文件的有效性,但它們必須處理它們讀取的所有內部 DTD 子集中的聲明和所有參數實体,直到遇到第一個對它們沒有讀取的參數實体的引用;也就是說,它們必須根据這些聲明中的信息規范化屬性值,包含內部實体的置換文本,并提供缺省屬性值。] 除了 standalone="yes" 的情況,它們在遇到第一個對它們沒有讀取的參數實体的引用后,不應處理其后的實体聲明屬性表聲明,因為此實体中包含的聲明可能覆蓋前面的聲明。

5.2 使用 XML 處理器

進行驗証的處理器的行為是高度可預測的;它必須讀取文件的所有部分,報告所有對格式正确性和有效性的違反。對一個不進行驗証的處理器的要求要低一點;它不需要讀取文件實体以外的任何文件部分。這對 XML 的處理器的使用者而言可能會有兩個重要的影響:

  • 某些格式正确性錯誤,尤其是那些要求讀取外部實体的,可能不會被不進行驗証的處理器檢測到。例子有稱為聲明實体已析實体無遞歸的約束,以及"4.4 XML 處理器對實体和引用的處理"中描述為被禁止的一些情況。
  • 取決于處理器是否讀取參數和外部實体,從處理器傳給應用的信息可能會有所不同。例如,不進行驗証的處理器可能不規范化屬性值,不包含內部實体的置換文本,或不提供缺省屬性值,這些動作要求先讀取外部或參數實体中的聲明。

為了使不同 XML 處理器間的互操作有最大的可靠性,使用不進行驗証的處理器的應用不應依賴于不要求這些處理器具備的動作。那些要求使用如缺省值或在外部實体中聲明內部實体等功能的應用應該使用進行驗証的 XML 處理器。

6. 記法(Notation)

本規范中 XML 的形式化文法用一种簡單的擴展巴科斯范式(Extended Backus-Naur Form,EBNF)給出。文法中的每一條規則定義了一個符號,形式如下:

symbol ::= expression

如果符號是正則語言的起始符號,則它以大寫字母開頭,否則以小寫字母開頭。字符串常量(literal strings)用引號括起。

在規則右邊的表達式中,以下表達式用于匹配一個或多個字符的字符串:

#xN

N 是一個十六進制的整數,當 ISO/IEC 10646 中某個字符的規范(UCS-4)代碼值作為無符號二進制數与 N 相等時,此表達式匹配這個字符。#xN 中的前導 0 沒有意義,在相應的代碼值中的前導 0 的個數則由所用字符編碼方案決定,對 XML 沒有意義。

[a-zA-Z][#xN-#xN]

与其值在指定范圍內的任何 Char 相匹配(含界,inclusive)。

[abc], [#xN#xN#xN]

与其值為所枚舉的值之一的 Char 相匹配。在一對方括號內枚舉和范圍可以混用。

[^a-z][^#xN-#xN]

与其值在指定范圍之外的任何 Char 相匹配。

[^abc][^#xN#xN#xN]

与任何不在給定字符集內的 Char 相匹配。在一對方括號內被禁值的枚舉和范圍可以混用。

"string"

匹配雙引號中所給字符串的常量字符串相匹配。

'string'

匹配單引號中所給字符串的常量字符串相匹配。

這些符號可以按下列方式組合,以匹配更复雜的模式,其中AB表示簡單表達式:

(expression)
expression 被當成一個單元,可以向本表描述的那樣進行組合。
A?
与零個或一個 A 相匹配,即 A 可選。
A B
A 后跟 B 的模式相匹配。這個操作符的优先級高于 |,因此 A B | C D 相當于 (A B) | (C D)
A | B
AB 之一相匹配,但不同時匹配。
A - B
与任何匹配 A 但不匹配 B 的字符串相匹配。
A+
与一個或多個 A 相匹配。連接操作的优先級高于 |,因此 A+ | B+ 相當于 (A+) | (B+)
A*
与零個或多個 A 相匹配。連接操作的优先級高于 |,因此 A* | B* 相當于 (A*) | (B*)

其他在產生式中使用的記法有:

/* ... */
注釋
[ wfc: ... ]
格式正确性約束;用名字標識一個對与某個產生式相關聯的格式正确的文件的約束。
[ vc: ... ]
有效性約束;用名字標識一個對与某個產生式相關聯的有效的文件的約束。

附錄

A. 參考文獻

A.1 正式參考文獻

IANA-CHARSETS
(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/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).
ISO/IEC 10646-2000
ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 2000.
Unicode
The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.
Unicode3
The Unicode Consortium. The Unicode Standard, Version 3.0. Reading, Mass.: Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5.

A.2 其他參考文獻

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üggemann-Klein
Brüggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Faculty of Mathematics at the University of Freiburg, 1993. (See ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)
Brüggemann-Klein and Wood
Brüggemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages. Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991. Extended abstract in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Lecture Notes in Computer Science 577. Full version titled One-Unambiguous Regular Languages in Information and Computation 140 (2): 229-253, February 1998.
Clark
James Clark. Comparison of SGML and XML. See http://www.w3.org/TR/NOTE-sgml-xml-971215.
IANA-LANGCODES
(Internet Assigned Numbers Authority) Registry of Language Tags, ed. Keld Simonsen et al. (See http://www.isi.edu/in-notes/iana/assignments/languages/.)
IETF RFC2141
IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997.
IETF RFC 2279
IETF (Internet Engineering Task Force). RFC 2279: UTF-8, a transformation format of ISO 10646, ed. F. Yergeau, 1998. (See http://www.ietf.org/rfc/rfc2279.txt.)
IETF RFC 2376
IETF (Internet Engineering Task Force). RFC 2376: XML Media Types. ed. E. Whitehead, M. Murata. 1998. (See http://www.ietf.org/rfc/rfc2376.txt.)
IETF RFC 2396
IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 1998. (See http://www.ietf.org/rfc/rfc2396.txt.)
IETF RFC 2732
IETF (Internet Engineering Task Force). RFC 2732: Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. 1999. (See http://www.ietf.org/rfc/rfc2732.txt.)
IETF RFC 2781
IETF (Internet Engineering Task Force). RFC 2781: UTF-16, an encoding of ISO 10646, ed. P. Hoffman, F. Yergeau. 2000. (See http://www.ietf.org/rfc/rfc2781.txt.)
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 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.
WEBSGML
ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology -- Document Description and Processing Languages. [Geneva]: International Organization for Standardization, 1998. (See http://www.sgmlsource.com/8879rev/n0029.htm.)
XML Names
Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (See http://www.w3.org/TR/REC-xml-names/.)

B. 字符的分類(Character Classes)

根据 Unicode 標准中定義的特征,字符被分為基字符(其中包含了拉丁字母),表意字符和組合字符(其中包含了大多數的變音符)。數字和擴展符(extender)也各自被分成類。

字符
[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 2.0 字符庫中如下導出:

  • 名字的起始字符必須屬于 Ll,Lu,Lo,Lt,Nl 中的一類。
  • 除了起始字符之外的命名字符必須屬于 Mc,Me,Mn,Lm 或 Nd 中的一類。
  • 兼容區(即代碼大于 #xF900,小于 #xFFFE 的字符)中的字符不允許在 XML 名字中出現。
  • 不允許出現具有字集或兼容分解(即,庫中第 5 區有"compatibility formatting tag"的字符 -- "<"標志著 5 區的開始)的字符。
  • 下列字符被當成名字起始字符,因為特性文件中將它們歸于字母類: [#x02BB-#x02C1],#x0559,#x06E5,#x06E6。
  • 不允許出現字符 #x20DD-#x20E0(与 Unicode 2.0 的 5.14 節保持一致)。
  • 字符 #x00B7 被分為擴展符,因為特性文件中對它是這么標識的。
  • 字符 #x0387 被當成一個命名字符,因為 #x00B7 是它的等价規范形式。
  • 字符':'和'_'可以作為名字起始字符。
  • 字符'-'和'.'可以作為命名字符。

C. XML 和 SGML(非正式)

XML 被設計為 SGML 的一個子集,表現在每一個有效的 XML 文件也應該是一個合乎規范的 SGML 文件。對 XML 在 SGML 之外對文件所加的限制的詳細討論參見[Clark]

D. 實体和字符引用的展開(非正式)

本附錄中舉例說明了在 "4.4  XML 處理器對實体和引用的處理"一節中規定的實体和字符引用的識別和展開的次序。

如果聲明包含在 DTD 中

<!ENTITY example "<p>An ampersand (&#38;#38;) may be escaped
numerically (&#38;#38;#38;) or with a general entity
(&amp;amp;).</p>" >

那么 XML 處理器將在對實体聲明進行語法分析時識別出字符引用,并在將下面的字符串存為實体"example"的值前解析這些字符引用:

<p>An ampersand (&#38;) may be escaped
numerically (&#38;#38;) or with a general entity
(&amp;amp;).</p>

文件中對 "&example;" 的引用會導致對文本的重新分析,此時元素 "p" 的起始和結束標簽被識別,三個引用被識別和展開,其結果是一個包含下面內容(所有數据,無定界符或標記)"p" 元素:

An ampersand (&) may be escaped
numerically (&#38;) or with a general entity
(&amp;).

一個更复雜的例子可以完整地說明這些規則和它們的作用。在下面的例子中,行號僅僅是為了方便說明。

1 <?xml version='1.0'?>
2 <!DOCTYPE test [
3 <!ELEMENT test (#PCDATA) >
4 <!ENTITY % xx '&#37;zz;'>
5 <!ENTITY % zz '&#60;!ENTITY tricky "error-prone" >' >
6 %xx;
7 ]>
8 <test>This sample shows a &tricky; method.</test>

這個例子會導致下列動作:

  • 在第 4 行,對字符 37 的引用會被立即展開,參數實体 "xx" 以值 "%zz;" 存于符號表中。因為置換文本不被再次掃描,對參數實体 "zz" 的引用不會被識別。(而且如果它被識別的話則是一個錯誤,因為 "zz" 還沒有被聲明。)
  • 在第 5 行,字符引用 "&#60;" 被立即展開,而參數實体 "zz" 以置換文本 "<!ENTITY tricky "error-prone" >" 被存儲,此置換文本是一個格式正确的實体聲明。
  • 在第 6 行,對 "xx" 的引用被識別,"xx" 的置換文本(即 "%zz;")被分析。對 "zz" 的引用隨后被識別,它的置換文本("<!ENTITY tricky "error-prone" >")被分析。此時普通實体 "tricky" 被聲明,它的置換文本是 "error-prone"。
  • 在第 8 行,對普通實体 "tricky" 的引用被識別,并被展開,因此 "test" 元素的全部內容為一個自說明的(也不合語法)字符串This sample shows a error-prone method.

E. 确定型內容模型(非正式)

3.2.1 元素型內容中所述,元素類型聲明中的內容模型要求是确定型的。這個要求是出于和 SGML 的兼容性考慮(SGML 稱為"無歧義的");用 SGML 系統生成的 XML 處理器可能會把非确定型內容模型標為錯誤。

例如,內容模型((b, c) | (b, d))是非确定型的,因為給定一個初始 b,XML 處理器沒有在向前看以知道 b 后是什么元素之前,無法知道匹配模型中的哪個 b。在這种情況下,兩個對 b 的引用可以簡化成單個的引用,使得模型成為(b,(c | d))。此時初始的 b 只和內容模型中的一個名字明确匹配。處理器不需要向前看其后的內容。cd 都能被接受。

更形式化的說法:使用 Aho,Sethi 和 Ullman 所著 [Aho/Ullman] 3.9 節中的標准算法 3.5,可以從內容模型构造出一個有限狀態自動机。在很多這樣的算法中,對應正則表達式中的每一個位置(即正則表達式的語法樹中的每個葉子節點),都构造一個隨集(follow set);如果任一位置的隨集中不止一個后繼位置被標為同一元素類型時,那么此內容模型出錯,并且可以被報為錯誤。

存在將許多但不是所有非确定型內容模型自動規約為等价的确定型模型的算法;參見 Brggemann-Klein 1991 [Brggemann-Klein].

F. 字符編碼的自動檢測(非正式)

XML 編碼聲明在實体中以內部標簽的方式工作,用于指出使用了何种字符編碼。然而,在 XML 處理器能讀取這個內部標簽前,顯然它必須知道當前使用的是何种字符編碼-而這正是此內部標簽要試圖指出的。通常情況下,這是一种無法解決的情況。但在 XML 中并非如此,因為 XML 在兩個方面對這种情形作出了限制:假定每一种實現只支持一個有限的字符編碼集,并且,為了使得正常情況下自動檢測每個實体中所用字符編碼成為可能,限制了 XML 編碼聲明的位置和內容。同時,很多情況下除了 XML 數据流本身之外,另外還有可用的信息源。根据 XML 實体交給處理器時沒有或有任何的附帶(外部)信息,可以區分出兩种情況。我們先考慮第一种情況。

F.1 無外部編碼信息時的檢測

因為每一個沒有外部編碼信息且非 UTF-8 或 UTF-16 編碼的 XML 實体必須以 XML 編碼聲明開頭,其開始的几個字符必須為 '<?xml',任何合乎規范的處理器可以在兩到四個八位組的輸入后,檢測出适用于下列何种情況。在讀這張表時,知道這些是有幫助的:在 UCS-4 中,'<' 是 "#x0000003C",'?' 是 "#x0000003F",UTF-16 數据流的字節次序標記要求為 "#xFEFF"。記法 ## 用于表示任意的字節值,但兩個連續的 ## 不能同時為 00。

有字節次序標記:

00 00 FE FF UCS-4,big-endian 編碼的計算机(1234次序)
FF FE 00 00 UCS-4,little-endian 編碼的計算机(4321次序)
00 00 FF FE UCS-4,异常的八位組次序(2143)
FE FF 00 00 UCS-4,异常的八位組次序(3412)
FE FF ## ## UTF-16, big-endian
FF FE ## ## UTF-16, little-endian
EF BB BF UTF-8

無字節次序標記:

00 00 00 3C UCS-4 或其他 32 位碼元的編碼,同時 ASCII 字符的碼值就是 ASCII 值,次序分別為 big-endian(1234),little-endian(4321)和兩种异常的字節次序(2143 和 3412)。必須讀取編碼聲明以确定使用的是 或其他被支持的 32 位編碼。
3C 00 00 00
00 00 3C 00
00 3C 00 00
00 3C 00 3F UTF-16BE,big-endian 的 ISO-10646-UCS-2 或其他 16 位碼元的 big-endian 的編碼,其中 ASCII 字符的碼值就是 ASCII (必須讀取編碼聲明以确定使用的是哪一种)
3C 00 3F 00 UTF-16LE,little-endian 的 ISO-10646-UCS-2 或其他 16 位碼元的 little-endian 的編碼,其中 ASCII 字符的碼值就是 ASCII (必須讀取編碼聲明以确定使用的是哪一种)
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,否則不是數据流被標錯了(沒有所需的編碼聲明),被損坏了,是不完整的,就是被包含在某种外層數据中

注:

在上述不需要讀取編碼聲明來确定所用編碼的情況下,4.3.3 節仍然要求讀取可能出現的編碼聲明,并檢查其中的編碼名稱是否与實体實際的編碼相一致。同時,現在不要求有編碼聲明的情況有可能會因為新的字符編碼方案的發明而變得必須使用編碼聲明用于确定所用的編碼。

這种層次的自動檢測足以用于讀取 XML 編碼聲明和分析字符編碼標識符。字符編碼標識符仍然是必須的,它用于區分編碼方案集中的單個成員(例如從 8859 中區分出 UTF-8,8859 各個部分間的相互區分,以及區分所用的特定 EBCDIC 代碼頁,等等)。

因為編碼聲明的內容限于 ASCII 字符集中的字符(不管怎樣編碼),一旦處理器檢測到使用的是哪一個編碼方案集,它能夠可靠地讀取整個編碼聲明。因為在實際中,所有廣泛使用的字符編碼都可以歸于上述种類中,XML 編碼聲明保証了可靠的內嵌(in-band)字符編碼標注,即使是在操作系統或傳輸協議級的外部信息源并不可靠的情況下。象 UTF-7 那樣重用了 ASCII 編碼值的字符編碼方案有可能無法可靠地被檢測。

一旦處理器檢測到所用的字符編碼,它就可以作出合适的動作,或是針對每种情況調用單獨的輸入例程,或是對每個輸入的字符調用版本合适的轉換函數。

和任何自標注(self-labeling)的系統一樣,一旦任何軟件改變了實体的字符集或其編碼而沒有相應修改編碼聲明的話,XML的編碼聲明將無法工作。字符編碼方案的實現者必須小心仔細,以保証用于標注實体的內部和外部信息的正确性。

F.2 外部編碼信息的优先級

第二种可能的情況是 XML 實体有附帶的信息,如在一些文件系統和网絡協議中。當具有多個信息源時,它們間的相對优先級和首選衝突處理方法必須在傳輸 XML 的高層協議中給出。具体請參考 [IETF RFC 2376] 或其后續標准,其中定義了 text/xmlapplication/xml MIME 類型并且提供了一些有用的指導。然而出于互操作性考慮,建議使用下列規則。

  • 如果 XML 實体是在一個文件中,用字節次序標記和編碼聲明 PI(如果有的話)來确定字符編碼。

G. W3C XML 工作組(非正式)

本規范由 W3C XML 工作組(WG)完成并批准發表。工作組批准本規范并不表示所有的工作組成員都一致同意本規范。現有和以前的 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, SoftQuad, Grif SA, Muzmo and Veo Systems
  • MURATA Makoto (FAMILY Given), Fuji Xerox Information Systems
  • Joel Nava, Adobe
  • Conleth O'Connell, Vignette
  • Peter Sharpe, SoftQuad
  • John Tigue, DataChannel

H W3C XML 核心工作組(非正式)

本規范的第二版由 W3C XML 核心工作組完成。在此版本發表時此工作組的成員包括:

  • Paula Angerstein, Vignette
  • Daniel Austin, Ask Jeeves
  • Tim Boland
  • Allen Brown, Microsoft
  • Dan Connolly, W3C (Staff Contact)
  • John Cowan, Reuters Limited
  • John Evdemon, XMLSolutions Corporation
  • Paul Grosso, Arbortext (Co-Chair)
  • Arnaud Le Hors, IBM (Co-Chair)
  • Eve Maler, Sun Microsystems (Second Edition Editor)
  • Jonathan Marsh, Microsoft
  • MURATA Makoto (FAMILY Given), IBM
  • Mark Needleman, Data Research Associates
  • David Orchard, Jamcracker
  • Lew Shannon, NCR
  • Richard Tobin, University of Edinburgh
  • Daniel Veillard, W3C
  • Dan Vint, Lexica
  • Norman Walsh, Sun Microsystems
  • François Yergeau, Alis Technologies (Errata List Editor)
  • Kongyi Zhou, Oracle

I 文檔制作說明(非正式)

第二版用 XMLspec DTD 書寫(見其文檔)。其 HTML 版本用 xmlspec.xsldiffspec.xsl,和 REC-xml-2e.xsl XSLT 樣式表制成。其 PDF 版本使用 html2ps 和一個 distiller 程序制成。

 

 
All contents copyright ? Los Angeles Chinese Learning Center, unless otherwise noted. Website Hosting and Promotion  

Alternative medicine and herbal supplement - Chong's Health Care Inc., formulator of herbal remedy for diabetes, a diabetes alternative medicine, herbal remedy for impotence with penis enlargement effect from animal experiment, and  natural supplements for weight losskidney disease, heart disease, allergy relief, pain relief, eye bags, etc.