Extensible Markup Language (XML) 1.0 (第四版) Extensible Markup Language (XML) 1.0 (Fourth Edition)

1.1 始まりと目標 Origin and Goals

XMLの発展は、1996年にWorld Wide Web Consortium(W3C)の援助の下発足したSGML Editorial Review Board──後のXML Working Groupの手によるものである。XML Working Groupの議長はSun MicrosystemsのJon Bosakが務めた。XML Working Groupの活動には、同じくW3Cで組織されたSGML Working Group──現在のXML Special Interest Groupが積極的に参加してくれた。XML Working Groupのメンバは附録に載せておく。XML Working GroupとW3Cとの連絡はDan Connollyが取り持った。

XML was developed by an XML Working Group (originally known as the SGML Editorial Review Board) formed under the auspices of the World Wide Web Consortium (W3C) in 1996. It was chaired by Jon Bosak of Sun Microsystems with the active participation of an XML Special Interest Group (previously known as the SGML Working Group) also organized by the W3C. The membership of the XML Working Group is given in an appendix. Dan Connolly served as the Working Group's contact with the W3C.

XMLの設計目標は次の通り。

The design goals for XML are:

1. XMLが、インターネットのどこでもそのまま使える事。

   XML shall be straightforwardly usable over the Internet.

2. XMLが多岐に渡るアプリケーションの役に立つ事。

   XML shall support a wide variety of applications.

3. XMLがSGMLと互換性を持っている事。

   XML shall be compatible with SGML.

4. XML文書を処理するプログラムを書く事が簡単である事。

   It shall be easy to write programs which process XML documents.

5. XMLの、実装によってばらつきが出るような機能が限りなく少なく保たれる事……理想を言えば、そんな機能が全く無い事。

   The number of optional features in XML is to be kept to the absolute minimum, ideally zero.

6. XML文書が、できれば人間にも読みやすく、道理に適ってすっきりしている事。

   XML documents should be human-legible and reasonably clear.

7. XMLの設計が、できれば素早く用意される事。

   The XML design should be prepared quickly.

8. XMLの設計が、きちんとした形式でありながら同時に簡潔である事。

   The design of XML shall be formal and concise.

9. XML文書を作る事が簡単である事。

   XML documents shall be easy to create.

10. XMLのマークアップにおいては、(厳密さに比べて)簡潔さは全然重要でない事。

    Terseness in XML markup is of minimal importance.

この仕様書には、関連する標準規格(文字に関してはUnicode [Unicode]とISO/IEC 10646 [ISO/IEC 10646]、言語識別タグに関してはInternet RFC 3066 [IETF RFC 3066]、言語コードについてはISO 639 [ISO 639]、そして国コードについてはISO 3166 [ISO 3166])と共に読む事で、XML バージョン1.0を理解し、それを処理する事のできるコンピュータプログラムを構築する為に必要なすべての情報が書かれている。

This specification, together with associated standards (Unicode [Unicode] and ISO/IEC 10646 [ISO/IEC 10646] for characters, Internet RFC 3066 [IETF RFC 3066] for language identification tags, ISO 639 [ISO 639] for language name codes, and ISO 3166 [ISO 3166] for country name codes), provides all the information necessary to understand XML Version 1.0 and construct computer programs to process it.

このバージョンのXML仕様書は、テキスト及び法律上の注意事項のすべてをそのままにするならば、自由に配付して良い。

This version of the XML specification may be distributed freely, as long as all text and legal notices remain intact.

1.2 専門用語 Terminology

XML文書を記述する際に使われる用語については、この仕様書の本文で定義する。キーワードMUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、そしてOPTIONALが強調されて使われた場合、それらは[IETF RFC 2119]で説明されている意味で使われているものとする。加えて、次に挙げるリストで定義される用語は、本文中の用語の定義や、XMLプロセッサの動作の記述に使われる。

The terminology used to describe XML documents is defined in the body of this specification. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when EMPHASIZED, are to be interpreted as described in [IETF RFC 2119]. In addition, the terms defined in the following list are used in building those definitions and in describing the actions of an XML processor:

エラー error

