Extensible Markup Language (XML) 1.1 (第二版) Extensible Markup Language (XML) 1.1 (Second 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.1を理解し、処理する事のできるコンピュータプログラムを構築する為に必要な全ての情報が書かれている。

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.1 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

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

[Definition: (Of strings or names:) Two strings or names being compared are identical. Characters with multiple possible representations in Unicode (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の事でしょう。Case FoldingはUTR # 30 Character Foldings(2007-07-27T17:40:27+09:00現在はまだ草稿の段階)で説明されているキャラクタフォールディング(Character 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.]

1.3 XML 1.1での変更点とその原理的説明 Rationale and list of changes for XML 1.1

W3CのXML 1.0の勧告文書が最初に発行されたのは1998年である。沢山の誤りの発見と訂正の積み重ねは2004年に第三版を登場させる事となったが、それでもXML 1.0は、どんなXML文書が整形式で、どんなXML文書が整形式でないかという点では不変であった(これは意図的な狙いに因る)。この安定性は相互運用性を確保するという点において、非常に便利であった。しかしながらXML 1.0が文字についての仕様として頼っていたUnicode Standardは変わり続け、バージョン2.0からバージョン4.0、そして更に後続のバージョンへと発展していった。Unicode 2.0には登場しない文字でも、XML 1.0の文字データでは既に使う事ができた。しかし、それらの文字はXML名前、例えば要素型名、属性名、列挙属性値、処理命令の対象などに用いる事は許されていなかった。しかも、Unicode 2.0の仕様書で見落としをして、Unicode 2.0との間で整合性が保たれていなかった為に、本来XML名前で許されるべきだった文字の一部は、使用が許されていなかった。

The W3C's XML 1.0 Recommendation was first issued in 1998, and despite the issuance of many errata culminating in a Third Edition of 2004, has remained (by intention) unchanged with respect to what is well-formed XML and what is not. This stability has been extremely useful for interoperability. However, the Unicode Standard on which XML 1.0 relies for character specifications has not remained static, evolving from version 2.0 to version 4.0 and beyond. Characters not present in Unicode 2.0 may already be used in XML 1.0 character data. However, they are not allowed in XML names such as element type names, attribute names, enumerated attribute values, processing instruction targets, and so on. In addition, some characters that should have been permitted in XML names were not, due to oversights and inconsistencies in Unicode 2.0.

名前に関する方針はXML 1.0のものからがらりと変わった。XML 1.0の名前の定義は融通が利かず、許されていないものは全て禁止されていたが、XML 1.1の名前では、特別な理由で禁止されていなければ、それらは全て許される。Unicodeはバージョン4.0を出した後でも発展を続けるだろう。それ故、Unicodeでまだ割り当てられていない文字も含めて殆ど全ての文字を名前に使う事を許可する事は、度重なるXMLの改訂を回避する事に繋がると考えられるのである。

The overall philosophy of names has changed since XML 1.0. Whereas XML 1.0 provided a rigid definition of names, wherein everything that was not permitted was forbidden, XML 1.1 names are designed so that everything that is not forbidden (for a specific reason) is permitted. Since Unicode will continue to grow past version 4.0, further changes to XML can be avoided by allowing almost any character, including those not yet assigned, in names.

加えて、XML 1.0はモダンなOSで用いられる行末の慣習を幅広く受け容れようとしたが、IBM及びIBM互換のメインフレームで使われる行末の慣習に対する配慮が無かった。その結果、XML文書は、メインフレームではプレーンテキストではなくなってしまった。メインフレームでXML 1.0文書を生成するには、ローカルな行末の慣習に逆らうか、あるいは構文解析の前と生成の後に不必要な変換をしなければならなかった。メインフレームとメインフレームでない環境の間でデータストアが共有される場合には、データストアがそのまま使えるという事(相互運用性)は特に重要な事である。故に、XML 1.1はNEL(#x85)を行末記号のリストに加える。更に万全を期す為、Unicodeの行区切り文字である#x2028もサポートされる。

In addition, XML 1.0 attempts to adapt to the line-end conventions of various modern operating systems, but discriminates against the conventions used on IBM and IBM-compatible mainframes. As a result, XML documents on mainframes are not plain text files according to the local conventions. XML 1.0 documents generated on mainframes must either violate the local line-end conventions, or employ otherwise unnecessary translation phases before parsing and after generation. Allowing straightforward interoperability is particularly important when data stores are shared between mainframe and non-mainframe systems (as opposed to being copied from one to the other). Therefore XML 1.1 adds NEL (#x85) to the list of line-end characters. For completeness, the Unicode line separator character, #x2028, is also supported.

そして、XML文書で任意のUnicode文字を使う為の標準的な表現方法を定めるよう、強い要望があった。これを受けてXML 1.1では、制御文字である#x1から#x1Fまでを参照する文字参照の使用を認めている。これらの文字参照の殆どはXML 1.0では禁止されていた。しかし、堅牢性の観点から、これらの文字を(文字参照を使わず)直接文書で使う事はXML 1.1でも認められない。また、文字エンコーディング検知の堅牢性を高める為、XML 1.0では文書中で自由に使う事が許されていた制御文字、つまり#x7Fから#x9Fまでの文字は、文字参照としてしか現れ得ない。勿論、ホワイトスペース文字はこの制限の対象ではない。後方互換性を僅かに犠牲にした事は、さして重要ではないと考えられる。また、APIが潜在的な問題を抱えている為、#x0についてはXML 1.1でも、直接記述する事も文字参照を使って表す事も禁止されている。

Finally, there is considerable demand to define a standard representation of arbitrary Unicode characters in XML documents. Therefore, XML 1.1 allows the use of character references to the control characters #x1 through #x1F, most of which are forbidden in XML 1.0. For reasons of robustness, however, these characters still cannot be used directly in documents. In order to improve the robustness of character encoding detection, the additional control characters #x7F through #x9F, which were freely allowed in XML 1.0 documents, now must also appear only as character references. (Whitespace characters are of course exempt.) The minor sacrifice of backward compatibility is considered not significant. Due to potential problems with APIs, #x0 is still forbidden both directly and as a character reference.

最後に、XML 1.1は、XML文書における「完全正規化」を定義する。文書の作成者は完全正規化を固守する事が望ましく(SHOULD)、文書のプロセッサは検証する事が望ましい(SHOULD)。完全に正規化された文書を用いれば、名前、属性値や内容の文字が完全に同一であるかどうかの比較が、単にバイナリレベルでUnicode文字列を比較する事によって正確に行われる事が保証される。

Finally, XML 1.1 defines a set of constraints called "full normalization" on XML documents, which document creators SHOULD adhere to, and document processors SHOULD verify. Using fully normalized documents ensures that identity comparisons of names, attribute values, and character content can be made correctly by simple binary comparison of Unicode strings.

XML 1.0の誤りを直すのではなく、XMLの新しいバージョンが作られているのは、変更が整形式の文書の定義に及んだからである。XML 1.0プロセッサは依然として、XML名前に新しい文字、新しい行末の慣習、そして制御文字を参照する文字参照を含む文書を拒絶しなければならない。文書がXML 1.0文書であるか、XML 1.1文書であるかは、各文書の最初に置かれるXML宣言のバージョン番号情報で示される。

A new XML version, rather than a set of errata to XML 1.0, is being created because the changes affect the definition of well-formed documents. XML 1.0 processors must continue to reject documents that contain new characters in XML names, new line-end conventions, and references to control characters. The distinction between XML 1.0 and XML 1.1 documents is indicated by the version number information in the XML declaration at the start of each document.

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 [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 [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 [Unicode]の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 [Unicode]; 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.

[#x1-#x8], [#xB-#xC], [#xE-#x1F], [#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

[定義: 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.

Nameの最初の文字はNameStartCharでなければならい(MUST)。同時に、名前の二文字目以降の文字はNameCharsでなければならない(MUST)。この機構が使われるのは、ASCIIの欧州数字や、基本的結合文字から始まる事を避ける為である。名前に使える文字は、区切り子として使われるもの、あるいは区切り子として使われたとしても合理的なものを除く殆ど全ての文字である。その意図は排他的ではなく非排他的であり、まだUnicodeでエンコードされていない記述体系もXML名前で使えるようにする為のものである。なお、新しいXML名前を作る際にはI XML名前の為の提案 Suggestions for XML Namesを参照してほしい。

The first character of a Name MUST be a NameStartChar, and any other characters MUST be NameChars; this mechanism is used to prevent names from beginning with European (ASCII) digits or with basic combining characters. Almost all characters are permitted in names, except those which either are or reasonably could be used as delimiters. The intention is to be inclusive rather than exclusive, so that writing systems not yet encoded in Unicode can be used in XML names. See I Suggestions for XML Names for suggestions on the creation of names.

文書の著者には、自然言語において意味のある単語、あるいはその組み合わせを名前に使い、シンボル的な文字や、ホワイトスペース文字を使う事は避ける事をお勧めする。COLON(コロン)、HYPHEN-MINUS(マイナスのハイフン)、FULL STOP(ピリオド)、LOW LINE(アンダースコア)、MIDDLE DOT(ミドルドット(#xB7)、即ち'·')が明示的に許可されている事にも注意してほしい。

Document authors are encouraged to use names which are meaningful words or combinations of words in natural languages, and to avoid symbolic or white space characters in names. Note that COLON, HYPHEN-MINUS, FULL STOP (period), LOW LINE (underscore), and MIDDLE DOT are explicitly permitted.

ASCIIのシンボルや句読点、そしてUnicodeのかなり大きなグループであるシンボル文字グループに含まれる文字は、名前に使う事が許されない。これは、XML文書の外でXML名前が使われる文脈で、これらの文字が区切り子として使えた方が便利だからである。このグループの文字を区切り子にすれば、そのような文脈に、XML名前になり得ないものについての確かな保証を与える事ができる。GREEK QUESTION MARK(ギリシャ語の疑問符(#x037E)、即ち';')も名前に使う事が許されない。もし許せば、この文字は正規化された時セミコロンになり、実体参照の意味を変えてしまう為である。

The ASCII symbols and punctuation marks, along with a fairly large group of Unicode symbol characters, are excluded from names because they are more useful as delimiters in contexts where XML names are used outside XML documents; providing this group gives those contexts hard guarantees about what cannot be part of an XML name. The character #x037E, GREEK QUESTION MARK, is excluded because when normalized it becomes a semicolon, which could change the meaning of entity references.

名前とトークン 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 or 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 1.1文書は、使われるXMLのバージョンを指定するXML宣言から始まらなければならない(MUST)。] 例えば、次に挙げるのは完全なXML 1.1文書である。これは整形式であるが妥当ではない。

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

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

しかし、次に挙げるものは、XML宣言を持っていない為、XML 1.0文書である。

but the following is an XML 1.0 document because it does not have an XML declaration:

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