[定義: この仕様書で定められる規則に対する違反。その結果は定義されない。特別な記述が無い限り、この仕様書で、しなければならない(MUST)、必須とされる(REQUIRED)、してはならない(MUST NOT)、すべきである(SHALL)、すべきでない(SHALL NOT)とされている規定を遵守しないものはエラーである。仕様に適合するソフトウェアは、エラーを検知してアプリケーションに報告しても良い(MAY)し、エラーを修復してその状態から復帰しても良い(MAY)。

[Definition: A violation of the rules of this specification; results are undefined. Unless otherwise specified, failure to observe a prescription of this specification indicated by one of the keywords MUST, REQUIRED, MUST NOT, SHALL and SHALL NOT is an error. Conforming software MAY detect and report an error and MAY recover from it.]

致命的エラー fatal error

[定義: 仕様に適合するXMLプロセッサが検知し、アプリケーションに報告しなければならない(MUST)エラー。XMLプロセッサは、一つめの致命的エラーに出くわした後、更なるエラーを探す為に処理を続けても良い(MAY)し、アプリケーションにそれらのエラーを報告しても良い(MAY)。XMLプロセッサは、エラーの訂正を支援する為、文書の処理しなかったデータを(文字データとマークアップとに分けたものと共に)アプリケーションに渡しても良い(MAY)。しかし、一度致命的エラーを検知したならば、XMLプロセッサは通常の処理を続けてはならない(MUST NOT)。即ち、通常のやり方で、文字データや文書の論理構造に関する情報をアプリケーションに渡す事を続けてはならない(MUST NOT)。]

[Definition: An error which a conforming XML processor MUST detect and report to the application. After encountering a fatal error, the processor MAY continue processing the data to search for further errors and MAY report such errors to the application. In order to support correction of errors, the processor MAY make unprocessed data from the document (with intermingled character data and markup) available to the application. Once a fatal error is detected, however, the processor MUST NOT continue normal processing (i.e., it MUST NOT continue to pass character data and information about the document's logical structure to the application in the normal way).]

ユーザが選択した場合 at user option

[定義: 仕様に適合するソフトウェアは、そこで説明されているような動作をしても良い(MAY)、あるいはしなければならない(MUST)(文章で使われている法の助動詞に依る)。そのような動作をする場合は、ユーザにその動作の有効・無効を選択する手段を提供しなければならない(MUST)。]

[Definition: Conforming software MAY or MUST (depending on the modal verb in the sentence) behave as described; if it does, it MUST provide users a means to enable or disable the behavior described.]

妥当性制約 validity constraint

[定義: すべての妥当なXML文書に適用される規則。妥当性制約に対する違反はエラーである。妥当性を検証するXMLプロセッサは、ユーザが選択した場合、それらのエラーを報告しなければならない(MUST)。]

[Definition: A rule which applies to all valid XML documents. Violations of validity constraints are errors; they MUST, at user option, be reported by validating XML processors.]

整形式性制約 well-formedness constraint

[定義: すべての整形式なXML文書に適用される規則。整形式性制約に対する違反は致命的エラーである。]

[Definition: A rule which applies to all well-formed XML documents. Violations of well-formedness constraints are fatal errors.]

マッチする match

[定義: (文字列や名前がマッチする:) 比較対象の二つの文字列、あるいは比較対象の二つの名前があらゆる点で一致する。ISO/IEC 10646において複数の表現方法がある文字(例えば、最初から組み合わさっている形式(合成済み形式)と、元となる文字(基底文字)に発音区別符号を組み合わせる形式がある文字)は、両方の文字列で同じ表現方法が使われている時にのみマッチする。ケースフォールディングは行われない。(文字列と文法規則がマッチする:) 文字列が、生成規則によって生成される言語(生成規則によって課される制約を満たすあらゆる文字列の集合)に属する時、文字列は生成規則にマッチする。(内容と内容モデルがマッチする:) [妥当性制約: 妥当な要素]を満たす時、要素はその宣言にマッチする。]

[Definition: (Of strings or names:) Two strings or names being compared are identical. Characters with multiple possible representations in ISO/IEC 10646 (e.g. characters with both precomposed and base+diacritic forms) match only if they have the same representation in both strings. No case folding is performed. (Of strings and rules in the grammar:) A string matches a grammatical production if it belongs to the language generated by that production. (Of content and content models:) An element matches its declaration when it conforms in the fashion described in the constraint [VC: Element Valid].]

[訳者註開始]

訳者註

ケースフォールディング(Case Folding)とは、(この仕様書の原文では明示されていませんが)UnicodeにおけるCase Foldingの事でしょう。ケースフォールディングは、ケース間の、大抵の場合は大文字小文字の間の差異を無視する操作の事です。例えば、ラテン文字の大文字はラテン文字の小文字に変換されるので、ケースフォールディングを行う場合は、MathとmAthは両方ともmathになるので一致します。完全ケースフォールディングをする場合、ドイツ語のアルファベットの一つ、エスツェット('ß')はラテン文字の小文字のエス二つ('ss')に変換されるので、daßとdassは両方ともdassになって一致します。

XMLで文字列や名前がマッチするかどうかを判定する時にはケースフォールディングが行われない事に気を付けて下さい。なお、ケースフォールディングで変換される文字のリストはCaseFolding.txtで得られます。

[訳者註終了]

互換性の為に for compatibility

[定義: XMLがSGMLと互換性を持つようにする為だけに付け加えられたXMLの機能を説明する文章に付く句。]

[Definition: Marks a sentence describing a feature of XML included solely to ensure that XML remains compatible with SGML.]

相互運用性の為に for interoperability

[定義: XML文書が、ISO 8879に対するWebSGML Adaptions Annexが出される前に作られたSGMLプロセッサでも処理できる機会を増やす為に付け加えられた、拘束力を持たない推奨事項を説明する文章に付く句。]

[Definition: Marks a sentence describing a non-binding recommendation included to increase the chances that XML documents can be processed by the existing installed base of SGML processors which predate the WebSGML Adaptations Annex to ISO 8879.]

2.1 整形式のXML文書 Well-Formed XML Documents

[Definition: 次に挙げる条件をすべて満たす時、テキストオブジェクトは整形式XML文書となる。]

[Definition: A textual object is a well-formed XML document if:]

1. 全体として、document生成規則にマッチする。

   Taken as a whole, it matches the production labeled document.

2. この仕様書が定めるすべての整形式性制約を満たす。

   It meets all the well-formedness constraints given in this specification.

3. 文書中で直接的あるいは間接的に参照されるすべての解析対象実体がそれぞれ整形式である。

   Each of the parsed entities which is referenced directly or indirectly within the document is well-formed.

文書 Document

document生成規則にマッチする事は、次の事をも暗に意味する。

Matching the document production implies that:

1. 一つ以上の要素を含む。

   It contains one or more elements.

2. [定義: ルート、あるいは文書要素と呼ばれる要素がただ一つのみ存在する。ルート要素は、自身の一部あるいは全部が他の要素の内容となる事が一切無い。] ルート要素以外のすべての要素は、その開始タグが他の要素の内容に含まれた時、その終了タグも同じ要素の内容に含まれる。もっと簡単に言えば、要素は開始タグと終了タグでその範囲が定められ、そして互いに適切にネストする。

   [Definition: There is exactly one element, called the root, or document element, no part of which appears in the content of any other element.] For all other elements, if the start-tag is in the content of another element, the end-tag is in the content of the same element. More simply stated, the elements, delimited by start- and end-tags, nest properly within each other.

[定義: この結果、文書中に存在する非ルート要素Cそれぞれについて、他の要素Pが存在すると考えられる。Cが、Pの内容に含まれるが、Pの内容に含まれる他のすべての要素の内容には含まれない時、PはCの親と、CはPの子と呼ばれる。]

[Definition: As a consequence of this, for each non-root element C in the document, there is one other element P in the document such that C is in the content of P, but is not in the content of any other element that is in the content of P. P is referred to as the parent of C, and C as a child of P.]

2.2 文字 Characters

[定義: 解析対象実体はテキスト、即ち一連の文字を含む。テキストはマークアップか文字データを表す。] [定義: 文字は、ISO/IEC 10646:2000 [ISO/IEC 10646]で定義されている、テキストを構成する最小単位である。使用が認められる文字は、タブ、キャリッジリターン、ラインフィード、及びUnicodeとISO/IEC 10646で使用を認められている文字である。A.1 規範的な参考文献 Normative Referencesで引用されているこれらの標準規格のバージョンは、この文書が用意された時点で最新のものである。これらの規格には、修正や改版によって、新たな文字が追加される事があるかも知れない。よって、XMLプロセッサはCharで指定される範囲に含まれるすべての文字を受け容れなければならない(MUST)。]

[Definition: A parsed entity contains text, a sequence of characters, which may represent markup or character data.] [Definition: A character is an atomic unit of text as specified by ISO/IEC 10646:2000 [ISO/IEC 10646]. Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646. The versions of these standards cited in A.1 Normative References were current at the time this document was prepared. New characters may be added to these standards by amendments or new editions. Consequently, XML processors MUST accept any character in the range specified for Char.]

文字の範囲 Character Range

文字コード点をビットパターンにエンコードする機構は、実体によって異なっていても良い。すべてのXMLプロセッサは、Unicode 3.1 [Unicode3]のUTF-8エンコーディングとUTF-16エンコーディングを受け容れなければならない(MUST)。二つのエンコーディングのどちらが使われているかを知らせる機構や、他のエンコーディングを使う為の機構については、4.3.3 実体で使われる文字エンコーディング Character Encoding in Entitiesで取り扱う。

The mechanism for encoding character code points into bit patterns may vary from entity to entity. All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode 3.1 [Unicode3]; the mechanisms for signaling which of the two is in use, or for bringing other encodings into play, are discussed later, in 4.3.3 Character Encoding in Entities.

[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF],
[#x1FFFE-#x1FFFF], [#x2FFFE-#x2FFFF], [#x3FFFE-#x3FFFF],
[#x4FFFE-#x4FFFF], [#x5FFFE-#x5FFFF], [#x6FFFE-#x6FFFF],
[#x7FFFE-#x7FFFF], [#x8FFFE-#x8FFFF], [#x9FFFE-#x9FFFF],
[#xAFFFE-#xAFFFF], [#xBFFFE-#xBFFFF], [#xCFFFE-#xCFFFF],
[#xDFFFE-#xDFFFF], [#xEFFFE-#xEFFFF], [#xFFFFE-#xFFFFF],
[#x10FFFE-#x10FFFF].

2.3 一般的な構文構成子 Common Syntactic Constructs

このセクションでは、XMLの文法で広く使われるシンボルを定義する。

This section defines some symbols used widely in the grammar.

S(ホワイトスペース)は、一つ以上のスペース文字(#x20)、キャリッジリターン、ラインフィード、タブから成る。

S (white space) consists of one or more space (#x20) characters, carriage returns, line feeds, or tabs.

ホワイトスペース White Space

簡便の為に、文字は、レター、算用数字やその他の文字に分類される。レターは、アルファベットや表音基底文字、それに表意文字の事である。それぞれのクラスに含まれる文字の完全な定義はB 文字クラス Character Classesで与えられる。

Characters are classified for convenience as letters, digits, or other characters. A letter consists of an alphabetic or syllabic base character or an ideographic character. Full definitions of the specific characters in each class are given in B Character Classes.

[定義: Name(名前)は、レター一つあるいは限られた種類の句読点一つから始まり、複数のレター、数字、ハイフン、アンダースコア、コロン、終止符が続くトークンである。これらの文字は名前文字として知られる。] 文字列"xml"から始まる名前や、(('X'|'x')('M'|'m')('L'|'l'))にマッチする文字列から始まる名前は、この仕様書のこのバージョン及び将来のバージョンにおける標準化の為に予約されている。

[Definition: A Name is a token beginning with a letter or one of a few punctuation characters, and continuing with letters, digits, hyphens, underscores, colons, or full stops, together known as name characters.] Names beginning with the string "xml", or with any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or future versions of this specification.

Nmtoken(名前トークン)は名前文字を任意に組み合わせたものである。

An Nmtoken (name token) is any mixture of name characters.

名前とトークン Names and Tokens

リテラルデータは、引用符で括られた文字列である。但し、文字列の区切り子として使われている引用符をその中に含む事はできない。リテラルは内部エンティティの内容(EntityValue)や、属性の値(AttValue)、外部識別子(SystemLiteral)を指定する為に使われる。SystemLiteralはマークアップを走査せずに解析され得る事に注意してほしい。

Literal data is any quoted string not containing the quotation mark used as a delimiter for that string. Literals are used for specifying the content of internal entities (EntityValue), the values of attributes (AttValue), and external identifiers (SystemLiteral). Note that a SystemLiteral can be parsed without scanning for markup.

リテラル Literals

2.4 文字データとマークアップ Character Data and Markup

テキストは文字データとマークアップを混ぜ合わせたものから成る。 [定義: マークアップは、次のような形態を採る。開始タグ、終了タグ、空要素タグ、実体参照、文字参照、コメント、CDATAセクション区切り子、文書型宣言、処理命令、XML宣言、テキスト宣言、そして文書実体の最上層(つまり、文書要素の外かつ他のすべてのマークアップに含まれない場所)にあるホワイトスペース。]

Text consists of intermingled character data and markup. [Definition: Markup takes the form of start-tags, end-tags, empty-element tags, entity references, character references, comments, CDATA section delimiters, document type declarations, processing instructions, XML declarations, text declarations, and any white space that is at the top level of the document entity (that is, outside the document element and not inside any other markup).]

[定義: マークアップでないすべてのテキストは文書の文字データを成す。]

[Definition: All text that is not markup constitutes the character data of the document.]

アンパサンド文字(&)と左山括弧(<)は、マークアップ区切り子として使われる場合、あるいはコメント、処理命令、CDATAセクションの中に現れる場合を除き、直接現れてはならない(MUST NOT)。もしそれらの文字を他の場所で使わなければならない場合は、数値による文字参照を使うか、それぞれ文字列"&"と"<"を使うかしてエスケープしなければならない(MUST)。右山括弧(>)は、通常はそうする必要は無いが、文字列">"で表しても良い。但し、文字列"]]>"がCDATAセクションの終わりを意味する為に現れたのでなければ、互換性の為に、その文字列の中に現れる右山括弧を">"か文字参照を使ってエスケープしなければならない(MUST)。

The ampersand character (&) and the left angle bracket (<) MUST NOT appear in their literal form, except when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. If they are needed elsewhere, they MUST be escaped using either numeric character references or the strings "&" and "<" respectively. The right angle bracket (>) may be represented using the string ">", and MUST, for compatibility, be escaped using either ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section.

要素の内容では、文字データは、あらゆる種類のマークアップの開始区切り子やCDATAセクション終了区切り子("]]>")を含まない、ありとあらゆる文字列である。CDATAセクションでは、文字データは、CDATAセクション終了区切り子("]]>")を含まない、ありとあらゆる文字列である。

In the content of elements, character data is any string of characters which does not contain the start-delimiter of any markup and does not include the CDATA-section-close delimiter, "]]>". In a CDATA section, character data is any string of characters not including the CDATA-section-close delimiter, "]]>".

属性値に単引用符と二重引用符を両方含ませる為に、アポストロフィあるいは単引用符(')を"'"で、二重引用符(")を"""で表す事がよくある。

To allow attribute values to contain both single and double quotes, the apostrophe or single-quote character (') may be represented as "'", and the double-quote character (") as """.

文字データ Character Data

2.5 コメント Comments

[定義: コメントは、他のマークアップの外になら、どこに現れても良い。加えて、文書型宣言の中にも、文法が許す場所になら現れて良い。コメントは文書の文字データの一部ではない。故に、XMLプロセッサはコメントに含まれるテキストをアプリケーションが受け取れるようにしても良い(MAY)が、必ずしもそうする必要は無い。互換性の為に、文字列"--"(二つのハイフン)はコメントの中に現れてはならない(MUST NOT)。] コメントの中では、パラメータ実体参照を認識してはならない(MUST NOT)。

[Definition: Comments may appear anywhere in a document outside other markup; in addition, they may appear within the document type declaration at places allowed by the grammar. They are not part of the document's character data; an XML processor MAY, but need not, make it possible for an application to retrieve the text of comments. For compatibility, the string "--" (double-hyphen) MUST NOT occur within comments.] Parameter entity references MUST NOT be recognized within comments.

コメント Comments

コメントの一例を挙げる。

An example of a comment:

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

--->で終わるコメントは文法的に許されない事に注意してほしい。次の例は整形式ではない。

Note that the grammar does not allow a comment ending in --->. The following example is not well-formed.

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

2.6 処理命令 Processing Instructions

[定義: 処理命令(PIと略される事もある)は、文書中にアプリケーションへの命令を記述するものである。]

[Definition: Processing instructions (PIs) allow documents to contain instructions for applications.]

処理命令 Processing Instructions

処理命令は文書の文字データの一部ではないが、アプリケーションに渡されなければならない(MUST)。処理命令は、命令を与えるアプリケーションを識別する為に使われる対象(PITarget)から始まる。"XML"や"xml"などの対象名は、この仕様書のこのバージョン及び将来のバージョンにおける標準化の為に予約されている。処理命令対象の正式な宣言の為に、XML記法機構が使われる事もある。処理命令の中では、パラメータ実体参照を認識してはならない(MUST NOT)。

PIs are not part of the document's character data, but MUST be passed through to the application. The PI begins with a target (PITarget) used to identify the application to which the instruction is directed. The target names "XML", "xml", and so on are reserved for standardization in this or future versions of this specification. The XML Notation mechanism may be used for formal declaration of PI targets. Parameter entity references MUST NOT be recognized within processing instructions.

2.7 CDATAセクション CDATA Sections

[定義: CDATAセクションは、文字データが現れて良い所なら、どこに現れても良い。CDATAセクションは、そのままではマークアップと認識されてしまう文字を含むテキストをエスケープする為に使われる。CDATAセクションは文字列"<![CDATA["から始まり、文字列"]]>"で終わる。]

[Definition: CDATA sections may occur anywhere character data may occur; they are used to escape blocks of text containing characters which would otherwise be recognized as markup. CDATA sections begin with the string "<![CDATA[" and end with the string "]]>":]

CDATAセクション CDATA Sections

CDATAセクションの中では、CDEnd文字列だけが唯一マークアップとして認識される。この為、左山括弧とアンパサンドは直接現れて良い。つまり、"<"や"&"などとエスケープされなくて良いし、される事もできない。CDATAセクションはネストできない。

Within a CDATA section, only the CDEnd string is recognized as markup, so that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using "<" and "&". CDATA sections cannot nest.

CDATAセクションの一例を挙げる。ここでは"<greeting>"と"</greeting>"は、マークアップではなく文字データであると認識される。

An example of a CDATA section, in which "<greeting>" and "</greeting>" are recognized as character data, not markup:

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

2.8 プロローグと文書型宣言 Prolog and Document Type Declaration

[Definition: XML文書は、使われるXMLのバージョンを指定するXML宣言から始まる事が望ましい(SHOULD)。] 例えば、次に挙げるのは完全なXML文書である。これは整形式であるが妥当ではない。

[Definition: XML documents SHOULD begin with an XML declaration which specifies the version of XML being used.] For example, the following is a complete XML document, well-formed but not valid:

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

次も同様である。

and so is this:

<greeting>Hello, world!</greeting>

XML文書におけるマークアップの役割は、記録の構造と論理構造を記述し、属性の名前と値のペアを論理構造に関連付ける事である。XMLは、論理構造に制約を課し、定義済みの記録単位の使用を助ける機構である文書型宣言を提供する。 [定義: XML文書は、関連付けられる文書型宣言を持ち、かつその文書型が課す制約に従う時、妥当となる。]

The function of the markup in an XML document is to describe its storage and logical structure and to associate attribute name-value pairs with its logical structures. XML provides a mechanism, the document type declaration, to define constraints on the logical structure and to support the use of predefined storage units. [Definition: An XML document is valid if it has an associated document type declaration and if the document complies with the constraints expressed in it.]

文書型宣言は、文書中で最初に現れる要素よりも前に現れなければならない(MUST)。

The document type declaration MUST appear before the first element in the document.

プロローグ Prolog

[定義: XML文書型宣言は、文書のクラスの文法を提供するマークアップ宣言を、含むか指すかする。この文法は、DTD(文書型定義)として知られる。文書型宣言は、マークアップ宣言を含む外部サブセット(特別な種類の外部実体)を指しても良いし、内部サブセットの中に直接マークアップ宣言を含んでも良いし、その両方をやっても良い。文書が使うDTDは、それらのサブセットを両方併せたものとなる。]

[Definition: The XML document type declaration contains or points to markup declarations that provide a grammar for a class of documents. This grammar is known as a document type definition, or DTD. The document type declaration can point to an external subset (a special kind of external entity) containing markup declarations, or can contain the markup declarations directly in an internal subset, or can do both. The DTD for a document consists of both subsets taken together.]

[定義: マークアップ宣言は、要素型宣言、属性リスト宣言、実体宣言、記法宣言の何れかである。] これらの宣言は、この後で述べる整形式性制約や妥当性制約で説明されているように、宣言の一部あるいは全部がパラメータ実体に含まれても良い。更なる情報は、4 物理構造 Physical Structuresで確認してほしい。

[Definition: A markup declaration is an element type declaration, an attribute-list declaration, an entity declaration, or a notation declaration.] These declarations may be contained in whole or in part within parameter entities, as described in the well-formedness and validity constraints below. For further information, see 4 Physical Structures.

文書型定義 Document Type Definition

外部サブセットを指さず、内部サブセットも含まないdoctypedeclを含む整形式の文書を作る事も可能である事に注意してほしい。

Note that it is possible to construct a well-formed document containing a doctypedecl that neither points to an external subset nor contains an internal subset.

マークアップ宣言は、一部あるいは全部がパラメータ実体の置換テキストから作られても良い。この仕様書の後の方にある、各非終端シンボル(elementdeclやAttlistDeclなど)の生成規則は、すべてのパラメータ実体がインクルードされた後の定義を記述する。

The markup declarations may be made up in whole or in part of the replacement text of parameter entities. The productions later in this specification for individual nonterminals (elementdecl, AttlistDecl, and so on) describe the declarations after all the parameter entities have been included.

パラメータ実体参照は、DTD(内部及び外部サブセットと外部パラメータ実体)の中ならどこでも認識されるが、リテラル、処理命令、コメント、及び無視される条件付きセクション(3.4 条件付きセクション Conditional Sections参照)の中は例外である。実体値リテラルの中でも認識される。内部サブセットでのパラメータ実体の使用は、以下で説明されるように、制限される。

Parameter entity references are recognized anywhere in the DTD (internal and external subsets and external parameter entities), except in literals, processing instructions, comments, and the contents of ignored conditional sections (see 3.4 Conditional Sections). They are also recognized in entity value literals. The use of parameter entities in the internal subset is restricted as described below.

内部サブセットと同様、外部サブセットやDeclSepで参照される外部パラメータ実体は、一連の完全なマークアップ宣言から成らなければならない(MUST)。マークアップ宣言の間にはホワイトスペースやパラメータ実体参照を交える事があるが、その宣言の種類は、非終端シンボルmarkupdeclで許されているものでなければならない(MUST)。但し、外部サブセットの内容の一部や参照される外部パラメータ実体の内容の一部が、条件付きセクション構成子を使う事で条件に応じて無視される事はあっても良い。これは、内部サブセットでは使用する事ができないが、内部サブセットが参照する外部パラメータ実体では使用する事ができる。

Like the internal subset, the external subset and any external parameter entities referenced in a DeclSep MUST consist of a series of complete markup declarations of the types allowed by the non-terminal symbol markupdecl, interspersed with white space or parameter-entity references. However, portions of the contents of the external subset or of these external parameter entities may conditionally be ignored by using the conditional section construct; this is not allowed in the internal subset but is allowed in external parameter entities referenced in the internal subset.

外部サブセット External Subset

外部サブセットと外部パラメータ実体は、パラメータ実体参照が、マークアップ宣言の間だけではなくマークアップ宣言の中でも許されるという点においても、内部サブセットと異なる。

The external subset and external parameter entities also differ from the internal subset in that in them, parameter-entity references are permitted within markup declarations, not only between markup declarations.

文書型宣言を持つXML文書の一例を挙げる。

An example of an XML document with a document type declaration:

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

システム識別子"hello.dtd"は、文書に関連付けられるDTDのアドレスをURI参照で与える。

The system identifier "hello.dtd" gives the address (a URI reference) of a DTD for the document.

文書型宣言は局所的に与えられても良い。例えば次のようにである。

The declarations can also be given locally, as in this example:

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

外部サブセットと内部サブセットが両方使われた場合、内部サブセットは外部サブセットの前に現れると見なされなければならない(MUST)。これは、内部サブセットに現れる実体宣言や属性リスト宣言が、外部サブセットに現れるものよりも高い優先度を持つという事である。

If both the external and internal subsets are used, the internal subset MUST be considered to occur before the external subset. This has the effect that entity and attribute-list declarations in the internal subset take precedence over those in the external subset.

2.9 スタンドアローン文書宣言 Standalone Document Declaration

XMLプロセッサからアプリケーションに渡される過程で、マークアップ宣言は文書の内容に影響する事がある。例えば、属性デフォルトや実体宣言などがその例である。スタンドアローン文書宣言はXML宣言の構成要素として現れる事があり、文書実体の外や、パラメータ実体の中に、文書の内容に影響するような宣言があるかどうかを知らせる。 [定義: 外部マークアップ宣言は、外部サブセットの中、あるいはパラメータ実体の中に現れるマークアップ宣言の事である(このパラメータ実体は、外部パラメータ実体と内部パラメータ実体の両方である。内部パラメータ実体のマークアップ宣言が外部マークアップ宣言に含まれるのは、妥当性を検証しないプロセッサは内部パラメータ実体を読む事を必要とされないからである)。]

Markup declarations can affect the content of the document, as passed from an XML processor to an application; examples are attribute defaults and entity declarations. The standalone document declaration, which may appear as a component of the XML declaration, signals whether or not there are such declarations which appear external to the document entity or in parameter entities. [Definition: An external markup declaration is defined as a markup declaration occurring in the external subset or in a parameter entity (external or internal, the latter being included because non-validating processors are not required to read them).]

スタンドアローン文書宣言 Standalone Document Declaration

スタンドアローン文書宣言では、値"yes"は、XMLプロセッサからアプリケーションに渡される情報に影響する外部マークアップ宣言が存在しない事を示す。値"no"は、そのような外部マークアップ宣言が存在する事、あるいは存在するであろう事を示す。注意してほしいのは、スタンドアローン文書宣言は外部宣言の存在を示すものでしかないという事である。つまり、文書中に外部実体への参照があっても、それらの実体が内部で宣言されているならば、その外部実体への参照の存在は、文書がスタンドアローンであるかどうかという点には変更を来さない。

In a standalone document declaration, the value "yes" indicates that there are no external markup declarations which affect the information passed from the XML processor to the application. The value "no" indicates that there are or may be such external markup declarations. Note that the standalone document declaration only denotes the presence of external declarations; the presence, in a document, of references to external entities, when those entities are internally declared, does not change its standalone status.

外部マークアップ宣言が一切無ければ、スタンドアローン文書宣言は何ら意味を持たない。外部マークアップ宣言はあるもののスタンドアローン文書宣言が無い時は、値"no"が指定されたものと見なされる。

If there are no external markup declarations, the standalone document declaration has no meaning. If there are external markup declarations but there is no standalone document declaration, the value "no" is assumed.

standalone="no"が適用されているXML文書は、どんな文書であっても、アルゴリズムに従ってスタンドアローン文書に変換する事ができる。ある種のネットワーク転送アプリケーションにとっては、この事は望ましい事であるかも知れない。

Any XML document for which standalone="no" holds can be converted algorithmically to a standalone document, which may be desirable for some network delivery applications.

スタンドアローン文書宣言を持つXML宣言の一例を挙げる。

An example XML declaration with a standalone document declaration:

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

2.10 ホワイトスペースの取り扱い White Space Handling

XML文書を編集する際、より可読性を高める為に「ホワイトスペース」(スペース、タブ、空行など)を使ってマークアップを分離すると便利になる事が多い。そのようなホワイトスペースは、大抵の場合、ユーザの下に届けられる文書の形態でも含まれる事は意図していない。一方で、ユーザの元に届けられる形態でも保たれるべき「有意な」ホワイトスペースもよくある。例えば、詩やソースコードに含まれるホワイトスペースがそれである。

In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, "significant" white space that should be preserved in the delivered version is common, for example in poetry and source code.

XMLプロセッサは、マークアップでない文字はすべてアプリケーションに渡さなければならない(MUST)。妥当性を検証するXMLプロセッサは、それらの文字の内、どれが要素内容に現れるホワイトスペースを成すのかという事もアプリケーションに伝えなければならない(MUST)。

An XML processor MUST always pass all characters in a document that are not markup through to the application. A validating XML processor MUST also inform the application which of these characters constitute white space appearing in element content.

xml:spaceという名前の特別な属性を、その要素ではホワイトスペースが保たれなければならないという意図をアプリケーションに伝える為に、要素に付けても良い。妥当な文書では、この属性は──他のすべての属性と同じように──使われる場合には宣言されなければならない(MUST)。宣言される場合は、その属性は、"default"か"preserve"の何れかを値に持つ、あるいはその両方を値に持つ列挙型として定義されなければならない(MUST)。例えば、次のようにである。

A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, MUST be declared if it is used. When declared, it MUST be given as an enumerated type whose values are one or both of "default" and "preserve". For example:

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

値"default"は、その要素については、アプリケーションデフォルトのホワイトスペース処理モードが使用可能である事を意味する。値"preserve"は、アプリケーションがすべてのホワイトスペースを保たなければならない意図がある事を示す。この定義の意図は、他のxml:spaceのインスタンスが上書きしない限り、xml:space属性が指定された要素の内容に含まれる要素すべてに適用されるという事である。この仕様書は、xml:spaceの値で"default"と"preserve"以外のものについては、その意味を与えない。その他の値が指定される事はエラーである。XMLプロセッサは、そのエラーをアプリケーションに報告しても良い(MAY)し、その属性の指定を無視する事で、あるいはエラーを引き起こした値をアプリケーションに報告する事でエラーから回復しても良い(MAY)。アプリケーションは、エラーを引き起こした値を無視しても良いし、拒絶しても良い。

The value "default" signals that applications' default white-space processing modes are acceptable for this element; the value "preserve" indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space attribute. This specification does not give meaning to any value of xml:space other than "default" and "preserve". It is an error for other values to be specified; the XML processor MAY report the error or MAY recover by ignoring the attribute specification or by reporting the (erroneous) value to the application. Applications may ignore or reject erroneous values.

あらゆる文書のルート要素は、そのルート要素がこの属性に値を指定したり、この属性がデフォルト値を持つように定義されたりしていない限りは、アプリケーションがホワイトスペースを取り扱う方法について何ら意図を伝えないものと見なされる。

The root element of any document is considered to have signaled no intentions as regards application space handling, unless it provides a value for this attribute or the attribute is declared with a default value.

2.11 行末の取り扱い End-of-Line Handling

XMLの解析対象実体はしばしば、編集の簡便の為に複数行に渡って書かれるコンピュータファイルに格納される。これらの行は一般に、CARRIAGE RETURN(#xD)とLINE FEED(#xA)の組み合わせで分けられる。

XML parsed entities are often stored in computer files which, for editing convenience, are organized into lines. These lines are typically separated by some combination of the characters CARRIAGE RETURN (#xD) and LINE FEED (#xA).

アプリケーションの仕事を簡単にする為に、XMLプロセッサは、あたかも、入力から得られた外部解析対象実体(文書実体も含む)の改行を、解析を始める前に正規化したかのように動作しなければならない(MUST)。この時、連続する二文字#xD #xAと、#xAが後続しない一文字#xDの両方を、一つの#xA文字に変換したかのように動作しなければならない(MUST)。

To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character.

2.12 言語識別 Language Identification

文書を処理する際、その内容がどの自然言語あるいは形式言語で書かれているかを識別すると便利になる事がしばしばある。そこで、xml:langという名前の特別な属性を、XML文書の中の要素の内容や属性値で使われている言語を指定する為に、文書中に挿入しても良い。妥当な文書では、この属性は──他のすべての属性と同じように──使われる場合には宣言されなければならない(MUST)。この属性の値は、Tags for the Identification of Languages [IETF RFC 3066]、及びその後継文書で定義される言語識別子である。空の文字列を指定しても良い。

In document processing, it is often useful to identify the natural or formal language in which the content is written. A special attribute named xml:lang may be inserted in documents to specify the language used in the contents and attribute values of any element in an XML document. In valid documents, this attribute, like any other, MUST be declared if it is used. The values of the attribute are language identifiers as defined by [IETF RFC 3066], Tags for the Identification of Languages, or its successor; in addition, the empty string may be specified.

(生成規則33から38までは削除された。)

(Productions 33 through 38 have been removed.)

xml:langを使った例を挙げる。

For example:

<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ßem Bemüh'n.</l>
</sp>

xml:langで指定された言語は、その属性が指定された要素とその要素の属性値に適用される。加えて、他のxml:langのインスタンスが上書きしない限り、その属性が指定された要素の内容に含まれるすべての要素にも適用される。特に、要素Bを内包する要素Aのxml:langの指定を上書きする為に、要素Bでxml:langに空の値が(他の言語を指定するのではなく)使われる事がある。Bの中では、あたかもBとその祖先でxml:langなど指定されなかったかのように、言語についての情報が無いものと見なされる。アプリケーションは、要素のどの属性値がxml:langで説明される言語依存の値として取り扱われるのか、また、(もしあれば)要素の内容のどの部分が言語依存のものとして取り扱われるのかを決定する。

The language specified by xml:lang applies to the element where it is specified (including the values of its attributes), and to all elements in its content unless overridden with another instance of xml:lang. In particular, the empty value of xml:lang is used on an element B to override a specification of xml:lang on an enclosing element A, without specifying another language. Within B, it is considered that there is no language information available, just as if xml:lang had not been specified on B or any of its ancestors. Applications determine which of an element's attribute values and which parts of its character content, if any, are treated as language-dependent values described by xml:lang.

xml:langの簡単な宣言は、次の形を採るだろう。

A simple declaration for xml:lang might take the form

xml:lang CDATA #IMPLIED

しかし、適切ならば、特定のデフォルト値を与えても良い。フランス語で書かれた一連の詩(poem)を、英語で書かれた語義(gloss)と注解(note)と共に、英語を使う学生の為に用意するならば、xml:langは次のように宣言されるだろう。

but specific default values may also be given, if appropriate. In a collection of French poems for English students, with glosses and notes in English, the xml:lang attribute might be declared this way:

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

3.1 開始タグ、終了タグ、空要素タグ Start-Tags, End-Tags, and Empty-Element Tags

[定義: 空でないXML要素の始まりは、すべて開始タグで示される。]

[Definition: The beginning of every non-empty XML element is marked by a start-tag.]

開始タグ Start-tag

開始タグと終了タグのNameは、その要素の型を与える。 [定義: NameとAttValueの組は、要素の属性指定と呼ばれる。] [定義: 属性指定のNameは属性名と呼ばれる。] [定義: AttValueの内容(区切り子'あるいは"で挟まれたテキスト)は属性値と呼ばれる。] 開始タグや空要素タグの属性指定の順番は有意でない事に注意してほしい。

The Name in the start- and end-tags gives the element's type. [Definition: The Name-AttValue pairs are referred to as the attribute specifications of the element], [Definition: with the Name in each pair referred to as the attribute name] and [Definition: the content of the AttValue (the text between the ' or " delimiters) as the attribute value.] Note that the order of attribute specifications in a start-tag or empty-element tag is not significant.

開始タグの一例を挙げる。

An example of a start-tag:

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

[定義: 開始タグで始まる要素は、すべて、開始タグで与えられる要素型に対応する名前を持つ終了タグで示されなければならない(MUST)。]

[Definition: The end of every element that begins with a start-tag MUST be marked by an end-tag containing a name that echoes the element's type as given in the start-tag:]

終了タグ End-tag

終了タグの一例を挙げる。

An example of an end-tag:

</termdef>

[定義: 開始タグと終了タグに挟まれたテキストは、要素の内容と呼ばれる。]

[Definition: The text between the start-tag and end-tag is called the element's content:]

要素の内容 Content of Elements

[定義: contentを持たない要素は空だと言われる。] 空である要素は、終了タグが開始タグの直後に続く事か、空要素タグを使う事で表現される。 [定義: 空要素タグは、次の特別な形を採る。]

[Definition: An element with no content is said to be empty.] The representation of an empty element is either a start-tag immediately followed by an end-tag, or an empty-element tag. [Definition: An empty-element tag takes a special form:]

空要素のタグ Tags for Empty Elements

空要素タグは、要素が内容を一切持たないのであれば、その要素がキーワードEMPTYを使って宣言されたかどうかに拘わらず、あらゆる要素に使っても良い。しかし、相互運用性の為に、空要素タグはEMPTYと宣言された要素だけに使われる事が望ましい(SHOULD)。

Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY. For interoperability, the empty-element tag SHOULD be used, and SHOULD only be used, for elements which are declared EMPTY.

空要素の例を幾つか挙げる。

Examples of empty elements:

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

3.2 要素型宣言 Element Type Declarations

妥当性を検証する目的で、XML文書の要素の構造に、要素型宣言や属性リスト宣言を使って制約を課す事がある。要素型宣言は要素の内容に制約を課す。

The element structure of an XML document may, for validation purposes, be constrained using element type and attribute-list declarations. An element type declaration constrains the element's content.

要素型宣言はしばしば、どの要素型がその要素の子として現れ得るかを制限する。ある宣言が、宣言の無い要素型について言及した場合、XMLプロセッサは、ユーザが選択した場合、警告を出しても良い(MAY)が、これはエラーではない。

Element type declarations often constrain which element types can appear as children of the element. At user option, an XML processor MAY issue a warning when a declaration mentions an element type for which no declaration is provided, but this is not an error.

[定義: 要素型宣言は次の形を採る。]

[Definition: An element type declaration takes the form:]

要素型宣言 Element Type Declaration

ここで、Nameは、宣言される要素型を与える。

where the Name gives the element type being declared.

要素型宣言の例を幾つか挙げる。

Examples of element type declarations:

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

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

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

3.3 属性リスト宣言 Attribute-List Declarations

属性は、名前と値の組を要素に関連付ける為に使われる。属性指定は開始タグや空要素タグの外に現れてはならない(MUST NOT)。この為、属性指定を認識する為の生成規則はすべて3.1 開始タグ、終了タグ、空要素タグ Start-Tags, End-Tags, and Empty-Element Tagsにある。一方、属性リスト宣言は次の目的の為に使われる事がある。

Attributes are used to associate name-value pairs with elements. Attribute specifications MUST NOT appear outside of start-tags and empty-element tags; thus, the productions used to recognize them appear in 3.1 Start-Tags, End-Tags, and Empty-Element Tags. Attribute-list declarations may be used:

• 与えられた要素型に関連する属性の組を定義する為。

  To define the set of attributes pertaining to a given element type.

• それらの属性に対する型の制約を確立する為。

  To establish type constraints for these attributes.

• 属性にデフォルト値を提供する為。

  To provide default values for attributes.

[定義: 属性リスト宣言は、与えられた要素型に関連付けられたそれぞれの属性の名前、データ型、そして(もしあれば)デフォルト値を指定する。]

[Definition: Attribute-list declarations specify the name, data type, and default value (if any) of each attribute associated with a given element type:]

属性リスト宣言 Attribute-list Declaration

AttlistDecl規則のNameは、要素の型である。ユーザが選択した場合、XMLプロセッサは、それ自身が宣言されていない要素に対して属性が宣言された場合に警告を出しても良い(MAY)が、これはエラーではない。AttDef規則のNameは属性の名前である。

The Name in the AttlistDecl rule is the type of an element. At user option, an XML processor MAY issue a warning if attributes are declared for an element type not itself declared, but this is not an error. The Name in the AttDef rule is the name of the attribute.

一つの要素型に対して二つ以上のAttlistDeclが与えられた場合、それらの内容はすべて混ぜ合わされる。ある要素型の同じ属性に対して二つ以上の定義が与えられた場合、最初に現れたものが関連付けられ、その後に現れた宣言はすべて無視される。相互運用性の為に、DTDの作成者は、一つの要素型に対して多くとも一つの属性リスト宣言しか書かず、一つの属性リスト宣言の中では一つの属性に対して多くとも一つの属性定義しか用意しないようにし、それぞれの属性リスト宣言には少なくとも一つの属性定義を与えるようにしても良い。また、相互運用性の為に、XMLプロセッサは、ユーザが選択した場合、一つの要素型に対して二つ以上の属性リスト宣言が与えられた場合や、一つの属性に対して二つ以上の定義が与えられた場合、警告を出しても良い(MAY)が、これはエラーではない。

When more than one AttlistDecl is provided for a given element type, the contents of all those provided are merged. When more than one definition is provided for the same attribute of a given element type, the first declaration is binding and later declarations are ignored. For interoperability, writers of DTDs may choose to provide at most one attribute-list declaration for a given element type, at most one attribute definition for a given attribute name in an attribute-list declaration, and at least one attribute definition in each attribute-list declaration. For interoperability, an XML processor MAY at user option issue a warning when more than one attribute-list declaration is provided for a given element type, or more than one attribute definition is provided for a given attribute, but this is not an error.

<!ATTLIST termdef
          id      ID      #REQUIRED
          name    CDATA   #IMPLIED>
<!ATTLIST list
          type    (bullets|ordered|glossary)  "ordered">
<!ATTLIST form
          method  CDATA   #FIXED "POST">

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

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 #x20 B #x20 #x20

a= "

A

B
"

#xD #xD A #xA #xA B #xD #xA

#xD #xD A #xA #xA B #xD #xA

3.4 条件付きセクション Conditional Sections

[Definition: 条件付きセクションは、条件を支配するキーワードによってDTDの論理構造に取り込まれたり除外されたりする文書型宣言の外部サブセットの一部、あるいは外部パラメータ実体の一部である。]

[Definition: Conditional sections are portions of the document type declaration external subset or of external parameter entities which are included in, or excluded from, the logical structure of the DTD based on the keyword which governs them.]

条件付きセクション Conditional Section

内部及び外部DTDサブセットと同様、条件付きセクションは一つ以上の完全な宣言、コメント、処理命令、ネストされた条件付きセクションを含んで良く、それらの間にホワイトスペースを混ぜても良い。

Like the internal and external DTD subsets, a conditional section may contain one or more complete declarations, comments, processing instructions, or nested conditional sections, intermingled with white space.

条件付きセクションのキーワードがINCLUDEであれば、その条件付きセクションの内容はDTDの一部として処理されなければならない(MUST)。条件付きセクションのキーワードがIGNOREであれば、その条件付きセクションの内容はDTDの一部として処理されてはならない(MUST NOT)。キーワードにINCLUDEを持つ条件付きセクションが、キーワードにIGNOREを持つ、より大きな条件付きセクションの中に現れた場合は、外側及び内側の条件付きセクションは両方とも無視されなければならない(MUST)。無視される条件付きセクションの内容は、キーワードに続く"["の直後から、対応する条件付きセクションの終了が見つかる手前までのすべての文字(但し条件付きセクションの開始"<!["と終了"]]>"は例外)を無視しながら解析されなければならない(MUST)。この過程では、パラメータ実体参照は認識されてはならない(MUST NOT)。

If the keyword of the conditional section is INCLUDE, then the contents of the conditional section MUST be processed as part of the DTD. If the keyword of the conditional section is IGNORE, then the contents of the conditional section MUST NOT be processed as part of the DTD. If a conditional section with a keyword of INCLUDE occurs within a larger conditional section with a keyword of IGNORE, both the outer and the inner conditional sections MUST be ignored. The contents of an ignored conditional section MUST be parsed by ignoring all characters after the "[" following the keyword, except conditional section starts "<![" and ends "]]>", until the matching conditional section end is found. Parameter entity references MUST NOT be recognized in this process.

条件付きセクションのキーワードがパラメータ実体参照ならば、そのパラメータ実体は、プロセッサがその条件付きセクションを取り込むか無視するかを決定する前に、そのパラメータ実体の内容で置き換えられなければならない(MUST)。

If the keyword of the conditional section is a parameter-entity reference, the parameter entity MUST be replaced by its content before the processor decides whether to include or ignore the conditional section.

条件付きセクションの一例を挙げる。

An example:

<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >

<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>
<![%final;[
<!ELEMENT book (title, body, supplements?)>
]]>

4.1 文字参照と実体参照 Character and Entity References

[定義: 文字参照は、ISO/IEC 10646文字セットに含まれる特定の文字を参照する。例えば、利用可能な入力デバイスでは直接入力できない文字を参照する。]

[Definition: A character reference refers to a specific character in the ISO/IEC 10646 character set, for example one not directly accessible from available input devices.]

文字参照 Character Reference

文字参照が"&#x"から始まれば、終わりの;までの数字と文字は、ISO/IEC 10646のコード点の16進数表記を与える。ただの"&#"から始まれば、終わりの;までの数字は、その文字のコード点の10進数表記を与える。

If the character reference begins with "&#x", the digits and letters up to the terminating ; provide a hexadecimal representation of the character's code point in ISO/IEC 10646. If it begins just with "&#", the digits up to the terminating ; provide a decimal representation of the character's code point.

[定義: 実体参照は、名前の付いた実体の内容を参照する。] [定義: 解析対象一般実体への参照は、アンパサンド(&)とセミコロン(;)を区切り子に使う。] [定義: パラメータ実体参照はパーセント符号(%)とセミコロン(;)を区切り子に使う。]

[Definition: An entity reference refers to the content of a named entity.] [Definition: References to parsed general entities use ampersand (&) and semicolon (;) as delimiters.] [Definition: Parameter-entity references use percent-sign (%) and semicolon (;) as delimiters.]

実体参照 Entity Reference

文字参照と実体参照の例を幾つか挙げる。

Examples of character and entity references:

Type <key>less-than</key> (&#x3C;) to save options.
This document was prepared on &docdate; and
is classified &security-level;.

パラメータ実体参照の一例を挙げる。

Example of a parameter-entity reference:

<!-- declare the parameter entity "ISOLat2"... -->
<!ENTITY % ISOLat2
         SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... now reference it. -->
%ISOLat2;

4.2 実体宣言 Entity Declarations

[定義: 実体は次のように宣言される。]

[Definition: Entities are declared thus:]

実体宣言 Entity Declaration

Nameは、実体参照でその実体を識別する為の名前である。解析対象外実体の場合は、ENTITY属性やENTITIES属性の値でその実体を識別する為の名前である。もし同じ名前の実体が二回以上宣言された場合は、最初に見つかった宣言がその実体に結び付けられる。ユーザが選択した場合、XMLプロセッサは、実体が複数回宣言された場合に警告を出しても良い(MAY)。

The Name identifies the entity in an entity reference or, in the case of an unparsed entity, in the value of an ENTITY or ENTITIES attribute. If the same entity is declared more than once, the first declaration encountered is binding; at user option, an XML processor MAY issue a warning if entities are declared multiple times.

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

<!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

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

4.4 XMLプロセッサによる実体と参照の扱い XML Processor Treatment of Entities and References

以下に挙げる表は、文字参照、実体参照、及び解析対象外実体の呼び出しが現れ得る文脈と、それぞれの場合においてXMLプロセッサに要求される(REQUIRED)動作を要約したものである。最左端の列のラベルは認識される文脈を説明する。認識される文脈の種類は次の通り。

The table below summarizes the contexts in which character references, entity references, and invocations of unparsed entities might appear and the REQUIRED behavior of an XML processor in each case. The labels in the leftmost column describe the recognition context:

内容の中での参照 Reference in Content

要素の開始タグの後から終了タグの手前までに現れる参照として。非終端contentに対応する。

as a reference anywhere after the start-tag and before the end-tag of an element; corresponds to the nonterminal content.

属性値の中での参照 Reference in Attribute Value

開始タグの属性の値の中、あるいは属性宣言のデフォルト値の中に現れる参照として。非終端AttValueに対応する。

as a reference within either the value of an attribute in a start-tag, or a default value in an attribute declaration; corresponds to the nonterminal AttValue.

属性値としての名前 Occurs as Attribute Value

型ENTITYとして宣言された属性の値に現れるNameとして、あるいは型ENTITIESとして宣言された属性の値に含まれるスペースで区切られたトークンの一つ(Name)として。参照としてではない。

as a Name, not a reference, appearing either as the value of an attribute which has been declared as type ENTITY, or as one of the space-separated tokens in the value of an attribute which has been declared as type ENTITIES.

実体値の中での参照 Reference in Entity Value

パラメータ実体や内部実体の実体宣言の中のリテラル実体値に現れる参照として。非終端EntityValueに対応する。

as a reference within a parameter or internal entity's literal entity value in the entity's declaration; corresponds to the nonterminal EntityValue.

DTDの中での参照 Reference in DTD

DTDの内部サブセット、あるいは外部サブセットの中に現れる参照として。但し、EntityValue、AttValue、PI、Comment、SystemLiteral、PubidLiteral、及び無視される条件付きセクション(3.4 条件付きセクション Conditional Sections参照)の内容の外に限る。

as a reference within either the internal or external subsets of the DTD, but outside of an EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral, or the contents of an ignored conditional section (see 3.4 Conditional Sections).

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

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

4.5 実体の置換テキストの構築 Construction of Entity Replacement Text

実体の扱いについて取り扱う際、二種類の実体値を区別すると便利である。 [定義: 内部実体について、リテラル実体値は、実体宣言の中に実際に存在する、引用符で挟まれた文字列である。これは非終端EntityValueに対応する。] [定義: 外部実体について、リテラル実体値は、その実体に含まれるテキストそのものである。] [定義: 内部実体について、置換テキストは、文字参照とパラメータ実体参照を置換した後における、その実体の内容である。] [定義: 外部実体について、置換テキストは、テキスト宣言が存在すればそれを取り去った後における、その実体の内容である。但しテキスト宣言を取り去る場合でも、その周囲のホワイトスペースはそのまま置換テキストに残る。また、文字参照やパラメータ実体参照も置換されない。]

In discussing the treatment of entities, it is useful to distinguish two forms of the entity's value. [Definition: For an internal entity, the literal entity value is the quoted string actually present in the entity declaration, corresponding to the non-terminal EntityValue.] [Definition: For an external entity, the literal entity value is the exact text contained in the entity.] [Definition: For an internal entity, the replacement text is the content of the entity, after replacement of character references and parameter-entity references.] [Definition: For an external entity, the replacement text is the content of the entity, after stripping the text declaration (leaving any surrounding whitespace) if there is one but without any replacement of character references or parameter-entity references.]

内部実体宣言で与えられるリテラル実体値(EntityValue)は、文字参照、パラメータ実体参照、一般実体参照を含んでも良い。そのような参照は、全体がそのリテラル実体値の中に含まれなければならない(MUST)。インクルードされた(あるいはリテラルの中でインクルードされた)実際の置換テキストは、上で説明されているように、参照されたパラメータ実体の置換テキストを含まなければならない(MUST)し、リテラル実体値中の文字参照の代わりに、参照された文字を含まなければならない(MUST)。しかし、一般実体参照は、そのまま、つまり展開されないままにしておかれなければならない(MUST)。例えば、次の宣言を与えられたものとする。

The literal entity value as given in an internal entity declaration (EntityValue) may contain character, parameter-entity, and general-entity references. Such references MUST be contained entirely within the literal entity value. The actual replacement text that is included (or included in literal) as described above MUST contain the replacement text of any parameter entities referred to, and MUST contain the character referred to, in place of any character references in the literal entity value; however, general-entity references MUST be left as-is, unexpanded. For example, given the following declarations:

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

この時、実体"book"の置換テキストは次のようになる。

then the replacement text for the entity "book" is:

La Peste: Albert Camus,
© 1947 Éditions Gallimard. &rights;

もし参照"&book;"が文書の内容や属性値の中に現れるなら、一般実体参照"&rights;"も展開されるだろう。

The general-entity reference "&rights;" would be expanded should the reference "&book;" appear in the document's content or an attribute value.

これらの簡単な規則が複雑な相互作用をする事もある。難しい例を用いた詳しい説明は、C 実体参照と文字参照の展開 Expansion of Entity and Character Referencesで見られる。

These simple rules may have complex interactions; for a detailed discussion of a difficult example, see C Expansion of Entity and Character References.

4.6 定義済み実体 Predefined Entities

[定義: 実体参照や文字参照は、左山括弧、アンパサンド、及びその他の区切り子をエスケープする為に使われる事がある。一般実体のセット(amp、lt、gt、apos、quot)がこの目的の為に定められている。数値文字参照も使われる事がある。文字参照は認識された時直ちに展開され、文字データとして扱われなければならない(MUST)。この為、数値文字参照"<"と"&"は、文字データの中で現れた時、<と&をエスケープする為に使われる事ができる。]

[Definition: Entity and character references may both be used to escape the left angle bracket, ampersand, and other delimiters. A set of general entities (amp, lt, gt, apos, quot) is specified for this purpose. Numeric character references may also be used; they are expanded immediately when recognized and MUST be treated as character data, so the numeric character references "<" and "&" may be used to escape < and & when they occur in character data.]

すべてのXMLプロセッサは、これらの実体が宣言されているかいないかに拘わらず、それらを認識しなければならない(MUST)。相互運用性の為に、妥当なXML文書は、他の実体と同じように、これらの実体も使う前に宣言する事が望ましい(SHOULD)。実体ltやampが宣言される場合、置換テキストが、エスケープされているそれぞれの文字(左山括弧かアンパサンド)への文字参照となる内部実体として宣言されなければならない(MUST)。これらの実体への参照をしても整形式であるようにする為に、二重のエスケーピングは必須である(REQUIRED)。実体gt、apos、及びquotが宣言される場合、置換テキストがエスケープされている一つの文字となる内部実体として宣言されなければならない(MUST)(置換テキストが、その文字への文字参照となる内部実体として宣言されても良い。ここでの二重エスケーピングは任意である(OPTIONAL)が、やったとしても無害である)。これらの実体の宣言の例を次に挙げる。

All XML processors MUST recognize these entities whether they are declared or not. For interoperability, valid XML documents SHOULD declare these entities, like any others, before using them. If the entities lt or amp are declared, they MUST be declared as internal entities whose replacement text is a character reference to the respective character (less-than sign or ampersand) being escaped; the double escaping is REQUIRED for these entities so that references to them produce a well-formed result. If the entities gt, apos, or quot are declared, they MUST be declared as internal entities whose replacement text is the single character being escaped (or a character reference to that character; the double escaping here is OPTIONAL but harmless). For example:

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

4.7 記法宣言 Notation Declarations

[定義: 記法は、解析対象外実体のフォーマットや、記法属性を持つ要素のフォーマット、あるいは処理命令が与えられるアプリケーションを、名前で識別する。]

[Definition: Notations identify by name the format of unparsed entities, the format of elements which bear a notation attribute, or the application to which a processing instruction is addressed.]

[定義: 記法宣言は、実体宣言や属性リスト宣言、属性指定で使う為の、記法の名前を提供する。また、その記法のデータを処理する事のできるヘルパーアプリケーションの位置をXMLプロセッサやそのクライアントアプリケーションに伝える、外部識別子も提供する。]

[Definition: Notation declarations provide a name for the notation, for use in entity and attribute-list declarations and in attribute specifications, and an external identifier for the notation which may allow an XML processor or its client application to locate a helper application capable of processing data in the given notation.]

記法宣言 Notation Declarations

XMLプロセッサは、宣言され、属性値や属性定義、実体宣言で参照されたすべての記法について、その名前と外部識別子をアプリケーションに提供しなければならない(MUST)。それに加えて、外部識別子を、システム識別子やファイル名、あるいは指定された記法のデータを処理する為のプロセッサをアプリケーションが呼び出す為に必要なその他の情報に解決しても良い(MAY)。しかしながら、XMLプロセッサやアプリケーションが動作しているシステムでは入手不能なアプリケーションを指定する記法を、XML文書が宣言したり参照したりしても、エラーにはならない。

XML processors MUST provide applications with the name and external identifier(s) of any notation declared and referred to in an attribute value, attribute definition, or entity declaration. They MAY additionally resolve the external identifier into the system identifier, file name, or other information needed to allow the application to call a processor for data in the notation described. (It is not an error, however, for XML documents to declare and refer to notations for which notation-specific applications are not available on the system where the XML processor or application is running.)

4.8 文書実体 Document Entity

[定義: 文書実体は、実体ツリーのルートや、XMLプロセッサの開始点になる。] この仕様書では、文書実体がXMLプロセッサによってどのように探し出されるべきかについては指定しない。他の実体と違って、文書実体には名前が無く、プロセッサの入力ストリームに現れる時も一切の識別情報を持たずに現れるであろう。

[Definition: The document entity serves as the root of the entity tree and a starting-point for an XML processor.] This specification does not specify how the document entity is to be located by an XML processor; unlike other entities, the document entity has no name and might well appear on a processor input stream without any identification at all.

5.1 妥当性を検証するプロセッサとしないプロセッサ Validating and Non-Validating Processors

仕様に適合するXMLプロセッサは、妥当性を検証するものと妥当性を検証しないものの二種類に分類される。

Conforming XML processors fall into two classes: validating and non-validating.

妥当性を検証するプロセッサとしないプロセッサは何れも、文書実体やそれ以外に読み取った解析対象実体の内容で、この仕様書の整形式性制約の違反を見つけた場合、その違反を報告しなければならない(MUST)。

Validating and non-validating processors alike MUST report violations of this specification's well-formedness constraints in the content of the document entity and any other parsed entities that they read.

[定義: 妥当性を検証するプロセッサは、ユーザが選択した場合、DTDの宣言で表される制約の違反や、この仕様書で与えられる妥当性制約の不履行を報告しなければならない(MUST)。] これを達成する為、妥当性を検証するプロセッサは、DTD全体、及び文書で参照されたすべての外部解析対象実体を読み取り、処理しなければならない(MUST)。

[Definition: Validating processors MUST, at user option, report violations of the constraints expressed by the declarations in the DTD, and failures to fulfill the validity constraints given in this specification.] To accomplish this, validating XML processors MUST read and process the entire DTD and all external parsed entities referenced in the document.

妥当性を検証しないプロセッサでは、内部DTDサブセット全体を含めた文書実体だけを、整形式性を調べる為に検査する事が必須とされる(REQUIRED)。 [定義: 妥当性を検証しないプロセッサは、妥当性を調べる為に文書を検査する事は要求されないが、内部DTDサブセットの中や、読み取ったパラメータ実体の中に現れる宣言を、読み取らないパラメータ実体への参照が最初に現れるまで処理する事が必須とされる(REQUIRED)。つまり、妥当性を検証しないプロセッサは、それらの宣言に含まれる情報を、属性値を正規化したり、内部実体の置換テキストをインクルードしたり、デフォルト属性値を提供したりする為に使わなければならない(MUST)。] standalone="yes"である場合を除き、妥当性を検証しないプロセッサは、読み取らないパラメータ実体への参照に出くわした後に見つけた実体宣言や属性リスト宣言を処理してはならない(MUST NOT)。これは、その読み取らない実体が上書きする宣言を持っているかも知れないからである。一方、standalone="yes"である場合は、プロセッサはこれらの宣言(読み取らないパラメータ実体への参照に出くわした後に見つけた宣言)を処理しなければならない(MUST)。

Non-validating processors are REQUIRED to check only the document entity, including the entire internal DTD subset, for well-formedness. [Definition: While they are not required to check the document for validity, they are REQUIRED to process all the declarations they read in the internal DTD subset and in any parameter entity that they read, up to the first reference to a parameter entity that they do not read; that is to say, they MUST use the information in those declarations to normalize attribute values, include the replacement text of internal entities, and supply default attribute values.] Except when standalone="yes", they MUST NOT process entity declarations or attribute-list declarations encountered after a reference to a parameter entity that is not read, since the entity may have contained overriding declarations; when standalone="yes", processors MUST process these declarations.

注意してほしいのは、妥当でない文書を妥当性を検証しないプロセッサで処理する時、アプリケーションは矛盾の無い情報を受け取れない事があるかも知れない事である。例えば、文書における一意性に関する幾つかの要件が満たされないかも知れない(同じIDを持つ要素が二つ以上あったり、同じ名前を持つ要素型や記法の重複した宣言があったりするかも知れない)。これらの場合、それらの情報をアプリケーションに報告するという点では、パーサの動作は定義されない。

Note that when processing invalid documents with a non-validating processor the application may not be presented with consistent information. For example, several requirements for uniqueness within the document may not be met, including more than one element with the same id, duplicate declarations of elements or notations with the same name, etc. In these cases the behavior of the parser with respect to reporting such information to the application is undefined.

5.2 XMLプロセッサの使用 Using XML Processors

妥当性を検証するXMLプロセッサの動作は非常に予測しやすい。文書のすべての構成要素を読み取って、すべての整形式性違反と妥当性違反を報告しなければならないからである。妥当性を検証しないプロセッサではそれ程要求されない。文書実体以外の文書の構成要素は、読み取る事が必要とされないのである。この事には、XMLプロセッサのユーザにとって重要となる二つの効果がある。

The behavior of a validating XML processor is highly predictable; it must read every piece of a document and report all well-formedness and validity violations. Less is required of a non-validating processor; it need not read any part of the document other than the document entity. This has two effects that may be important to users of XML processors:

• ある種の整形式性エラー、特に外部実体の読み取りを必要とするものは、妥当性を検証しないプロセッサでは検知に失敗するかも知れない。例として、宣言された実体、解析対象実体、一切無い再帰と題された制約や、4.4 XMLプロセッサによる実体と参照の扱い XML Processor Treatment of Entities and Referencesで許されないとして説明されている場合の内の幾つかが挙げられる。

  Certain well-formedness errors, specifically those that require reading external entities, may fail to be detected by a non-validating processor. Examples include the constraints entitled Entity Declared, Parsed Entity, and No Recursion, as well as some of the cases described as forbidden in 4.4 XML Processor Treatment of Entities and References.

• プロセッサからアプリケーションに渡される情報は、プロセッサが外部実体やパラメータ実体を読み取るかどうかによって、変化する事がある。例えば、妥当性を検証しないプロセッサは、属性値を正規化したり、内部実体の置換テキストをインクルードしたり、デフォルト属性値を提供したりする事ができないかも知れない(それらの遂行が外部実体やパラメータ実体の中の宣言の読み取りに依存する場合)。

  The information passed from the processor to the application may vary, depending on whether the processor reads parameter and external entities. For example, a non-validating processor may fail to normalize attribute values, include the replacement text of internal entities, or supply default attribute values, where doing so depends on having read declarations in external or parameter entities.

異なるXMLプロセッサと相互運用する際の信頼性を最大化する為には、妥当性を検証しないプロセッサを使うアプリケーションがそのプロセッサでは要求されない動作に頼る事は望ましくない(SHOULD NOT)。妥当性の検証に関係の無いDTDが提供する便利なもの(外部実体の中で指定される、あるいは指定されるかも知れないデフォルト属性の宣言や内部実体など)を必要とするアプリケーションは、妥当性を検証するプロセッサを使う事が望ましい(SHOULD)。

For maximum reliability in interoperating between different XML processors, applications which use non-validating processors SHOULD NOT rely on any behaviors not required of such processors. Applications which require DTD facilities not related to validation (such as the declaration of default attributes and internal entities that are or may be specified in external entities) SHOULD use validating XML processors.