[訳者註開始]
訳者註
この翻訳版の中には、このようにマークアップされた段落が幾つかあります。これらは翻訳者が独自の判断でやむを得ず追加した註釈(annotation)です。殆どのものは、オリジナル版の読解の為にではなく、翻訳版を読むに当たって問題となるかも知れない事柄に補足する為に追加したものです。元々オリジナル版の仕様書にはこれらの註釈は無く、勿論これらの註釈の内容が間違っていたとしても、それはオリジナル版の誤りではありません。註釈の中に誤りを見つけたら、Hiroaki Hasegawaまでお知らせ下さい。
なお、オリジナル版にはNoteがありますが、これは別物です。混乱を避ける為、オリジナル版のNoteはメモと呼びます。
[訳者註終了]
この文書の公開後に規範的な訂正があるかも知れない。正誤表を確認してほしい。
Please refer to the errata for this document, which may include some normative corrections.
[訳者註開始]
訳者註
翻訳版の誤りは、是非Hiroaki Hasegawaまでお知らせ下さい。
[訳者註終了]
第四版の正誤表も提供されている。
The previous errata for this document, are also available.
翻訳版も参照すると良い。
See also translations.
この文書には、規範的ではないが、XML形式や修正箇所が色分けされたXHTML形式もある。
This document is also available in these non-normative formats: XML and XHTML with color-coded revision indicators.
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Extensible Markup Language (XML)は、この文書で全容を明らかにする、SGMLのサブセットである。XMLの目標は、一般的なSGMLを──現在HTMLで実現されているように──ウェブ上で授受し、処理する事を可能にする事である。XMLは、実装が容易であるように、またSGMLやHTMLと相互運用する事が可能であるように設計されている。
The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML.
このセクションでは、この文書を公開した時点での、この文書の位置付けを説明する。他の文書がより優れたものとして、この文書に取って代わる可能性がある。W3Cが現在公開している文書や、この技術情報の最新版はW3C技術情報索引(http://www.w3.org/TR/)で得られる。
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
この文書は、既に広く使われている国際的なテキスト処理規格の標準(Standard Generalized Markup Language、ISO 8879:1986(E)に修正・訂正を加えたもの)をワールドワイドウェブで使う為、そのサブセットを取る事で作られる構文の仕様を定める。これは、XML Activityの一環として、XML Core Working Groupが策定したものである。この仕様書は、英語版のみが規範である。しかし、この文書の翻訳版を見たいなら、http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlを見ると良い。
This document specifies a syntax created by subsetting an existing, widely used international text processing standard (Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected) for use on the World Wide Web. It is a product of the XML Core Working Group as part of the XML Activity. The English version of this specification is the only normative version. However, for translations of this document, see http://www.w3.org/2003/03/Translations/byTechnology?technology=xml.
この文書はW3Cの勧告文書である。この第五版は、XMLの新しいバージョンではない。読者の簡便の為、2006年8月16日に公開されたXML 1.0 (第四版)で報告され、集積された正誤情報(http://www.w3.org/XML/xml-V10-4e-errata)をまとめ、修正を反映したものである。特に、正誤情報[E09]に基づく修正は、要素や属性の名前における制限を緩和するものであり、これによって、これまでXML 1.1を使う事でしか得られなかった恩恵が、XML 1.0においても大多数のエンドユーザにもたらされる事となる。この結果、この仕様の以前の版に拠ると整形式でないとされてきた多くの文書でも、今では整形式となり得る。また、今回新しく許されるようになった(以前の版では許されていなかった)名前文字をID属性などに使っていた為に妥当でないとされてきた文書も、妥当となり得る。
This document is a W3C Recommendation. This fifth edition is not a new version of XML. As a convenience to readers, it incorporates the changes dictated by the accumulated errata (available at http://www.w3.org/XML/xml-V10-4e-errata) to the Fourth Edition of XML 1.0, dated 16 August 2006. In particular, erratum [E09] relaxes the restrictions on element and attribute names, thereby providing in XML 1.0 the major end user benefit currently achievable only by using XML 1.1. As a consequence, many possible documents which were not well-formed according to previous editions of this specification are now well-formed, and previously invalid documents using the newly-allowed name characters in, for example, ID attributes, are now valid.
この版は2006年8月16日に公開した第四版のW3C勧告に取って代わる。
This edition supersedes the previous W3C Recommendation of 16 August 2006.
この文書に誤りを見つけたら、是非とも公開メーリングリストxml-editor@w3.orgに報告してほしい。過去の投稿も公開されている。また、読者の簡便の為、修正箇所が色分けされたXHTML版も用意されている。これは、一つ前の版の正誤表に載っている誤りを目立たせ、その正誤情報を扱っている箇所にリンクしてある。誤りの殆どは、修正の根拠が説明されている。この第五版の正誤表はhttp://www.w3.org/XML/xml-V10-5e-errataで見られる。
Please report errors in this document to the public xml-editor@w3.org mail list; public archives are available. For the convenience of readers, an XHTML version with color-coded revision indicators is also provided; this version highlights each change due to an erratum published in the errata list for the previous edition, together with a link to the particular erratum in that list. Most of the errata in the list provide a rationale for the change. The errata list for this fifth edition is available at http://www.w3.org/XML/xml-V10-5e-errata.
[訳者註開始]
訳者註
翻訳版の誤りは、是非Hiroaki Hasegawaまでお知らせ下さい。
[訳者註終了]
実装の報告はhttp://www.w3.org/XML/2008/01/xml10-5e-implementation.htmlで見られる。この仕様への適合度評価を助ける為、Test Suiteが提供されている。
An implementation report is available at http://www.w3.org/XML/2008/01/xml10-5e-implementation.html. A Test Suite is maintained to help assessing conformance to this specification.
この文書は、W3C会員、ソフトウェア開発者や、W3Cの他のグループ、またこれに興味を持った団体によって審査され、W3C勧告として公開しても問題無いとW3Cディレクターに認められたものである。この文書は安定しており、リファレンスとして使ったり、他の文書から引用したりしても構わない。W3Cが勧告文書を作るのは、仕様書に注意を集め、その仕様が広く普及する事を促す為である。これは、ウェブの機能性と相互運用性を高めるのに役立つ。
This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
W3Cは、W3Cの提供する文書と関係するすべての特許情報開示の公開リストを提供する。リストを提供する文書では、特許情報を開示する為の方法も書かれている。Essential Claim(s)を含んでいると考えられる特許について実際の情報を知っている者は、W3C Patent Policyのセクション6に従ってその情報を開示しなければならない。
W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 導入 Introduction
1.1 始まりと目標 Origin and Goals
1.2 専門用語 Terminology
2 文書 Document
2.1 整形式のXML文書 Well-Formed XML Documents
2.2 文字 Characters
2.3 一般的な構文構成子 Common Syntactic Constructs
2.4 文字データとマークアップ Character Data and Markup
2.5 コメント Comments
2.6 処理命令 Processing Instructions
2.7 CDATAセクション CDATA Sections
2.8 プロローグと文書型宣言 Prolog and Document Type Declaration
2.9 スタンドアローン文書宣言 Standalone Document Declaration
2.10 ホワイトスペースの取り扱い White Space Handling
2.11 行末の取り扱い End-of-Line Handling
2.12 言語識別 Language Identification
3 論理構造 Logical Structures
3.1 開始タグ、終了タグ、空要素タグ Start-Tags, End-Tags, and Empty-Element Tags
3.2 要素型宣言 Element Type Declarations
3.2.1 要素内容 Element Content
3.2.2 混合内容 Mixed Content
3.3 属性リスト宣言 Attribute-List Declarations
3.3.1 属性型 Attribute Types
3.3.2 属性デフォルト Attribute Defaults
3.3.3 属性値正規化 Attribute-Value Normalization
3.4 条件付きセクション Conditional Sections
4 物理構造 Physical Structures
4.1 文字参照と実体参照 Character and Entity References
4.2 実体宣言 Entity Declarations
4.2.1 内部実体 Internal Entities
4.2.2 外部実体 External Entities
4.3 解析対象実体 Parsed Entities
4.3.1 テキスト宣言 The Text Declaration
4.3.2 整形式の解析対象実体 Well-Formed Parsed Entities
4.3.3 実体で使われる文字エンコーディング Character Encoding in Entities
4.4 XMLプロセッサによる実体と参照の扱い XML Processor Treatment of Entities and References
4.4.1 認識されない Not Recognized
4.4.2 インクルードされる Included
4.4.3 妥当性を検証する場合インクルードされる Included If Validating
4.4.4 許されない Forbidden
4.4.5 リテラルの中でインクルードされる Included in Literal
4.4.6 通知する Notify
4.4.7 バイパスされる Bypassed
4.4.8 パラメータ実体としてインクルードされる Included as PE
4.4.9 エラー Error
4.5 実体の置換テキストの構築 Construction of Entity Replacement Text
4.6 定義済み実体 Predefined Entities
4.7 記法宣言 Notation Declarations
4.8 文書実体 Document Entity
5 適合性 Conformance
5.1 妥当性を検証するプロセッサとしないプロセッサ Validating and Non-Validating Processors
5.2 XMLプロセッサの使用 Using XML Processors
6 仕様書の記法 Notation
A 参考文献 References
A.1 規範的な参考文献 Normative References
A.2 その他の参考文献 Other References
B 文字クラス Character Classes
C XMLとSGML XML and SGML (非規範的) (Non-Normative)
D 実体参照と文字参照の展開 Expansion of Entity and Character References (非規範的) (Non-Normative)
E 決定的内容モデル Deterministic Content Models (非規範的) (Non-Normative)
F 文字エンコーディングの自動検知 Autodetection of Character Encodings (非規範的) (Non-Normative)
F.1 外部エンコーディング情報を使わない検知 Detection Without External Encoding Information
F.2 外部エンコーディング情報が存在する時の優先度 Priorities in the Presence of External Encoding Information
G W3C XML Working Group W3C XML Working Group (非規範的) (Non-Normative)
H W3C XML Core Working Group W3C XML Core Working Group (非規範的) (Non-Normative)
I 生成メモ Production Notes (非規範的) (Non-Normative)
J XML名前の為の提案 Suggestions for XML Names (非規範的)(Non-Normative)
Extensible Markup Language(XMLと略される)は、XML文書と呼ばれるデータオブジェクトのクラスを説明する。また、XMLを処理するコンピュータプログラムの動作の一部も説明する。XMLはSGML(Standard Generalized Markup Language [ISO 8879])のアプリケーションプロファイルであるか、制限された形式のものである。構造上、XML文書はSGML文書に適合する。
Extensible Markup Language, abbreviated XML, describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them. XML is an application profile or restricted form of SGML, the Standard Generalized Markup Language [ISO 8879]. By construction, XML documents are conforming SGML documents.
XML文書は、実体と呼ばれる記録単位から成る。実体は、解析対象となるデータ、ならないデータの何れかを持つ。解析対象となるデータは文字から成る。文字は、幾つかが集まって文字データを作る事もあるし、マークアップを作る事もある。マークアップは、文書の記録データの配置や、論理構造についての情報をエンコードする。XMLは、記録データの配置や論理構造についての制約を課す機構を提供する。
XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure.
[定義: XMLプロセッサと呼ばれるソフトウェアモジュールは、XML文書を読み込み、その内容と構造にアクセスする手段を提供する為に使われる。] [定義: XMLプロセッサは、別のモジュールで、XMLプロセッサが提供する内容・構造を利用する為に使われると考えられる。この、XMLプロセッサを利用するモジュールをアプリケーションと呼ぶ。] この仕様書では、アプリケーションに渡さなければならないXMLデータや情報を読み取るに当たって、XMLプロセッサに必要とされる動作を説明する。
[Definition: A software module called an XML processor is used to read XML documents and provide access to their content and structure.] [Definition: It is assumed that an XML processor is doing its work on behalf of another module, called the application.] This specification describes the required behavior of an XML processor in terms of how it must read XML data and the information it must provide to the application.
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:
XMLが、インターネットのどこでもそのまま使える事。
XML shall be straightforwardly usable over the Internet.
XMLが多岐に渡るアプリケーションの役に立つ事。
XML shall support a wide variety of applications.
XMLがSGMLと互換性を持っている事。
XML shall be compatible with SGML.
XML文書を処理するプログラムを書く事が簡単である事。
It shall be easy to write programs which process XML documents.
XMLの、実装によってばらつきが出るような機能が限りなく少なく保たれる事……理想を言えば、そんな機能が全く無い事。
The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
XML文書が、できれば人間にも読みやすく、道理に適ってすっきりしている事。
XML documents should be human-legible and reasonably clear.
XMLの設計が、できれば素早く用意される事。
The XML design should be prepared quickly.
XMLの設計が、きちんとした形式でありながら同時に簡潔である事。
The design of XML shall be formal and concise.
XML文書を作る事が簡単である事。
XML documents shall be easy to create.
XMLのマークアップにおいては、(厳密さに比べて)簡潔さは全然重要でない事。
Terseness in XML markup is of minimal importance.
この仕様書には、関連する標準規格(文字に関してはUnicode [Unicode]とISO/IEC 10646 [ISO/IEC 10646]、言語識別タグに関してはInternet BCP 47 [IETF BCP 47]とLanguage Subtag Registry [IANA-LANGCODES])と共に読む事で、XML バージョン1.0を理解し、それを処理する事のできるコンピュータプログラムを構築する為に必要なすべての情報が書かれている。
This specification, together with associated standards (Unicode [Unicode] and ISO/IEC 10646 [ISO/IEC 10646] for characters, Internet BCP 47 [IETF BCP 47] and the Language Subtag Registry [IANA-LANGCODES] for language identification tags), 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.
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:
[訳者註開始]
訳者註
[IETF RFC 2119]で定義されるキーワード、即ちMUSTからOPTIONALまでが強調されて使われている場合、この翻訳版でも括弧書きでキーワードを添えるようにしています。これらのキーワードに対応する日本語として、この翻訳版では、しなければならない(MUST)、してはならない(MUST NOT)、必須とされる(REQUIRED)、すべきである(SHALL)、すべきでない(SHALL NOT)、望ましい(SHOULD)、望ましくない(SHOULD NOT)、推奨される(RECOMMENDED)、しても良い(MAY)、任意である(OPTIONAL)などという表現を使います。正確な定義やニュアンスを知るには[IETF RFC 2119]を読んでもらいたいのですが、特に、すべきである(SHALL)とすべきでない(SHALL NOT)は絶対的な要件(強制)、望ましい(SHOULD)と望ましくない(SHOULD NOT)は最大限の推奨(強制ではない)である事に気を付けて下さい。
[訳者註終了]
[定義: この仕様書で定められる規則に対する違反。その結果は定義されない。特別な記述が無い限り、この仕様書で、しなければならない(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.]
[定義: 仕様に適合する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).]
[定義: 仕様に適合するソフトウェアは、そこで説明されているような動作をしても良い(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.]
[定義: すべての妥当な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.]
[定義: すべての整形式なXML文書に適用される規則。整形式性制約に対する違反は致命的エラーである。]
[Definition: A rule which applies to all well-formed XML documents. Violations of well-formedness constraints are fatal errors.]
[定義: (文字列や名前がマッチする:) 比較対象の二つの文字列、あるいは比較対象の二つの名前があらゆる点で一致する。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で得られます。
[訳者註終了]
[定義: XMLがSGMLと互換性を持つようにする為だけに付け加えられたXMLの機能を説明する文章に付く句。]
[Definition: Marks a sentence describing a feature of XML included solely to ensure that XML remains compatible with SGML.]
[定義: 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.]
[定義: データオブジェクトは、この仕様書で定義するように整形式であるならば、XML文書となる。加えて、更なる所定の制約を満たす時、XML文書は妥当となる。]
[Definition: A data object is an XML document if it is well-formed, as defined in this specification. In addition, the XML document is valid if it meets certain further constraints.]
各XML文書は、論理構造と物理構造を併せ持っている。物理的には、文書は実体と呼ばれる単位から成る。実体は、文書中に取り込む為に他の実体を参照しても良い。文書は「ルート」、即ち文書実体から始まる。論理的には、文書は宣言、要素、コメント、文字参照、そして処理命令から成り、これらはすべて文書の中で明示的にマークアップされて示される。論理構造や物理構造がネストする時は、4.3.2 整形式の解析対象実体 Well-Formed Parsed Entitiesで説明されるように、適切にネストしなければならない(MUST)。
Each XML document has both a logical and a physical structure. Physically, the document is composed of units called entities. An entity may refer to other entities to cause their inclusion in the document. A document begins in a "root" or document entity. Logically, the document is composed of declarations, elements, comments, character references, and processing instructions, all of which are indicated in the document by explicit markup. The logical and physical structures MUST nest properly, as described in 4.3.2 Well-Formed Parsed Entities.
[Definition: 次に挙げる条件をすべて満たす時、テキストオブジェクトは整形式XML文書となる。]
[Definition: A textual object is a well-formed XML document if:]
全体として、document生成規則にマッチする。
Taken as a whole, it matches the production labeled document.
この仕様書が定めるすべての整形式性制約を満たす。
It meets all the well-formedness constraints given in this specification.
文書中で直接的あるいは間接的に参照されるすべての解析対象実体がそれぞれ整形式である。
Each of the parsed entities which is referenced directly or indirectly within the document is well-formed.
[訳者註開始]
訳者註
この翻訳版では、限定用法の"well-formed"に対して「整形式の」を、叙述用法の"well-formed"に対して「整形式である」などを、"well-formedness"に対して「整形式性」を使います。"well-formedness"に対して「整形式性」を使うのは少数派のようですが、この方が正確でしょう。
[訳者註終了]
[1] | document |
::= | ( prolog element Misc* ) |
document生成規則にマッチする事は、次の事をも暗に意味する。
Matching the document production implies that:
一つ以上の要素を含む。
It contains one or more elements.
[定義: ルート、あるいは文書要素と呼ばれる要素がただ一つのみ存在する。ルート要素は、自身の一部あるいは全部が他の要素の内容となる事が一切無い。] ルート要素以外のすべての要素は、その開始タグが他の要素の内容に含まれた時、その終了タグも同じ要素の内容に含まれる。もっと簡単に言えば、要素は開始タグと終了タグでその範囲が定められ、そして互いに適切にネストする。
[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
.]
[定義: 解析対象実体はテキスト、即ち一連の文字を含む。テキストはマークアップか文字データを表す。] [定義: 文字は、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.]
[2] | Char |
::= | #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] |
/* サロゲートブロック、FFFE、FFFFを除くすべてのUnicode文字。 any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ |
文字コード点をビットパターンにエンコードする機構は、実体によって異なっていても良い。すべての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.
メモ Note:
文書の著者には、[Unicode]のセクション2.3で定義されている「互換性文字」を使わない事をお勧めする。次の範囲にある文字も、使用を避けた方が良い。これらの文字は制御文字であるか、この先永遠に定義される事が無いUnicode文字である。
Document authors are encouraged to avoid "compatibility characters", as defined in section 2.3 of [Unicode]. The characters defined in the following ranges are also discouraged. They are either control characters or permanently undefined Unicode characters:
[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF], [#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].
このセクションでは、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.
[3] | S |
::= | ( #x20 | #x9 | #xD | #xA )+ |
メモ Note:
上記の生成規則に#xDが含まれているのは、ただ単に第一版との後方互換性を確保する為である。2.11 行末の取り扱い End-of-Line Handlingで説明されているように、XML文書に直接現れる#xD文字は、他の処理をするよりも前に、除去されるか、あるいは#xA文字に置換される。#xD文字をこの生成規則にマッチさせる唯一の方法は、実体値リテラルの中で文字参照を使う事である。
The presence of #xD in the above production is maintained purely for backward compatibility with the First Edition. As explained in 2.11 End-of-Line Handling, all #xD characters literally present in an XML document are either removed or replaced by #xA characters before any other processing is done. The only way to get a #xD character to match this production is to use a character reference in an entity value literal.
Nmtoken(名前トークン)は名前文字を任意に組み合わせたものである。
An Nmtoken (name token) is any mixture of name characters.
[定義: Nameは、Nmtokenに頭文字の制約を課したものの集合である。] 数字、発音区別記号、終止符、ハイフンをNameの頭文字として使う事は許されない。
[Definition: A Name is an Nmtoken with a restricted set of initial characters.] Disallowed initial characters for Names include digits, diacritics, the full stop and the hyphen.
文字列"xml
"から始まる名前や、(('X'|'x')('M'|'m')('L'|'l'))
にマッチする文字列から始まる名前は、この仕様書のこのバージョン及び将来のバージョンにおける標準化の為に予約されている。
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.
メモ Note:
勧告文書Napespaces in XML [XML Names]で、コロンを含む名前に特殊な意味を割り当てている。それ故、文書の著者が、名前空間として使う以外の目的でコロンをXML名前に使う事は望ましくない。しかし、XMLプロセッサは、コロンを名前文字として受け容れなければならない。
The Namespaces in XML Recommendation [XML Names] assigns a meaning to names containing colon characters. Therefore, authors should not use the colon in XML names except for namespace purposes, but XML processors must accept the colon as a name character.
Nameの最初の文字はNameStartCharでなければならい(MUST)。同時に、名前の二文字目以降の文字はNameCharでなければならない(MUST)。この機構が使われるのは、ASCIIの欧州数字や、基本的結合文字から始まる事を避ける為である。名前に使える文字は、区切り子として使われるもの、あるいは区切り子として使われたとしても合理的なものを除く殆どすべての文字である。その意図は排他的ではなく非排他的であり、まだUnicodeでエンコードされていない記述体系もXML名前で使えるようにする為のものである。なお、新しいXML名前を作る際にはJ 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 J 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.
[4] | NameStartChar |
::= | ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF] |
[4a] | NameChar |
::= | NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040] |
[5] | Name |
::= | NameStartChar ( NameChar )* |
[6] | Names |
::= | Name ( #x20 Name )* |
[7] | Nmtoken |
::= | ( NameChar )+ |
[8] | Nmtokens |
::= | Nmtoken ( #x20 Nmtoken )* |
メモ Note:
Names及びNmtokens生成規則は、正規化後のトークン化された属性値の妥当性を定義する為に使われる。3.3.1 属性型 Attribute Typesを参照してほしい。
The Names and Nmtokens productions are used to define the validity of tokenized attribute values after normalization (see 3.3.1 Attribute Types).
リテラルデータは、引用符で括られた文字列である。但し、文字列の区切り子として使われている引用符をその中に含む事はできない。リテラルは内部エンティティの内容(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.
[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] | [-'()+,./:=?;!*#@$_%] |
メモ Note:
EntityValue生成規則は、単独の<
を直接の値とする一般実体の定義(例えば<!ENTITY mylt "<">
)を許してしまうが、このような実体を実際に定義する事は避けるよう強くお薦めする。その実体への参照が整形式性制約エラーを引き起こしてしまうからである。
Although the EntityValue production allows the definition of a general entity consisting of a single explicit <
in the literal (e.g., <!ENTITY mylt "<">
), it is strongly advised to avoid this practice since any reference to that entity will cause a well-formedness error.
テキストは文字データとマークアップを混ぜ合わせたものから成る。 [定義: マークアップは、次のような形態を採る。開始タグ、終了タグ、空要素タグ、実体参照、文字参照、コメント、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 ""
".
[14] | CharData |
::= | [^<&]* - ( [^<&]* ']]>' [^<&]* ) |
[定義: コメントは、他のマークアップの外になら、どこに現れても良い。加えて、文書型宣言の中にも、文法が許す場所になら現れて良い。コメントは文書の文字データの一部ではない。故に、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.
[15] | Comment |
::= | '<!--' ( ( Char - '-' ) | ( '-' ( Char - '-' ) ) )* '-->' |
コメントの一例を挙げる。
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--->
[定義: 処理命令(PIと略される事もある)は、文書中にアプリケーションへの命令を記述するものである。]
[Definition: Processing instructions (PIs) allow documents to contain instructions for applications.]
[16] | PI |
::= | '<?' PITarget ( S ( Char* - ( Char* '?>' Char* ) ) )? '?>' |
[17] | PITarget |
::= | Name - ( ( 'X' | 'x' ) ( 'M' | 'm' ) ( 'L' | 'l' ) ) |
処理命令は文書の文字データの一部ではないが、アプリケーションに渡されなければならない(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.
[定義: 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 "]]>
":]
[18] | CDSect |
::= | CDStart CData CDEnd |
[19] | CDStart |
::= | '<![CDATA[' |
[20] | CData |
::= | ( Char* - ( Char* ']]>' Char* ) ) |
[21] | CDEnd |
::= | ']]>' |
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>]]>
[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.
[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 |
::= | '1.' [0-9]+ |
[27] | Misc |
::= | Comment | PI | S |
VersionNum生成規則は'1.x'の形であればあらゆるバージョン番号にマッチするが、XML 1.0文書が'1.0'以外のバージョン番号を指定する事は望ましくない(SHOULD NOT)。
Even though the VersionNum production matches any version number of the form '1.x', XML 1.0 documents SHOULD NOT specify a version number other than '1.0'.
メモ Note:
XML 1.0プロセッサが'1.0'ではない'1.x'形式のバージョン番号が指定された文書に出くわした場合、プロセッサはXML 1.0文書として処理するだろう。これは、1.xの文書であっても、XML 1.0で定められた機能のみを使っている限り、XML 1.0プロセッサによって受理されるだろう事を意味する。
When an XML 1.0 processor encounters a document that specifies a 1.x version number other than '1.0', it will process it as a 1.0 document. This means that an XML 1.0 processor will accept 1.x documents provided they do not use any non-1.0 features.
[定義: 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.
[28] | doctypedecl |
::= | '<!DOCTYPE' S Name ( S ExternalID )? S? ( '[' intSubset ']' S? )? '>' |
[妥当性制約: ルート要素の型] |
[整形式性制約: 外部サブセット] | ||||
[28a] | DeclSep |
::= | PEReference | S |
[整形式性制約: 宣言の間のパラメータ実体] |
[28b] | intSubset |
::= | ( markupdecl | DeclSep )* |
|
[29] | markupdecl |
::= | elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | Comment |
[妥当性制約: 宣言とパラメータ実体の適切なネスト] |
[整形式性制約: 内部サブセットの中のパラメータ実体] |
外部サブセットを指さず、内部サブセットも含まない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.
妥当性制約: ルート要素の型 Validity constraint: Root Element Type
文書型宣言のNameは、ルート要素の要素型にマッチしなければならない(MUST)。
The Name in the document type declaration MUST match the element type of the root element.
妥当性制約: 宣言とパラメータ実体の適切なネスト Validity constraint: Proper Declaration/PE Nesting
パラメータ実体の置換テキストは、マークアップ宣言に関して、適切にネストされなければならない(MUST)。それはつまり、マークアップ宣言(上記のmarkupdecl)の最初の文字か最後の文字の何れかがパラメータ実体参照の置換テキストに含まれる場合、両方とも同じ置換テキストの中に含まれなければならない(MUST)という事である。
Parameter-entity replacement text MUST be properly nested with markup declarations. That is to say, if either the first character or the last character of a markup declaration (markupdecl above) is contained in the replacement text for a parameter-entity reference, both MUST be contained in the same replacement text.
整形式性制約: 内部サブセットの中のパラメータ実体 Well-formedness constraint: PEs in Internal Subset
内部DTDサブセットの中では、パラメータ実体参照はマークアップ宣言の中に現れてはならない(MUST NOT)。マークアップ宣言が現れ得る場所に現れる事はあっても良い。この制約は、外部パラメータ実体の中に現れる参照や、外部サブセットには適用されない。
In the internal DTD subset, parameter-entity references MUST NOT occur within markup declarations; they may occur where markup declarations can occur. (This does not apply to references that occur in external parameter entities or to the external subset.)
整形式性制約: 外部サブセット Well-formedness constraint: External Subset
外部サブセットを使用する場合は、その外部サブセットは生成規則extSubsetにマッチしなければならない(MUST)。
The external subset, if any, MUST match the production for extSubset.
宣言の間のパラメータ実体 Well-formedness constraint: PE Between Declarations
DeclSepのパラメータ実体参照の置換テキストは、生成規則extSubsetDeclにマッチしなければならない(MUST)。
The replacement text of a parameter entity reference in a DeclSep MUST match the production extSubsetDecl.
内部サブセットと同様、外部サブセットや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.
[30] | extSubset |
::= | TextDecl? extSubsetDecl |
[31] | extSubsetDecl |
::= | ( markupdecl | conditionalSect | DeclSep )* |
外部サブセットと外部パラメータ実体は、パラメータ実体参照が、マークアップ宣言の間だけではなくマークアップ宣言の中でも許されるという点においても、内部サブセットと異なる。
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.
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).]
[32] | SDDecl |
::= | S 'standalone' Eq ( ( "'" ( 'yes' | 'no' ) "'" ) | ( '"' ( 'yes' | 'no' ) '"' ) ) |
[妥当性制約: スタンドアローン文書宣言] |
スタンドアローン文書宣言では、値"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.
妥当性制約: スタンドアローン文書宣言 Validity constraint: Standalone Document Declaration
スタンドアローン文書宣言は、外部マークアップ宣言の何れかが次の何れかを宣言した時、必ず値"no"を持たなければならない(MUST)。
The standalone document declaration MUST have the value "no" if any external markup declarations contain declarations of:
デフォルト値を持つ属性。但し、文書中に、その属性が適用されるにも拘わらずその属性に値を指定しなかった要素が現れる時に限る。
attributes with default values, if elements to which these attributes apply appear in the document without specifications of values for these attributes, or
amp
、lt
、gt
、apos
、quot
以外の実体。但し、それらの実体への参照が文書中に現れる時に限る。
entities (other than amp
, lt
, gt
, apos
, quot
), if references to those entities appear in the document, or
トークン化対象型の属性。但し、正規化によって、その宣言が無かった時と比べて異なる値が生成されるような値と共にその属性が文書中に現れる場合に限る。
attributes with tokenized types, where the attribute appears in the document with a value such that normalization will produce a different value from that which would be produced in the absence of the declaration, or
要素内容を持つ要素型。但し、その型のインスタンスの何れかが直接ホワイトスペースを含む時に限る。
element types with element content, if white space occurs directly within any instance of those types.
[訳者註開始]
訳者註
インスタンス(instance)について。Oxford Dictionary of ENGLISH Second editionのinstanceの項を見てみると、nounとしてan example or single occurrence of something
と載っています。つまり、要素型のインスタンス(an instance of an element type)とは、「要素型という型に当てはめる事ができる、文書中に現れるもの」("a single occurrence of an element type")と言えます。それはつまり要素(Element)の事です。この仕様書では属性のインスタンスという表現も使われます。これはつまり属性指定(Attribute Specification)の事です。
[訳者註終了]
スタンドアローン文書宣言を持つXML宣言の一例を挙げる。
An example XML declaration with a standalone document declaration:
<?xml version="1.0" standalone='yes'?>
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.
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.
文書を処理する際、その内容がどの自然言語あるいは形式言語で書かれているかを識別すると便利になる事がしばしばある。そこで、xml:lang
という名前の特別な属性を、XML文書の中の要素の内容や属性値で使われている言語を指定する為に、文書中に挿入しても良い。妥当な文書では、この属性は──他のすべての属性と同じように──使われる場合には宣言されなければならない(MUST)。この属性の値は、Tags for the Identification of Languages [IETF BCP 47]で定義される言語識別子である。空の文字列を指定しても良い。
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 BCP 47], Tags for the Identification of Languages; 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
.
メモ Note:
言語の情報は、外部の転送プロトコル(例えばHTTPやMIMEなど)によって提供される事がある。もしあれば、XMLアプリケーションはその情報を使用しても良いが、xml:lang
で提供されるより局所的な情報はそれを上書きするものと見なされる事が望ましい。
Language information may also be provided by external transport protocols (e.g. HTTP or MIME). When available, this information may be used by XML applications, but the more local information provided by xml:lang
should be considered to override it.
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'>
[定義: XML文書は何れも、一つ以上の要素を含む。要素の境界は開始タグと終了タグによって定められるが、空要素の場合は、空要素タグによって定められる。要素は型を持っており、名前で識別される。この名前は「共通識別子」(GI)と呼ばれる事が時々ある。要素は属性指定の組を持つ事もある。] 各属性指定は名前と値を持つ。
[Definition: Each XML document contains one or more elements, the boundaries of which are either delimited by start-tags and end-tags, or, for empty elements, by an empty-element tag. Each element has a type, identified by name, sometimes called its "generic identifier" (GI), and may have a set of attribute specifications.] Each attribute specification has a name and a value.
[39] | element |
::= | EmptyElemTag |
|
| STag content ETag |
[整形式性制約: 要素型のマッチ] | |||
[妥当性制約: 妥当な要素] |
この仕様書は、アプリケーションにおける意味や、使い方、また(構文の域を超えた)要素型や属性の名前については制約を課さない。但し、(('X'|'x')('M'|'m')('L'|'l'))
にマッチする文字列から始まる名前はこの仕様書のこのバージョン及び将来のバージョンにおける標準化の為に予約されている。
This specification does not constrain the application semantics, use, or (beyond syntax) names of the element types and attributes, except that names beginning with a match to (('X'|'x')('M'|'m')('L'|'l'))
are reserved for standardization in this or future versions of this specification.
整形式性制約: 要素型のマッチ Well-formedness constraint: Element Type Match
要素の終了タグのNameは、その要素の開始タグの要素型にマッチしなければならない(MUST)。
The Name in an element's end-tag MUST match the element type in the start-tag.
妥当性制約: 妥当な要素 Validity constraint: Element Valid
要素は、要素型がマッチするNameを持つ、elementdeclにマッチする宣言があり、更に次の何れかの条件を満たす時妥当となる。
An element is valid if there is a declaration matching elementdecl where the Name matches the element type, and one of the following holds:
宣言がEMPTYにマッチし、要素は何ら内容を持たない(実体参照、コメント、処理命令、ホワイトスペースなどですら含んではならない)。
The declaration matches EMPTY and the element has no content (not even entity references, comments, PIs or white space).
宣言がchildrenにマッチし、一連の子要素が、内容モデルの正規表現から生成される集合(言語)に属する。但し、ホワイトスペース、コメント、処理命令(つまり、生成規則[27] Miscにマッチするマークアップ)が、開始タグと最初の子要素の間、子要素と子要素の間、最後の子要素と終了タグの間に現れても良い。注意してほしいのは、ホワイトスペースのみを含むCDATAセクションや、ホワイトスペースに展開される文字参照を置換テキストに持つ実体への参照は非終端のSにマッチしない事である。この為、これらはMiscが現れ得る場所に現れる事ができない。しかし、ホワイトスペースに展開される文字参照から成るリテラル値を持つ内部実体への参照はSにマッチする。これは、その置換テキストが文字参照を展開した後のホワイトスペースになるからである。
The declaration matches children and the sequence of child elements belongs to the language generated by the regular expression in the content model, with optional white space, comments and PIs (i.e. markup matching production [27] Misc) between the start-tag and the first child element, between child elements, or between the last child element and the end-tag. Note that a CDATA section containing only white space or a reference to an entity whose replacement text is character references expanding to white space do not match the nonterminal S, and hence cannot appear in these positions; however, a reference to an internal entity with a literal value consisting of character references expanding to white space does match S, since its replacement text is the white space resulting from expansion of the character references.
宣言がMixedにマッチし、(すべての実体参照をそれぞれの置換テキストで置き換えた後の)要素の内容が、文字データ(CDATAセクションを含む)、コメント、処理命令、要素型が内容モデルに含まれる名前にマッチする子要素から成る。
The declaration matches Mixed, and the content (after replacing any entity references with their replacement text) consists of character data (including CDATA sections), comments, PIs and child elements whose types match names in the content model.
宣言がANYにマッチし、(すべての実体参照をそれぞれの置換テキストで置き換えた後の)要素の内容が、文字データ、CDATAセクション、コメント、処理命令、既に宣言されている要素型を持つ子要素から成る。
The declaration matches ANY, and the content (after replacing any entity references with their replacement text) consists of character data, CDATA sections, comments, PIs and child elements whose types have been declared.
[定義: 空でないXML要素の始まりは、すべて開始タグで示される。]
[Definition: The beginning of every non-empty XML element is marked by a start-tag.]
[40] | STag |
::= | '<' Name ( S Attribute )* S? '>' |
[整形式性制約: 一意な属性指定] |
[41] | Attribute |
::= | Name Eq AttValue |
[妥当性制約: 属性値の型] |
[整形式性制約: 一切無い外部実体参照] | ||||
[整形式性制約: 属性値の中に一切無い<] |
開始タグと終了タグの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.
整形式性制約: 一意な属性指定 Well-formedness constraint: Unique Att Spec
すべての属性名は、同じ開始タグあるいは同じ空要素タグの中で二回以上現れてはならない(MUST NOT)。
An attribute name MUST NOT appear more than once in the same start-tag or empty-element tag.
妥当性制約: 属性値の型 Validity constraint: Attribute Value Type
属性は宣言されていなければならない(MUST)。そして、その値は宣言された型に当てはまるものでなければならない(MUST)。属性型の詳細は3.3 属性リスト宣言 Attribute-List Declarationsで確認して欲しい。
The attribute MUST have been declared; the value MUST be of the type declared for it. (For attribute types, see 3.3 Attribute-List Declarations.)
整形式性制約: 一切無い外部実体参照 Well-formedness constraint: No External Entity References
属性値は、直接的にも間接的にも、外部実体への実体参照を含んではならない(MUST NOT)。
Attribute values MUST NOT contain direct or indirect entity references to external entities.
整形式性制約: 属性値の中に一切無い< Well-formedness constraint: No <
in Attribute Values
属性値の中で直接的あるいは間接的に参照されるすべての実体の置換テキストは、<を含んではならない(MUST NOT)。
The replacement text of any entity referred to directly or indirectly in an attribute value MUST NOT contain a <
.
開始タグの一例を挙げる。
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:]
[42] | ETag |
::= | '</' Name S? '>' |
終了タグの一例を挙げる。
An example of an end-tag:
</termdef>
[定義: 開始タグと終了タグに挟まれたテキストは、要素の内容と呼ばれる。]
[Definition: The text between the start-tag and end-tag is called the element's content:]
[43] | content |
::= | CharData? ( ( element | Reference | CDSect | PI | Comment ) CharData? )* |
[定義: 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:]
[44] | EmptyElemTag |
::= | '<' Name ( S Attribute )* S? '/>' |
[整形式性制約: 一意な属性指定] |
空要素タグは、要素が内容を一切持たないのであれば、その要素がキーワード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/>
妥当性を検証する目的で、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:]
[45] | elementdecl |
::= | '<!ELEMENT' S Name S contentspec S? '>' |
[妥当性制約: 一意な要素型宣言] |
[46] | contentspec |
::= | 'EMPTY' | 'ANY' | Mixed | children |
ここで、Nameは、宣言される要素型を与える。
where the Name gives the element type being declared.
妥当性制約: 一意な要素型宣言 Validity constraint: Unique Element Type Declaration
すべての要素型は、二回以上宣言されてはならない(MUST NOT)。
An element type MUST NOT be declared more than once.
要素型宣言の例を幾つか挙げる。
Examples of element type declarations:
<!ELEMENT br EMPTY> <!ELEMENT p (#PCDATA|emph)* > <!ELEMENT %name.para; %content.para; > <!ELEMENT container ANY>
[定義: ある型の要素が子要素だけを含まなければならない(MUST)時、その要素型は要素内容を持つ。但し、要素内容を持つ型の要素でも、子要素をホワイトスペース(非終端Sにマッチする文字列)で分ける事があっても良い。] [定義: この場合、内容モデルが制約に追加される。内容モデルは、子要素として許される要素の型と、それらが現れ得る順番を支配する簡単な文法である。] この文法は、内容小片(cp)を基礎とする。内容小片は、次のように、名前、内容小片の選択リスト、あるいは内容小片の順序リストから成る。
[Definition: An element type has element content when elements of that type MUST contain only child elements (no character data), optionally separated by white space (characters matching the nonterminal S).] [Definition: In this case, the constraint includes a content model, a simple grammar governing the allowed types of the child elements and the order in which they are allowed to appear.] The grammar is built on content particles (cps), which consist of names, choice lists of content particles, or sequence lists of content particles:
[47] | children |
::= | ( choice | seq ) ( '?' | '*' | '+' )? |
|
[48] | cp |
::= | ( Name | choice | seq ) ( '?' | '*' | '+' )? |
|
[49] | choice |
::= | '(' S? cp ( S? '|' S? cp )+ S? ')' |
[妥当性制約: グループとパラメータ実体の適切なネスト] |
[50] | seq |
::= | '(' S? cp ( S? ',' S? cp )* S? ')' |
[妥当性制約: グループとパラメータ実体の適切なネスト] |
ここで、それぞれのNameは子として現れ得る要素の型である。選択リストに含まれる内容小片は何れも、その選択リストが文法の中で現れる場所に対応する要素内容の中の場所に現れて良い。一方、順序リストに含まれる内容小片はそれぞれ、そのリストで与えられる順番通りに要素内容の中に現れなければならない(MUST)。名前やリストの後ろに任意に付ける事ができる文字は、その要素や内容小片が1回以上(+
)、0回以上(*
)、0回または1回(?
)現れ得るかどうかを支配する。そのような演算子が無い場合は、その要素や内容小片がただ1回だけ現れなければならない(MUST)を意味する。この構文と意味は、この仕様書に登場する生成規則で使われているものと同じである。
where each Name is the type of an element which may appear as a child. Any content particle in a choice list may appear in the element content at the location where the choice list appears in the grammar; content particles occurring in a sequence list MUST each appear in the element content in the order given in the list. The optional character following a name or list governs whether the element or the content particles in the list may occur one or more (+
), zero or more (*
), or zero or one times (?
). The absence of such an operator means that the element or content particle MUST appear exactly once. This syntax and meaning are identical to those used in the productions in this specification.
順序、選択、繰り返し演算子に従って内容モデルを完全に辿る事ができ、なおかつ内容に含まれる要素が内容モデルに含まれる要素型にマッチする時にのみ、その要素の内容は内容モデルにマッチする。互換性の為に、ある要素が内容モデルに現れる二つ以上の要素型に対して、何れにもマッチする事を内容モデルが許した場合はエラーとする。更なる情報はE 決定的内容モデル Deterministic Content Modelsで確認してほしい。
The content of an element matches a content model if and only if it is possible to trace out a path through the content model, obeying the sequence, choice, and repetition operators and matching each element in the content against an element type in the content model. For compatibility, it is an error if the content model allows an element to match more than one occurrence of an element type in the content model. For more information, see E Deterministic Content Models.
妥当性制約: グループとパラメータ実体の適切なネスト Validity constraint: Proper Group/PE Nesting
パラメータ実体の置換テキストは、括弧で囲まれたグループに関して適切にネストされなければならない(MUST)。それはつまり、choice、seq、あるいはMixed構成子の開き括弧か閉じ括弧の何れかがパラメータ実体の置換テキストに含まれる場合、両方とも同じ置換テキストの中に含まれなければならない(MUST)という事である。
Parameter-entity replacement text MUST be properly nested with parenthesized groups. That is to say, if either of the opening or closing parentheses in a choice, seq, or Mixed construct is contained in the replacement text for a parameter entity, both MUST be contained in the same replacement text.
相互運用性の為に、パラメータ実体参照がchoice、seq、あるいはMixed構成子の中に現れる場合は、その置換テキストは最低一つの非空白文字を含む事が望ましく(SHOULD)、また、置換テキストの最初の非空白文字も最後の非空白文字も、接続子(|
や,
)ではない事が望ましい(SHOULD)。
For interoperability, if a parameter-entity reference appears in a choice, seq, or Mixed construct, its replacement text SHOULD contain at least one non-blank character, and neither the first nor last non-blank character of the replacement text SHOULD be a connector (|
or ,
).
要素内容モデルの例を幾つか挙げる。
Examples of element-content models:
<!ELEMENT spec (front, body, back?)> <!ELEMENT div1 (head, (p | list | note)*, div2*)> <!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>
[定義: ある型の要素が文字データを含んで良い時、その要素型は混合内容を持つ。混合内容を持つ型の要素の内容には、随所に子要素を挿入しても良い。] この場合、子要素の型は制約を受けるが、その順番や出現回数は制約を受けない。
[Definition: An element type has mixed content when elements of that type may contain character data, optionally interspersed with child elements.] In this case, the types of the child elements may be constrained, but not their order or their number of occurrences:
[51] | Mixed |
::= | '(' S? '#PCDATA' ( S? '|' S? Name )* S? ')*' |
|
| '(' S? '#PCDATA' S? ')' |
[妥当性制約: グループとパラメータ実体の適切なネスト] | |||
[妥当性制約: 一切無い重複する型] |
ここで、Nameは子として現れ得る要素の型を与える。キーワード#PCDATAは、歴史的な経緯で用語"parsed character data"(「解析対象文字データ」)から採られたものである。
where the Names give the types of elements that may appear as children. The keyword #PCDATA derives historically from the term "parsed character data."
妥当性制約: 一切無い重複する型 Validity constraint: No Duplicate Types
一つの混合内容宣言において、同じ名前が二回以上現れてはならない(MUST NOT)。
The same name MUST NOT appear more than once in a single mixed-content declaration.
混合内容宣言の例を幾つか挙げる。
Examples of mixed content declarations:
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*> <!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* > <!ELEMENT b (#PCDATA)>
属性は、名前と値の組を要素に関連付ける為に使われる。属性指定は開始タグや空要素タグの外に現れてはならない(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:]
[52] | AttlistDecl |
::= | '<!ATTLIST' S Name AttDef* S? '>' |
[53] | AttDef |
::= | S Name S AttType S DefaultDecl |
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.
XML属性型には、文字列型、トークン化対象型、列挙型の三つの種類がある。文字列型は任意のリテラル文字列を値に持つ一方、トークン化対象型はより多くの制約を受ける。文法に註記されている妥当性制約は、3.3.3 属性値の正規化 Attribute-Value Normalizationで説明されるように属性値が正規化された後で適用される。
XML attribute types are of three kinds: a string type, a set of tokenized types, and enumerated types. The string type may take any literal string as a value; the tokenized types are more constrained. The validity constraints noted in the grammar are applied after the attribute value has been normalized as described in 3.3.3 Attribute-Value Normalization.
[54] | AttType |
::= | StringType | TokenizedType | EnumeratedType |
|
[55] | StringType |
::= | 'CDATA' |
|
[56] | TokenizedType |
::= | 'ID' |
[妥当性制約: ID] |
[妥当性制約: 一つの要素型に一つのID] | ||||
[妥当性制約: IDの属性デフォルト] | ||||
| 'IDREF' |
[妥当性制約: IDREF] | |||
| 'IDREFS' |
[妥当性制約: IDREF] | |||
| 'ENTITY' |
[妥当性制約: 実体名] | |||
| 'ENTITIES' |
[妥当性制約: 実体名] | |||
| 'NMTOKEN' |
[妥当性制約: 名前トークン] | |||
| 'NMTOKENS' |
[妥当性制約: 名前トークン] |
妥当性制約: ID Validity constraint: ID
型IDの値はName生成規則にマッチしなければならない(MUST)。ある名前がXML文書の中でこの型として二回以上現れてはならない(MUST NOT)。つまり、ID値はその値を持つ要素を一意に識別しなければならない(MUST)。
Values of type ID MUST match the Name production. A name MUST NOT appear more than once in an XML document as a value of this type; i.e., ID values MUST uniquely identify the elements which bear them.
妥当性制約: 一つの要素型に一つのID Validity constraint: One ID per Element Type
一つの要素型が二つ以上のID属性を持ってはならない(MUST NOT)。
An element type MUST NOT have more than one ID attribute specified.
妥当性制約: IDの属性デフォルト Validity constraint: ID Attribute Default
ID属性は#IMPLIEDか#REQUIREDと宣言されたデフォルトを持たなければならない(MUST)。
An ID attribute MUST have a declared default of #IMPLIED or #REQUIRED.
妥当性制約: IDREF Validity constraint: IDREF
型IDREFの値はName生成規則にマッチしなければならず(MUST)、型IDREFSの値はNamesにマッチしなければならない(MUST)。それぞれのNameは、そのXML文書に含まれるある要素のID属性の値にマッチしなければならない(MUST)。つまり、IDREF値はあるID属性の値にマッチしなければならない(MUST)。
Values of type IDREF MUST match the Name production, and values of type IDREFS MUST match Names; each Name MUST match the value of an ID attribute on some element in the XML document; i.e. IDREF values MUST match the value of some ID attribute.
妥当性制約: 実体名 Validity constraint: Entity Name
型ENTITYの値はName生成規則にマッチしなければならず(MUST)、型ENTITIESの値はNamesにマッチしなければならない(MUST)。それぞれのNameは、DTDで定義された解析対象外実体の名前にマッチしなければならない(MUST)。
Values of type ENTITY MUST match the Name production, values of type ENTITIES MUST match Names; each Name MUST match the name of an unparsed entity declared in the DTD.
妥当性制約: 名前トークン Validity constraint: Name Token
型NMTOKENの値はNmtoken生成規則にマッチしなければならず(MUST)、型NMTOKENSの値はNmtokensにマッチしなければならない(MUST)。
Values of type NMTOKEN MUST match the Nmtoken production; values of type NMTOKENS MUST match Nmtokens.
[定義: 列挙属性は、許される値のリストを宣言に持つ。] 列挙属性は、それらの値の中の一つを持たなければならない(MUST)。列挙属性型には、次のように二種類ある。
[Definition: Enumerated attributes have a list of allowed values in their declaration]. They MUST take one of those values. There are two kinds of enumerated attribute types:
[57] | EnumeratedType |
::= | NotationType | Enumeration |
|
[58] | NotationType |
::= | 'NOTATION' S '(' S? Name ( S? '|' S? Name )* S? ')' |
[妥当性制約: 記法属性] |
[妥当性制約: 一つの要素型に一つの記法] | ||||
[妥当性制約: 空要素に一切無い記法] | ||||
[妥当性制約: 一切無い重複するトークン] | ||||
[59] | Enumeration |
::= | '(' S? Nmtoken ( S? '|' S? Nmtoken )* S? ')' |
[妥当性制約: 列挙] |
[妥当性制約: 一切無い重複するトークン] |
NOTATION属性は、その属性が付けられた要素を解釈する際に使えるようにする為、記法を識別する。記法は、関連付けられたシステム識別子と公開識別子の両方、あるいは片方と共にDTDの中で宣言される。
A NOTATION attribute identifies a notation, declared in the DTD with associated system and/or public identifiers, to be used in interpreting the element to which the attribute is attached.
妥当性制約: 記法属性 Validity constraint: Notation Attributes
この型の値は、その宣言に含まれる記法名の内の一つにマッチしなければならない(MUST)。その宣言が採り得る記法名はすべて宣言されていなければならない(MUST)。
Values of this type MUST match one of the notation names included in the declaration; all notation names in the declaration MUST be declared.
妥当性制約: 一つの要素型に一つの記法 Validity constraint: One Notation Per Element Type
一つの要素型が二つ以上のNOTATION属性を持ってはならない(MUST NOT)。
An element type MUST NOT have more than one NOTATION attribute specified.
妥当性制約: 空要素に一切無い記法 Validity constraint: No Notation on Empty Element
互換性の為に、型NOTATIONの属性はEMPTYと宣言された属性に対して宣言されてはならない(MUST NOT)。
For compatibility, an attribute of type NOTATION MUST NOT be declared on an element declared EMPTY.
妥当性制約: 一切無い重複するトークン Validity constraint: No Duplicate Tokens
NotationType属性宣言のすべての記法名や、Enumeration属性宣言のすべてのNmTokenは、一つの宣言の中では互いに別個のものでなければならない(MUST)。
The notation names in a single NotationType attribute declaration, as well as the NmTokens in a single Enumeration attribute declaration, MUST all be distinct.
妥当性制約: 列挙 Validity constraint: Enumeration
この型の値は、その宣言に含まれるNmtokenトークンの内の一つにマッチしなければならない(MUST)。
Values of this type MUST match one of the Nmtoken tokens in the declaration.
相互運用性の為に、一つの要素型が持つ複数の列挙属性型の間でも、同じNmtokenが二回以上現れる事は望ましくない(SHOULD NOT)。
For interoperability, the same Nmtoken SHOULD NOT occur more than once in the enumerated attribute types of a single element type.
属性宣言は、その属性の存在が必須である(REQUIRED)かどうかについて情報を提供する。もし必須でなければ、宣言された属性が文書中に無かった時にXMLプロセッサがどう対応すべきかについて情報を提供する。
An attribute declaration provides information on whether the attribute's presence is REQUIRED, and if not, how an XML processor is to react if a declared attribute is absent in a document.
[60] | DefaultDecl |
::= | '#REQUIRED' | '#IMPLIED' |
|
| ( ( '#FIXED' S )? AttValue ) |
[妥当性制約: 必須属性] | |||
[妥当性制約: 構文的に正しい属性デフォルト値] | ||||
[整形式性制約: 属性値の中に一切無い<] | ||||
[妥当性制約: 固定属性デフォルト] | ||||
[整形式性制約: 一切無い外部実体参照] |
属性宣言では、#REQUIREDは、その属性が常に提供されなければならない(MUST)事を意味し、#IMPLIEDは、デフォルト値が提供されない事を意味する。 [定義: もし宣言が#REQUIREDでも#IMPLIEDでもなければ、AttValue値は宣言されたデフォルト値を持つ。#FIXEDキーワードは、その属性が常にデフォルト値を持たなければならない(MUST)事を示す。XMLプロセッサは、デフォルト値宣言を読み取ってある属性について、その属性の指定が無い要素を見つけた場合は、その属性が宣言されたデフォルト値を持つものとしてアプリケーションに報告しなければならない(MUST)。]
In an attribute declaration, #REQUIRED means that the attribute MUST always be provided, #IMPLIED that no default value is provided. [Definition: If the declaration is neither #REQUIRED nor #IMPLIED, then the AttValue value contains the declared default value; the #FIXED keyword states that the attribute MUST always have the default value. When an XML processor encounters an element without a specification for an attribute for which it has read a default value declaration, it MUST report the attribute with the declared default value to the application.]
妥当性制約: 必須属性 Validity constraint: Required Attribute
もしデフォルト宣言がキーワード#REQUIREDであれば、属性リスト宣言でその属性が宣言された要素型の要素すべてに対してその属性が指定されなければならない(MUST)。
If the default declaration is the keyword #REQUIRED, then the attribute MUST be specified for all elements of the type in the attribute-list declaration.
妥当性制約: 構文的に正しい属性デフォルト値 Validity constraint: Attribute Default Value Syntactically Correct
宣言されたデフォルト値は、その属性型の構文上の制約を満たさなければならない(MUST)。つまり、次の何れかを満たさなければならない。
The declared default value MUST meet the syntactic constraints of the declared attribute type. That is, the default value of an attribute:
型IDREFや型ENTITYの属性のデフォルト値は、Name生成規則にマッチしなければならない。
of type IDREF or ENTITY must match the Name production;
型IDREFSや型ENTITIESの属性のデフォルト値は、Names生成規則にマッチしなければならない。
of type IDREFS or ENTITIES must match the Names production;
型NMTOKENの属性のデフォルト値は、Nmtoken生成規則にマッチしなければならない。
of type NMTOKEN must match the Nmtoken production;
型NMTOKENSの属性のデフォルト値は、Nmtokens生成規則にマッチしなければならない。
of type NMTOKENS must match the Nmtokens production;
列挙型(NOTATION型や列挙)の属性のデフォルト値は、列挙された値の内の一つにマッチしなければならない。
of an enumerated type (either a NOTATION type or an enumeration) must match one of the enumerated values.
ここでは、その型の構文的な制約だけが必要である事に注意してほしい。他の制約(例えば、型ENTITYの属性では、その値は宣言された解析対象外実体の名前でなければならない、など)は、その属性の指定を持たない要素が実際に現れた時にのみ、妥当性を検証するパーサによって報告されるだろう。
Note that only the syntactic constraints of the type are required here; other constraints (e.g. that the value be the name of a declared unparsed entity, for an attribute of type ENTITY) will be reported by a validating parser only if an element without a specification for this attribute actually occurs.
妥当性制約: 固定属性デフォルト Validity constraint: Fixed Attribute Default
ある属性が#FIXEDキーワードと共に宣言されたデフォルト値を持つ場合は、その属性のインスタンスはそのデフォルト値にマッチしなければならない(MUST)。
If an attribute has a default value declared with the #FIXED keyword, instances of that attribute MUST match the default value.
属性リスト宣言の例を幾つか挙げる。
Examples of attribute-list declarations:
<!ATTLIST termdef id ID #REQUIRED name CDATA #IMPLIED> <!ATTLIST list type (bullets|ordered|glossary) "ordered"> <!ATTLIST form method CDATA #FIXED "POST">
ある属性の値をアプリケーションに渡したり、妥当性を検査したりする前に、XMLプロセッサは、以下に示されるアルゴリズムを適用する事で、属性値を正規化しなければならない(MUST)。アプリケーションに渡される値がこのアルゴリズムによって生成されるものと同じになる他の手段を用いても良い。
Before the value of an attribute is passed to the application or checked for validity, the XML processor MUST normalize the attribute value by applying the algorithm below, or by using some other method such that the value passed to the application is the same as that produced by the algorithm.
このアルゴリズムの残りの部分が正規化されたテキストに対して操作を行えるようにする為、2.11 行末の取り扱い End-of-Line Handlingで説明されているように、入力の改行はすべて#xAに正規化されていなければならない(MUST)。
All line breaks MUST have been normalized on input to #xA as described in 2.11 End-of-Line Handling, so the rest of this algorithm operates on text normalized in this way.
空の文字列から成る正規化済み値を準備する。
Begin with a normalized value consisting of the empty string.
未正規化値の最初から最後まで、文字、実体参照、文字参照それぞれについて、次の事を行う。
For each character, entity reference, or character reference in the unnormalized attribute value, beginning with the first and continuing to the last, do the following:
文字参照について、参照された文字を正規化済み値に追加する。
For a character reference, append the referenced character to the normalized value.
実体参照について、このアルゴリズムのステップ3をその実体の置換テキストに再帰的に適用する。
For an entity reference, recursively apply step 3 of this algorithm to the replacement text of the entity.
ホワイトスペース文字(#x20、#xD、#xA、#x9)について、スペース文字(#x20)を正規化済み値に追加する。
For a white space character (#x20, #xD, #xA, #x9), append a space character (#x20) to the normalized value.
その他の文字について、その文字をそのまま正規化済み値に追加する。
For another character, append the character to the normalized value.
属性型がCDATAでなければ、XMLプロセッサは更に正規化済み値に対して、先頭や末尾のスペース文字(#x20)列を取り除き、他のスペース文字(#x20)列を一つのスペース文字(#x20)で置き換える処理をしなければならない(MUST)。
If the attribute type is not CDATA, then the XML processor MUST further process the normalized attribute value by discarding any leading and trailing space (#x20) characters, and by replacing sequences of space (#x20) characters by a single space (#x20) character.
未正規化値が、スペース(#x20)以外のホワイトスペース文字への文字参照を含む場合、正規化済み値は参照された文字そのもの(#xDや#xA、#x9)を含む事に注意してほしい。これは、未正規化値が(参照でない)ホワイトスペース文字を含む場合と対照を成す。その場合、ホワイトスペース文字はスペース文字(#x20)に置き換えられる。また、未正規化値が、置換テキストがホワイトスペース文字を含む実体参照を含む場合とも対照を成す。この場合は、再帰的に処理されて、ホワイトスペース文字は正規化済み値のスペース文字(#x20)に置き換えられる。
Note that if the unnormalized attribute value contains a character reference to a white space character other than space (#x20), the normalized value contains the referenced character itself (#xD, #xA or #x9). This contrasts with the case where the unnormalized value contains a white space character (not a reference), which is replaced with a space character (#x20) in the normalized value and also contrasts with the case where the unnormalized value contains an entity reference whose replacement text contains a white space character; being recursively processed, the white space character is replaced with a space character (#x20) in the normalized value.
妥当性を検証しないプロセッサでは、宣言が読み取られなかった属性はすべてCDATAと宣言されたかの如く扱われる事が望ましい(SHOULD)。
All attributes for which no declaration has been read SHOULD be treated by a non-validating processor as if declared CDATA.
属性値が、宣言が読み取られなかった実体への参照を含んだ場合はエラーとなる。
It is an error if an attribute value contains a reference to an entity for which no declaration has been read.
次に挙げるのは属性正規化の例である。ここでは次の宣言を既に与えられたものとする。
Following are examples of attribute normalization. Given the following declarations:
<!ENTITY d "
"> <!ENTITY a "
"> <!ENTITY da "
">
下の表の左の列に書かれた属性指定は、属性a
がNMTOKENSと宣言されているならば真ん中の列の一連の文字のように、a
がCDATAと宣言されていれば右の列の一連の文字のように正規化される事だろう。
the attribute specifications in the left column below would be normalized to the character sequences of the middle column if the attribute a
is declared NMTOKENS and to those of the right columns if a
is declared CDATA.
属性指定 Attribute specification | aがNMTOKENSの時 a is NMTOKENS | aがCDATAの時 a is 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 #x20 B #x20 #x20 |
a= "

A

B
" |
#xD #xD A #xA #xA B #xD #xA |
#xD #xD A #xA #xA B #xD #xA |
最後の例は、a
が型NMTOKENSとなるよう宣言された場合には妥当でない事に注意してほしい(整形式ではある)。
Note that the last example is invalid (but well-formed) if a
is declared to be of type NMTOKENS.
[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.]
[61] | conditionalSect |
::= | includeSect | ignoreSect |
|
[62] | includeSect |
::= | '<![' S? 'INCLUDE' S? '[' extSubsetDecl ']]>' |
[妥当性制約: 条件付きセクションとパラメータ実体の適切なネスト] |
[63] | ignoreSect |
::= | '<![' S? 'IGNORE' S? '[' ignoreSectContents* ']]>' |
[妥当性制約: 条件付きセクションとパラメータ実体の適切なネスト] |
[64] | ignoreSectContents |
::= | Ignore ( '<![' ignoreSectContents ']]>' Ignore )* |
|
[65] | Ignore |
::= | Char* - ( Char* ( '<![' | ']]>' ) Char* ) |
妥当性制約: 条件付きセクションとパラメータ実体の適切なネスト Validity constraint: Proper Conditional Section/PE Nesting
条件付きセクションの"<![
"や"[
"、"]]>
"などがパラメータ実体参照の置換テキストに含まれる場合、それらのすべてが同じ置換テキストに含まれなければならない(MUST)。
If any of the "<![
", "[
", or "]]>
" of a conditional section is contained in the replacement text for a parameter-entity reference, all of them MUST be contained in the same replacement text.
内部及び外部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?)> ]]>
[定義: XML文書は、一つあるいは多数の記録単位で構成される。これらは実体と呼ばれる。すべての実体は内容を持ち、また、文書実体や外部DTDサブセット以外の実体はすべて実体名で識別される。] それぞれのXML文書は、文書実体と呼ばれる実体を一つずつ持つ。文書実体はXMLプロセッサの開始点となり、文書のすべてを内包する事もある。
[Definition: An XML document may consist of one or many storage units. These are called entities; they all have content and are all (except for the document entity and the external DTD subset) identified by entity name.] Each XML document has one entity called the document entity, which serves as the starting point for the XML processor and may contain the whole document.
実体は解析対象となる事もあるし、ならない事もある。 [定義: 解析対象実体の内容は置換テキストと呼ばれる。このテキストが実際に文書を構成する部分となる。]
Entities may be either parsed or unparsed. [Definition: The contents of a parsed entity are referred to as its replacement text; this text is considered an integral part of the document.]
[定義: 解析対象外実体は、内容がテキストである事もない事もあるリソースである。その内容がテキストの場合、それはXMLではない事もある。解析対象外実体はそれぞれ関連付けられた記法を一つ持つ。記法は名前で識別される。XMLプロセッサが解析対象外実体と記法をアプリケーションから利用可能にする事は要件とするが、XMLではそれ以上の制約、つまり解析対象外実体の内容についての制約は課さない。]
[Definition: An unparsed entity is a resource whose contents may or may not be text, and if text, may be other than XML. Each unparsed entity has an associated notation, identified by name. Beyond a requirement that an XML processor make the identifiers for the entity and notation available to the application, XML places no constraints on the contents of unparsed entities.]
解析対象実体は、実体参照を使い、名前で呼び出される。解析対象外実体も名前で呼び出されるが、その名前はENTITY属性やENTITIES属性の値で与えられる。
Parsed entities are invoked by name using entity references; unparsed entities by name, given in the value of ENTITY or ENTITIES attributes.
[定義: 一般実体は、文書の内容で使う為の実体である。この仕様書では、曖昧でなければ、一般実体が単に実体と呼ばれる事がある。] [定義: パラメータ実体は、DTDで使う為の解析対象実体である。] これら二種類の実体は、参照にも異なる形式を使い、認識されるのも異なる文脈である。更に、これらは異なる名前空間を占める。即ち、同じ名前を持つ一般実体とパラメータ実体は、全く異なる二つの実体である。
[Definition: General entities are entities for use within the document content. In this specification, general entities are sometimes referred to with the unqualified term entity when this leads to no ambiguity.] [Definition: Parameter entities are parsed entities for use within the DTD.] These two types of entities use different forms of reference and are recognized in different contexts. Furthermore, they occupy different namespaces; a parameter entity and a general entity with the same name are two distinct entities.
[定義: 文字参照は、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.]
[66] | CharRef |
::= | '&#' [0-9]+ ';' |
|
| '&#x' [0-9a-fA-F]+ ';' |
[整形式性制約: 使用が認められた文字] |
整形式性制約: 使用が認められた文字 Well-formedness constraint: Legal Character
文字参照を使って参照される文字は、生成規則Charにマッチしなければならない(MUST)。
Characters referred to using character references MUST match the production for Char.
文字参照が"&#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.]
[67] | Reference |
::= | EntityRef | CharRef |
|
[68] | EntityRef |
::= | '&' Name ';' |
[整形式性制約: 宣言された実体] |
[妥当性制約: 宣言された実体] | ||||
[整形式性制約: 解析対象実体] | ||||
[整形式性制約: 一切無い再帰] | ||||
[69] | PEReference |
::= | '%' Name ';' |
[妥当性制約: 宣言された実体] |
[整形式性制約: 一切無い再帰] | ||||
[整形式性制約: DTDの中] |
整形式性制約: 宣言された実体 Well-formedness constraint: Entity Declared
一切のDTDを持たない文書や、パラメータ実体参照を一切含まない内部DTDサブセットしか持たない文書、あるいは"standalone='yes'
"を持つ文書においては、外部サブセットやパラメータ実体の外に現れる実体参照については、その実体参照のNameは、外部サブセットやパラメータ実体の外の実体宣言の内の一つの名前にマッチしなければならない(MUST)。但し、amp
、lt
、gt
、apos
、quot
は例外で、これらの実体を整形式の文書が宣言する必要は無い。一般実体の宣言は、属性リスト宣言のデフォルト値に現れるその実体への参照すべてに先行しなければならない(MUST)。
In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'
", for an entity reference that does not occur within the external subset or a parameter entity, the Name given in the entity reference MUST match that in an entity declaration that does not occur within the external subset or a parameter entity, except that well-formed documents need not declare any of the following entities: amp
, lt
, gt
, apos
, quot
. The declaration of a general entity MUST precede any reference to it which appears in a default value in an attribute-list declaration.
妥当性を検証しないプロセッサは、パラメータ実体の中や外部サブセットの中に現れる実体宣言を読み取ったり処理したりするようには強制されない事に注意してほしい。つまり、妥当性を検証しないプロセッサでは、そのような文書──パラメータ実体参照や外部サブセットを持つ文書においては、standalone='yes'である時にのみ、実体が宣言されなければならないという規則が整形式制約となる。
Note that non-validating processors are not obligated to read and process entity declarations occurring in parameter entities or in the external subset; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'.
妥当性制約: 宣言された実体 Validity constraint: Entity Declared
外部サブセットやパラメータ実体参照を持ち、かつスタンドアローンでない文書("standalone='no'
"と指定されているか、スタンドアローン宣言が無い文書)では、その実体参照のNameは、実体宣言の内の一つの名前にマッチしなければならない(MUST)。相互運用性の為に、妥当な文書は、amp
、lt
、gt
、apos
、quot
の実体を4.6 定義済み実体 Predefined Entitiesで指定される形式で宣言する事が望ましい(SHOULD)。パラメータ実体の宣言は、それへの参照すべてに先行しなければならない(MUST)。同様に、一般実体の宣言は、その一般実体への直接的あるいは間接的な参照を持つデフォルト値を含有する属性リスト宣言すべてに先行しなければならない(MUST)。
In a document with an external subset or parameter entity references, if the document is not standalone (either "standalone='no'
" is specified or there is no standalone declaration), then the Name given in the entity reference MUST match that in an entity declaration. For interoperability, valid documents SHOULD declare the entities amp
, lt
, gt
, apos
, quot
, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity MUST precede any reference to it. Similarly, the declaration of a general entity MUST precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity.
In a document with an external subset or parameter entity references with "standalone='no'
", the Name given in the entity reference MUST match that in an entity declaration. For interoperability, valid documents SHOULD declare the entities amp
, lt
, gt
, apos
, quot
, in the form specified in 4.6 Predefined Entities. The declaration of a parameter entity MUST precede any reference to it. Similarly, the declaration of a general entity MUST precede any attribute-list declaration containing a default value with a direct or indirect reference to that general entity.
整形式性制約: 解析対象実体 Well-formedness constraint: Parsed Entity
実体参照は、解析対象外実体の名前を含んではならない(MUST NOT)。解析対象外実体は、型ENTITYやENTITIESとなるよう宣言された属性値からのみ参照できる。
An entity reference MUST NOT contain the name of an unparsed entity. Unparsed entities may be referred to only in attribute values declared to be of type ENTITY or ENTITIES.
整形式性制約: 一切無い再帰 Well-formedness constraint: No Recursion
解析対象実体は、直接的にも間接的にも、自分自身への再帰的な参照を含んではならない(MUST NOT)。
A parsed entity MUST NOT contain a recursive reference to itself, either directly or indirectly.
整形式性制約: DTDの中 Well-formedness constraint: In DTD
パラメータ実体参照は、DTDの外に現れてはならない(MUST NOT)。
Parameter-entity references MUST NOT appear outside the DTD.
文字参照と実体参照の例を幾つか挙げる。
Examples of character and entity references:
Type <key>less-than</key> (<) 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;
[定義: 実体は次のように宣言される。]
[Definition: Entities are declared thus:]
[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は、実体参照でその実体を識別する為の名前である。解析対象外実体の場合は、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.
[定義: 実体の定義がEntityValueである時、定義された実体は内部実体と呼ばれる。内部実体の定義では他の物理的な記録オブジェクトは使わず、実体の内容はその宣言の中で与えられる。] リテラル実体値での実体参照や文字参照の処理では、正しい置換テキストを生成しなければならない事がある事に注意してほしい。詳しくは4.5 実体の置換テキストの構築 Construction of Entity Replacement Textを参照する事。
[Definition: If the entity definition is an EntityValue, the defined entity is called an internal entity. There is no separate physical storage object, and the content of the entity is given in the declaration.] Note that some processing of entity and character references in the literal entity value may be required to produce the correct replacement text: see 4.5 Construction of Entity Replacement Text.
内部実体は解析対象実体である。
An internal entity is a parsed entity.
内部実体宣言の一例を挙げる。
Example of an internal entity declaration:
<!ENTITY Pub-Status "This is a pre-release of the specification.">
[定義: 実体が内部実体でなければ、外部実体である。外部実体は次のように宣言される。]
[Definition: If the entity is not internal, it is an external entity, declared as follows:]
[75] | ExternalID |
::= | 'SYSTEM' S SystemLiteral |
|
| 'PUBLIC' S PubidLiteral S SystemLiteral |
||||
[76] | NDataDecl |
::= | S 'NDATA' S Name |
[妥当性制約: 宣言された記法] |
NDataDeclが存在すれば、これは一般解析対象外実体となる。さもなくば解析対象実体となる。
If the NDataDecl is present, this is a general unparsed entity; otherwise it is a parsed entity.
[定義: SystemLiteralは、実体のシステム識別子と呼ばれる。これは、[IETF RFC 3986]で定義されるURI参照に変換される事を意図されている。XMLプロセッサがその実体の置換テキストを構築する際の入力を取得する為、そのURI参照が指すものを得る処理に使えるようにである。] (文字#
から始まる)断片識別子がシステム識別子に紛れ込む事はエラーである。この仕様書の範囲外の情報(例えば、特定のDTDで定義される特別なXML要素型や、特定のアプリケーション仕様書で定義される処理命令など)が提供されない限り、相対URIは、その実体宣言が現れたリソースの場所に対するものとする。これは、宣言を開始する'<'が宣言の開始であると解析された時点で、その'<'を含む外部実体のURIが基底URIになるよう定義される。このように、URIは文書実体に対して相対的になる事もあるし、外部DTDサブセットを含む実体に対して、あるいは他の外部パラメータ実体に対して相対的になる事もあり得る。URIで識別されるリソースを入手する試みは、パーサレベルで(例えば、実体解決機構で)リダイレクトされるかも知れないし、更に下層で(プロトコルレベルで、例えばHTTPのLocation:
ヘッダを使って)リダイレクトされるかも知れない。この仕様書の範囲外の追加情報がそのリソース中に無ければ、そのリソースの基底URIは常に、返された実際のリソースのURIである。言葉を換えれば、すべてのリダイレクションが発生した後で入手したリソースのURIが基底URIとなるという事である。
[Definition: The SystemLiteral is called the entity's system identifier. It is meant to be converted to a URI reference (as defined in [IETF RFC 3986]), as part of the process of dereferencing it to obtain input for the XML processor to construct the entity's replacement text.] It is an error for a fragment identifier (beginning with a #
character) to be part of a system identifier. Unless otherwise provided by information outside the scope of this specification (e.g. a special XML element type defined by a particular DTD, or a processing instruction defined by a particular application specification), relative URIs are relative to the location of the resource within which the entity declaration occurs. This is defined to be the external entity containing the '<' which starts the declaration, at the point when it is parsed as a declaration. A URI might thus be relative to the document entity, to the entity containing the external DTD subset, or to some other external parameter entity. Attempts to retrieve the resource identified by a URI may be redirected at the parser level (for example, in an entity resolver) or below (at the protocol level, for example, via an HTTP Location:
header). In the absence of additional information outside the scope of this specification within the resource, the base URI of a resource is always the URI of the actual resource returned. In other words, it is the URI of the resource retrieved after all redirection has occurred.
[訳者註開始]
訳者註
ここでは、便宜の為か相対URI(Relative URI)という用語が使われていますが、これは[IETF RFC 3986]に従うなら相対参照(Relative Reference)と呼ぶべきものです。相対参照はURIのサブセットではありません。URIを参照する方法(a method of referencing URIs
)です。詳しくは、[IETF RFC 3986]の1.2.3. Hierarchical Identifiersや4.2. Relative Referenceを参照して下さい。
また、Aに対して相対的になる
という表現もありますが、これはつまり「AのURIが基底URI(Base URI)になる」という事です。基底URIについての話もありますが、これには[IETF RFC 3986]の5.1. Establishing a Base URIが参考になるでしょう。
[訳者註終了]
システム識別子(とその他のURI参照として使われる事を意図されたXML文字列)は、[IETF RFC 3986]に拠れば、参照されたリソースを入手する為URIを使う前にエスケープされなければならない文字を含む事がある。エスケープされなければならない文字は、#x0から#x1Fまでと#x7Fの制御文字(これらの殆どはXMLでは現れ得ない)、スペース(#x20)、区切り子'<'(#x3C)、'>'(#x3E)、'"'(#x22)、思慮に欠ける文字'{'(#x7B)、'}'(#x7D)、'|'(#x7C)、'\'(#x5C)、'^'(#x5E)、'`'(#x60)、そして#x7Fより大きなコード点を持つすべての文字である。エスケーピングは必ずしも完全に可逆的な処理という訳ではないので、どうしても必要になった時にのみ、一連の処理の中のできるだけ遅い段階で為されなければならない(MUST)。特に、相対URIを絶対URIに変換する処理や、URI参照の指すものを入手しなければならないルーチンあるいはソフトウェアコンポーネントにURI参照を渡す処理は、何れもエスケーピングのきっかけにならない事が望ましい(SHOULD)。本当にエスケープする時は、次のようになされなければならない(MUST)。
System identifiers (and other XML strings meant to be used as URI references) may contain characters that, according to [IETF RFC 3986], must be escaped before a URI can be used to retrieve the referenced resource. The characters to be escaped are the control characters #x0 to #x1F and #x7F (most of which cannot appear in XML), space #x20, the delimiters '<' #x3C, '>' #x3E and '"' #x22, the unwise characters '{' #x7B, '}' #x7D, '|' #x7C, '\' #x5C, '^' #x5E and '`' #x60, as well as all characters above #x7F. Since escaping is not always a fully reversible process, it MUST be performed only when absolutely necessary and as late as possible in a processing chain. In particular, neither the process of converting a relative URI to an absolute one nor the process of passing a URI reference to a process or software component responsible for dereferencing it SHOULD trigger escaping. When escaping does occur, it MUST be performed as follows:
エスケープされる文字が、それぞれUTF-8 [Unicode]を使って、1バイト以上のバイト列で表される。
Each character to be escaped is represented in UTF-8 [Unicode] as one or more bytes.
結果となるバイト列が、URIエスケーピング機構を使ってエスケープされる(つまり、%
HH形式に変換される。ここでHHはそのバイト値の16進数表記である)。
The resulting bytes are escaped with the URI escaping mechanism (that is, converted to %
HH, where HH is the hexadecimal notation of the byte value).
元の文字が結果となる文字列で置き換えられる。
The original character is replaced by the resulting character sequence.
[定義: システム識別子に加えて、外部識別子は公開識別子をも持つ事がある。] 実体の内容を取得しようとするXMLプロセッサは、代替URI参照を生成する為に、この仕様書の範囲外の追加情報に加えて、公開識別子やシステム識別子を使っても良いし、それらの如何なる組み合わせを使っても良い。そうする事ができないのであれば、プロセッサはシステムリテラルで指定されたURI参照を使わなければならない(MUST)。マッチングを試みる前に、公開識別子のホワイトスペースはすべて一つのスペース文字(#x20)に正規化されなければならず(MUST)、また先頭と末尾のホワイトスペースは除去されなければならない(MUST)。
[Definition: In addition to a system identifier, an external identifier may include a public identifier.] An XML processor attempting to retrieve the entity's content may use any combination of the public and system identifiers as well as additional information outside the scope of this specification to try to generate an alternative URI reference. If the processor is unable to do so, it MUST use the URI reference specified in the system literal. Before a match is attempted, all strings of white space in the public identifier MUST be normalized to single space characters (#x20), and leading and trailing white space MUST be removed.
外部実体宣言の例を幾つか挙げる。
Examples of external entity declarations:
<!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 >
外部解析対象実体は、それぞれがテキスト宣言から始まる事が望ましい(SHOULD)。
External parsed entities SHOULD each begin with a text declaration.
[77] | TextDecl |
::= | '<?xml' VersionInfo? EncodingDecl S? '?>' |
テキスト宣言は、解析対象実体への参照を使うのではなく、直接書かれなければならない(MUST)。テキスト宣言は、外部解析対象実体の始まり以外には、あらゆる場所に現れてはならない(MUST NOT)。外部解析対象実体のテキスト宣言は、その置換テキストの一部とは見なされない。
The text declaration MUST be provided literally, not by reference to a parsed entity. The text declaration MUST NOT appear at any position other than the beginning of an external parsed entity. The text declaration in an external parsed entity is not considered part of its replacement text.
文書は、それが生成規則documentにマッチする時整形式となる。外部一般解析対象実体は、それが生成規則extParsedEntにマッチする時整形式となる。外部パラメータ実体は、定義上、すべてが整形式である。
The document entity is well-formed if it matches the production labeled document. An external general parsed entity is well-formed if it matches the production labeled extParsedEnt. All external parameter entities are well-formed by definition.
メモ Note:
整形式である必要があるのは、文書中で直接的あるいは間接的に参照される解析対象実体だけである。
Only parsed entities that are referenced directly or indirectly within the document are required to be well-formed.
[78] | extParsedEnt |
::= | TextDecl? content |
内部一般解析対象実体は、その置換テキストが生成規則contentにマッチする時整形式となる。内部パラメータ実体は、定義上、すべてが整形式である。
An internal general parsed entity is well-formed if its replacement text matches the production labeled content. All internal parameter entities are well-formed by definition.
一般実体が整形式性を持つ事によって、XML文書の論理構造と物理構造は適切にネストされる事となる。つまり、開始タグ、終了タグ、空要素タグ、要素、コメント、処理命令、文字参照、そして実体参照は、ある実体で始まり、別の実体で終わるという事が一切できない。
A consequence of well-formedness in general entities is that the logical and physical structures in an XML document are properly nested; no start-tag, end-tag, empty-element tag, element, comment, processing instruction, character reference, or entity reference can begin in one entity and end in another.
一つのXML文書で使われる外部解析対象実体は、それぞれ異なるエンコーディングを文字に対して用いても良い。すべてのXMLプロセッサは、UTF-8エンコーディングやUTF-16エンコーディングで表された実体を、両方とも読み取れなければならない(MUST)。この仕様書で使われる用語"UTF-8"と"UTF-16"は、UTF-16BE、UTF-16LE、CESU-8も含めて(かつこれらだけに限らず)、関連するエンコーディングを指す事は無い。
Each external parsed entity in an XML document may use a different encoding for its characters. All XML processors MUST be able to read entities in both the UTF-8 and UTF-16 encodings. The terms "UTF-8" and "UTF-16" in this specification do not apply to related character encodings, including but not limited to UTF-16BE, UTF-16LE, or CESU-8.
UTF-16でエンコードされた実体は、[ISO/IEC 10646:2000]の付録Hや、Unicode [Unicode]のセクション16.8で説明されているバイトオーダーマーク(Byte Order Mark、BOM。ZERO WIDTH NO-BREAK SPACE文字(#xFEFF)の事)から始まらなければならない(MUST)。UTF-8でエンコードされた実体は、バイトオーダーマークから始まっても良い(MAY)。バイトオーダーマークはエンコーディングのシグネチャであり、そのXML文書のマークアップの一部でも文字データの一部でもない。XMLプロセッサは、この文字を、UTF-8でエンコードされた文書とUTF-16でエンコードされた文書を区別する為に使えなければならない(MUST)。
Entities encoded in UTF-16 MUST and entities encoded in UTF-8 MAY begin with the Byte Order Mark described by Annex H of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF). This is an encoding signature, not part of either the markup or the character data of the XML document. XML processors MUST be able to use this character to differentiate between UTF-8 and UTF-16 encoded documents.
外部実体の置換テキストが文字U+FEFFから始まり、かつテキスト宣言が存在しない場合、実体のエンコーディングがUTF-8であろうとUTF-16であろうと、バイトオーダーマークが存在しなければならない(MUST)。
If the replacement text of an external entity is to begin with the character U+FEFF, and no text declaration is present, then a Byte Order Mark MUST be present, whether the entity is encoded in UTF-8 or UTF-16.
XMLプロセッサに絶対に要求されるのはUTF-8エンコーディングやUTF-16エンコーディングで表された実体を読み取れる事だけではあるが、他にも沢山のエンコーディングが世界各地で使われている事が知られており、XMLプロセッサがそれらのエンコーディングで表された実体をも読み取れる事が望まれるかも知れない。外部の文字エンコーディング情報(MIMEヘッダなど)が無いのであれば、UTF-8とUTF-16以外のエンコーディングで記録された解析対象実体は、エンコーディング宣言を含むテキスト宣言(4.3.1 テキスト宣言 The Text Declaration参照)から始まらなければならない(MUST)。エンコーディング宣言は次の通りである。
Although an XML processor is required to read only entities in the UTF-8 and UTF-16 encodings, it is recognized that other encodings are used around the world, and it may be desired for XML processors to read entities that use them. In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 MUST begin with a text declaration (see 4.3.1 The Text Declaration) containing an encoding declaration:
[80] | EncodingDecl |
::= | S 'encoding' Eq ( '"' EncName '"' | "'" EncName "'" ) |
|
[81] | EncName |
::= | [A-Za-z] ( [A-Za-z0-9._] | '-' )* |
/* ラテン文字しか含まないエンコーディング名 Encoding name contains only Latin characters */ |
文書実体では、エンコーディング宣言はXML宣言の一部である。EncNameは、使われているエンコーディングの名前である。
In the document entity, the encoding declaration is part of the XML declaration. The EncName is the name of the encoding used.
エンコーディング宣言では、値"UTF-8
"、"UTF-16
"、"ISO-10646-UCS-2
"、及び"ISO-10646-UCS-4
"は、UnicodeとISO/IEC 10646の様々なエンコーディングやトランスフォーメーションに対して使われる事が望ましい(SHOULD)。値"ISO-8859-1
"、"ISO-8859-2
"、……、"ISO-8859-
n"(ここでnはパート番号)は、ISO 8859のパートに対して使われる事が望ましい(SHOULD)。そして、値"ISO-2022-JP
"、"Shift_JIS
"、及び"EUC-JP
"は、JIS X-0208-1997の様々なエンコードされた形式に対して使われる事が望ましい(SHOULD)。また、Internet Assigned Numbers Authority [IANA-CHARSETS]によって(charsetとして)登録された文字エンコーディングが、その登録名を使って参照される事が推奨される(RECOMMENDED)(ただリストされただけのものは薦められない)。他のエンコーディングは、"x-"接頭辞で始まる名前を使う事が望ましい(SHOULD)。XMLプロセッサは、文字エンコーディング名を、ケース間の差を無視しながらマッチさせる事が望ましい(SHOULD)。また、XMLプロセッサは、IANA登録名を、その名前でIANAに登録されたエンコーディングとして解釈する事が望ましく(SHOULD)、そうしないのであればそれを不明なエンコーディングとして扱う事が望ましい(SHOULD)(プロセッサは、勿論、IANAに登録されたエンコーディングをすべてサポートする必要は無い)。
In an encoding declaration, the values "UTF-8
", "UTF-16
", "ISO-10646-UCS-2
", and "ISO-10646-UCS-4
" SHOULD be used for the various encodings and transformations of Unicode / ISO/IEC 10646, the values "ISO-8859-1
", "ISO-8859-2
", ... "ISO-8859-
n" (where n is the part number) SHOULD be used for the parts of ISO 8859, and the values "ISO-2022-JP
", "Shift_JIS
", and "EUC-JP
" SHOULD be used for the various encoded forms of JIS X-0208-1997. It is RECOMMENDED that character encodings registered (as charsets) with the Internet Assigned Numbers Authority [IANA-CHARSETS], other than those just listed, be referred to using their registered names; other encodings SHOULD use names starting with an "x-" prefix. XML processors SHOULD match character encoding names in a case-insensitive way and SHOULD either interpret an IANA-registered name as the encoding registered at IANA for that name or treat it as unknown (processors are, of course, not required to support all IANA-registered encodings).
外部の転送プロトコル(例えばHTTPやMIME)によって提供される情報が無いのであれば、エンコーディング宣言を含む実体がその宣言で言及したエンコーディング以外のエンコーディングで表されてXMLプロセッサに渡される事や、バイトオーダーマークから始まるのでもなくエンコーディング宣言から始まるのでもない実体がUTF-8以外のエンコーディングを使う事は致命的エラーである。但し、ASCIIはUTF-8のサブセットなので、通常のASCII実体は厳密にエンコーディング宣言を必要とする訳ではない事に注意してほしい。
In the absence of information provided by an external transport protocol (e.g. HTTP or MIME), it is a fatal error for an entity including an encoding declaration to be presented to the XML processor in an encoding other than that named in the declaration, or for an entity which begins with neither a Byte Order Mark nor an encoding declaration to use an encoding other than UTF-8. Note that since ASCII is a subset of UTF-8, ordinary ASCII entities do not strictly need an encoding declaration.
TextDeclが外部実体の始まり以外の場所に現れる事は致命的エラーである。
It is a fatal error for a TextDecl to occur other than at the beginning of an external entity.
XMLプロセッサが処理する事ができないエンコーディングで表された実体に出くわした場合、それは致命的エラーである。XML実体がある特定のエンコーディングで表されていると(デフォルトやエンコーディング宣言、またはより上層のプロトコルによって)決定されたにも拘わらず、そのエンコーディングで許されないバイト列を含んでいた場合、それは致命的エラーである。特に、UTF-8でエンコードされた実体が、Unicode [Unicode]のセクション3.9で定義される悪い形式のコード単位列を含んでいた場合、それは致命的エラーである。エンコーディングがより上層のプロトコルで決定されていなければ、XML実体がエンコーディング宣言を持たず、かつその内容がUTF-8やUTF-16として許されるものでなければ、これも致命的エラーである。
It is a fatal error when an XML processor encounters an entity with an encoding that it is unable to process. It is a fatal error if an XML entity is determined (via default, encoding declaration, or higher-level protocol) to be in a certain encoding but contains byte sequences that are not legal in that encoding. Specifically, it is a fatal error if an entity encoded in UTF-8 contains any ill-formed code unit sequences, as defined in section 3.9 of Unicode [Unicode]. Unless an encoding is determined by a higher-level protocol, it is also a fatal error if an XML entity contains no encoding declaration and its content is not legal UTF-8 or UTF-16.
エンコーディング宣言を含むテキスト宣言の例を幾つか挙げる。
Examples of text declarations containing encoding declarations:
<?xml encoding='UTF-8'?> <?xml encoding='EUC-JP'?>
以下に挙げる表は、文字参照、実体参照、及び解析対象外実体の呼び出しが現れ得る文脈と、それぞれの場合において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:
要素の開始タグの後から終了タグの手前までに現れる参照として。非終端contentに対応する。
as a reference anywhere after the start-tag and before the end-tag of an element; corresponds to the nonterminal content.
開始タグの属性の値の中、あるいは属性宣言のデフォルト値の中に現れる参照として。非終端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.
型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.
パラメータ実体や内部実体の実体宣言の中のリテラル実体値に現れる参照として。非終端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の内部サブセット、あるいは外部サブセットの中に現れる参照として。但し、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).
実体の種類 | 文字参照 | ||||
パラメータ実体 | 内部一般実体 | 外部解析対象一般実体 | 解析対象外実体 | ||
内容の中での参照 | 認識されない | インクルードされる | 妥当性を検証する場合インクルードされる | 許されない | インクルードされる |
属性値の中での参照 | 認識されない | リテラルの中でインクルードされる | 許されない | 許されない | インクルードされる |
属性値としての名前 | 認識されない | 許されない | 許されない | 通知する | 認識されない |
実体値の中での参照 | リテラルの中でインクルードされる | バイパスされる | バイパスされる | エラー | インクルードされる |
DTDの中での参照 | パラメータ実体としてインクルードされる | 許されない | 許されない | 許されない | 許されない |
Entity Type | Character | ||||
Parameter | Internal General | External Parsed General | Unparsed | ||
Reference in Content | Not recognized | Included | Included if validating | Forbidden | Included |
Reference in Attribute Value | Not recognized | Included in literal | Forbidden | Forbidden | Included |
Occurs as Attribute Value | Not recognized | Forbidden | Forbidden | Notify | Not recognized |
Reference in EntityValue | Included in literal | Bypassed | Bypassed | Error | Included |
Reference in DTD | Included as PE | Forbidden | Forbidden | Forbidden | Forbidden |
DTDの外では、文字%
は何ら特別な意味を持たない。従って、DTDの中ではパラメータ実体参照になるであろうものでも、contentの中ではマークアップとして認識されない。同様に、解析対象外実体の名前も、適切に宣言された属性の値に現れた時を除き認識されない。
Outside the DTD, the %
character has no special significance; thus, what would be parameter entity references in the DTD are not recognized as markup in content. Similarly, the names of unparsed entities are not recognized except when they appear in the value of an appropriately declared attribute.
[定義: 実体は、その置換テキストが入手されて処理された時、その参照そのものがあった場所に入れ替わってインクルードされる。あたかも、文書中でその参照が認識された場所にあったものがその置換テキストであるかのようにである。] 置換テキストは、文字データとマークアップの両方を含んで良い(但しパラメータ実体はマークアップを含む事はできない)。マークアップは、いつも通りに認識されなければならない(MUST)(例えば、文字列"AT&T;
"は"AT&T;
"に展開される。ここで、後者の文字列に残ったアンパサンドは実体参照の区切り子とは認識されない)。文字参照は、参照によって指し示された文字が処理された時、その参照そのものがあった場所にインクルードされる。
[Definition: An entity is included when its replacement text is retrieved and processed, in place of the reference itself, as though it were part of the document at the location the reference was recognized.] The replacement text may contain both character data and (except for parameter entities) markup, which MUST be recognized in the usual way. (The string "AT&T;
" expands to "AT&T;
" and the remaining ampersand is not recognized as an entity-reference delimiter.) A character reference is included when the indicated character is processed in place of the reference itself.
XMLプロセッサが解析対象実体への参照を認識した時、文書の妥当性を検証するのであれば、プロセッサはその置換テキストをインクルードしなければならない(MUST)。その実体が外部実体であり、プロセッサがそのXML文書の妥当性を検証しようとしていない場合、プロセッサはその実体の置換テキストをインクルードしても良い(MAY)が、必ずしもそうする必要は無い。妥当性を検証しないプロセッサが置換テキストをインクルードしない時には、プロセッサは、実体が参照されている事を認識はしたが、読み取りはしなかった事をアプリケーションに知らせなければならない(MUST)。
When an XML processor recognizes a reference to a parsed entity, in order to validate the document, the processor MUST include its replacement text. If the entity is external, and the processor is not attempting to validate the XML document, the processor MAY, but need not, include the entity's replacement text. If a non-validating processor does not include the replacement text, it MUST inform the application that it recognized, but did not read, the entity.
この規則は、主に文書を書く際のモジュール分けを助ける為に考えられた、SGML及びXML実体機構の自動インクルージョンが、必ずしも他のアプリケーション(特に文書のブラウジング)に対しては適切ではないという認識に基づいている。例えば、ブラウザは、外部解析対象実体参照を見つけた時、視覚的な情報を以て実体の存在を知らせるに留め、ユーザが要求するまでは、ディスプレイに表示する為に実体の内容を入手する事はしないだろう。
This rule is based on the recognition that the automatic inclusion provided by the SGML and XML entity mechanism, primarily designed to support modularity in authoring, is not necessarily appropriate for other applications, in particular document browsing. Browsers, for example, when encountering an external parsed entity reference, might choose to provide a visual indication of the entity's presence and retrieve it for display only on demand.
次の事は許されない。もしあれば致命的エラーとなる。
The following are forbidden, and constitute fatal errors:
解析対象外実体への参照の出現。但し、実体宣言のEntityValueの中に現れた場合を除く。
the appearance of a reference to an unparsed entity, except in the EntityValue in an entity declaration.
DTDの中での文字参照や一般実体参照の出現。但し、EntityValueの中とAttValueの中に現れた場合を除く。
the appearance of any character or general-entity reference in the DTD except within an EntityValue or AttValue.
属性値の中での外部実体への参照。
a reference to an external entity in an attribute value.
実体参照が属性値の中に現れた時、あるいはパラメータ実体参照がリテラル実体値の中に現れた時、その置換テキストは、あたかも文書中でその参照が認識された場所にあったものがそれであるかのように、参照そのものと入れ替わって処理されなければならない(MUST)。但し、置換テキストに含まれる単引用符や二重引用符は例外で、それらは常にただの文字として扱われなければならず(MUST)、リテラルを終わらせてはならない(MUST NOT)。例えば、次の例は整形式である。
When an entity reference appears in an attribute value, or a parameter entity reference appears in a literal entity value, its replacement text MUST be processed in place of the reference itself as though it were part of the document at the location the reference was recognized, except that a single or double quote character in the replacement text MUST always be treated as a normal data character and MUST NOT terminate the literal. For example, this is well-formed:
<!ENTITY % YN '"Yes"' > <!ENTITY WhatHeSaid "He said %YN;" >
しかし次の例は整形式ではない。
while this is not:
<!ENTITY EndAttr "27'" > <element attribute='a-&EndAttr;>
解析対象外実体の名前が、型ENTITYあるいは型ENTITIESとして宣言された属性の値に含まれるトークンとして現れた場合、妥当性を検証するプロセッサは、その実体と関連付けられた記法の両方について、システム識別子と、もしあれば公開識別子をアプリケーションに知らせなければならない(MUST)。
When the name of an unparsed entity appears as a token in the value of an attribute of declared type ENTITY or ENTITIES, a validating processor MUST inform the application of the system and public (if any) identifiers for both the entity and its associated notation.
一般実体参照が実体宣言のEntityValueに現れた場合、その参照はバイパスされ、そのままの状態にされておかなければならない(MUST)。
When a general entity reference appears in the EntityValue in an entity declaration, it MUST be bypassed and left as is.
外部解析対象実体と同様に、パラメータ実体は妥当性を検証する場合にのみインクルードされる必要がある。パラメータ実体参照がDTDの中で認識されてインクルードされる時、その置換テキストは、先頭と末尾にスペース文字(#x20)を一つずつ付け加えられなければならない(MUST)。この意図は、パラメータ実体の置換テキストに、DTDで必要になるだけの数の文法トークンを持たせるよう制約を課す事である。この動作は、実体値の中に現れるパラメータ実体参照には適用されてはならない(MUST NOT)。それらについては4.4.5 リテラルの中でインクルードされる Included in Literalで説明されている。
Just as with external parsed entities, parameter entities need only be included if validating. When a parameter-entity reference is recognized in the DTD and included, its replacement text MUST be enlarged by the attachment of one leading and one following space (#x20) character; the intent is to constrain the replacement text of parameter entities to contain an integral number of grammatical tokens in the DTD. This behavior MUST NOT apply to parameter entity references within entity values; these are described in 4.4.5 Included in Literal.
実体宣言のEntityValueの中に解析対象外実体への参照が現れる事はエラーである。
It is an error for a reference to an unparsed entity to appear in the EntityValue in an entity declaration.
実体の扱いについて取り扱う際、二種類の実体値を区別すると便利である。 [定義: 内部実体について、リテラル実体値は、実体宣言の中に実際に存在する、引用符で挟まれた文字列である。これは非終端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 "Éditions Gallimard" > <!ENTITY rights "All rights reserved" > <!ENTITY book "La Peste: Albert Camus, © 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.
[定義: 実体参照や文字参照は、左山括弧、アンパサンド、及びその他の区切り子をエスケープする為に使われる事がある。一般実体のセット(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 "&#60;"> <!ENTITY gt ">"> <!ENTITY amp "&#38;"> <!ENTITY apos "'"> <!ENTITY quot """>
[定義: 記法は、解析対象外実体のフォーマットや、記法属性を持つ要素のフォーマット、あるいは処理命令が与えられるアプリケーションを、名前で識別する。]
[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.]
[82] | NotationDecl |
::= | '<!NOTATION' S Name S ( ExternalID | PublicID ) S? '>' |
[妥当性制約: 一意な記法名] |
[83] | PublicID |
::= | 'PUBLIC' S PubidLiteral |
妥当性制約: 一意な記法名 Validity constraint: Unique Notation Name
与えられるNameは、二つ以上の記法宣言で宣言されてはならない(MUST NOT)。
A given Name MUST NOT be declared in more than one notation declaration.
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.)
[定義: 文書実体は、実体ツリーのルートや、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.
仕様に適合する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.
妥当性を検証する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, or in the internal subset after an unread parameter entity reference.
異なる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.
XMLの正式な文法は、簡単なEBNF(Extended Backus-Naur Form)記法を用いてこの仕様書で与えられる。文法のそれぞれの規則は、次の形式で、一つのシンボルを定義する。
The formal grammar of XML is given in this specification using a simple Extended Backus-Naur Form (EBNF) notation. Each rule in the grammar defines one symbol, in the form
symbol ::= expression
シンボルは、正規言語を成す開始シンボルであれば最初の文字が大文字で、そうでなければ小文字で書かれる。リテラル文字列は引用符で囲まれる。
Symbols are written with an initial capital letter if they are the start symbol of a regular language, otherwise with an initial lowercase letter. Literal strings are quoted.
各規則の右辺の表現では、次の表現が一つ以上の文字を持つ文字列をマッチさせる為に使われている。
Within the expression on the right-hand side of a rule, the following expressions are used to match strings of one or more characters:
#xN
N
は16進整数とする。この表現は、そのISO/IEC 10646での番号(コード点)がN
である文字にマッチする。#xN
形式の中で頭につくゼロの列は有意ではない。
where N
is a hexadecimal integer, the expression matches the character whose number (code point) in ISO/IEC 10646 is N
. The number of leading zeros in the #xN
form is insignificant.
[a-zA-Z]
, [#xN-#xN]
示された範囲の中の値を持つすべてのCharにマッチする。端の値も含まれる。
matches any Char with a value in the range(s) indicated (inclusive).
[abc]
, [#xN#xN#xN]
列挙された文字の中の値を持つすべてのCharにマッチする。一つの大括弧の組の中で、列挙と範囲が混ざる事もある。
matches any Char with a value among the characters enumerated. Enumerations and ranges can be mixed in one set of brackets.
[^a-z]
, [^#xN-#xN]
示された範囲の外の値を持つすべてのCharにマッチする。
matches any Char with a value outside the range indicated.
[^abc]
, [^#xN#xN#xN]
与えられた文字の中に無い値を持つすべてのCharにマッチする。一つの大括弧の中で、許されない値の列挙と範囲が混ざる事もある。
matches any Char with a value not among the characters given. Enumerations and ranges of forbidden values can be mixed in one set of brackets.
"string"
二重引用符の中で与えられるリテラル文字列にマッチする、リテラル文字列にマッチする。
matches a literal string matching that given inside the double quotes.
'string'
単引用符の中で与えられるリテラル文字列にマッチする、リテラル文字列にマッチする。
matches a literal string matching that given inside the single quotes.
これらのシンボルは、次に示されるようなより複雑なパターンにマッチする為に、組み合わされる事がある。ここでは、A
とB
は簡単な表現を表す。
These symbols may be combined to match more complex patterns as follows, where A
and B
represent simple expressions:
expression
)expression
は一つの単位として扱われる。このリストで説明されるように組み合わされる事がある。
expression
is treated as a unit and may be combined as described in this list.
A?
A
にマッチするか、何にもマッチしない。つまり、このA
の出現は任意である。
matches A
or nothing; optional A
.
A B
B
が直後に続くA
にマッチする。この演算子は代替よりも高い優先度を持つ。つまり、A B | C D
は( A B ) | ( C D )
と等価である。
matches A
followed by B
. This operator has higher precedence than alternation; thus A B | C D
is identical to (A B) | (C D)
.
A | B
A
かB
にマッチする。
matches A
or B
.
A - B
B
にマッチせず、かつA
にマッチする文字列にマッチする。
matches any string that matches A
but does not match B
.
A+
A
の1回以上の出現にマッチする。連接は代替よりも高い優先度を持つ為、A+ | B+
は( A+ ) | ( B+ )
と等価である。
matches one or more occurrences of A
. Concatenation has higher precedence than alternation; thus A+ | B+
is identical to (A+) | (B+)
.
A*
A
の0回以上の出現にマッチする。連接は代替よりも高い優先度を持つ為、A* | B*
は( A* ) | ( B* )
と等価である。
matches zero or more occurrences of A
. Concatenation has higher precedence than alternation; thus A* | B*
is identical to (A*) | (B*)
.
生成規則で使われる他の記法は次の通り。
Other notations used in the productions are:
/* ... */
コメント。
comment.
[ wfc: ... ]
整形式性制約。これは、生成規則に関連付けられた、整形式の文書に対する制約を名前で識別する。
well-formedness constraint; this identifies by name a constraint on well-formed documents associated with a production.
[ vc: ... ]
妥当性制約。これは、生成規則に関連付けられた、妥当な文書に対する制約を名前で識別する。
validity constraint; this identifies by name a constraint on valid documents associated with a production.
生成規則[4]と[5]に加えられた変更により、この付録に含まれる生成規則は今では孤立しており、今後名前文字を定める為に使われる事も無い。更に、この仕様書の将来の版ではこの付録が削除されるかも知れない。他の仕様書からここにある生成規則を参照したい場合、この仕様書の第四版に含まれる適切な生成規則を参照する事が望ましい。
Because of changes to productions [4] and [5], the productions in this Appendix are now orphaned and not used anymore in determining name characters. This Appendix may be removed in a future edition of this specification; other specifications that wish to refer to the productions herein should do so by means of a reference to the relevant production(s) in the Fourth Edition of this specification.
Unicodeで定義される特徴に従って、文字は基礎文字(ラテンアルファベットのアルファベット的文字を含む)、表意文字、結合文字(ほとんどの発音記号を含む)に分類される。数字と繰り返し記号の分類もある。
Following the characteristics defined in the Unicode standard, characters are classed as base characters (among others, these contain the alphabetic characters of the Latin alphabet), ideographic characters, and combining characters (among others, this class contains most diacritics). Digits and extenders are also distinguished.
[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文字データベースに由来を尋ねる事ができる。
The character classes defined here can be derived from the Unicode 2.0 character database as follows:
名前開始文字は、Ll、Lu、Lo、Lt、Nlの何れかに分類される文字でなければならない。
Name start characters must have one of the categories Ll, Lu, Lo, Lt, Nl.
名前開始文字以外の名前文字は、Mc、Me、Mn、Lm、Ndの何れかに分類される文字でなければならない。
Name characters other than Name-start characters must have one of the categories Mc, Me, Mn, Lm, or Nd.
互換性領域に含まれる文字(つまり、#xF900から#xFFFEまでの文字コードを持つ文字)は、XML名前では許されない。
Characters in the compatibility area (i.e. with character code greater than #xF900 and less than #xFFFE) are not allowed in XML names.
フォント分解文字列、あるいは互換性分解文字列を持つ文字(即ち、データベースの5番目のフィールドに「互換性フォーマッティングタグ」を持つ文字。これらの文字は5番目のフィールドが"<"から始まる)は許されない。
Characters which have a font or compatibility decomposition (i.e. those with a "compatibility formatting tag" in field 5 of the database -- marked by field 5 beginning with a "<") are not allowed.
[#x02BB-#x02C1]、#x0559、#x06E5、#x06E6の文字は、(Unicodeの)プロパティファイルでアルファベット的とされているので、名前文字ではなく名前開始文字として扱われる。
The following characters are treated as name-start characters rather than name characters, because the property file classifies them as Alphabetic: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.
#x20DD-#x20E0の文字は(Unicode 2.0のセクション5.14と同じ理由で)除外される。
Characters #x20DD-#x20E0 are excluded (in accordance with Unicode 2.0, section 5.14).
文字#x00B7は、プロパティリストがこれを繰り返し記号としている為、繰り返し記号に分類される。
Character #x00B7 is classified as an extender, because the property list so identifies it.
文字#x0387は、#x00B7が極限一致文字である為、名前文字に追加される。
Character #x0387 is added as a name character, because #x00B7 is its canonical equivalent.
文字':'と'_'が名前開始文字として許される。
Characters ':' and '_' are allowed as name-start characters.
文字'-'と'.'が名前文字として許される。
Characters '-' and '.' are allowed as name characters.
XMLはSGMLのサブセットとなるよう設計されたので、すべてのXML文書はSGML文書としても適合するはずである。SGMLと比べてXMLに追加された更なる制約について詳細な比較を知りたいなら、ClarkのComparison of XML and SGML [Clark]を見ると良い。
XML is designed to be a subset of SGML, in that every XML document should also be a conforming SGML document. For a detailed comparison of the additional restrictions that XML places on documents beyond those of SGML, see [Clark].
この附録では、4.4 XMLプロセッサによる実体と参照の扱い XML Processor Treatment of Entities and Referencesで指定される、実体参照や文字参照の認識と展開の一連の流れを例で解説する。
This appendix contains some examples illustrating the sequence of entity- and character-reference recognition and expansion, as specified in 4.4 XML Processor Treatment of Entities and References.
DTDが次の宣言を持っていたとする。
If the DTD contains the declaration
<!ENTITY example "<p>An ampersand (&#38;) may be escaped numerically (&#38;#38;) or with a general entity (&amp;).</p>" >
XMLプロセッサは、この実体宣言を解析する時、文字参照を認識し、実体"example
"の値として次の文字列を格納する前に、文字参照を解決するだろう。
then the XML processor will recognize the character references when it parses the entity declaration, and resolve them before storing the following string as the value of the entity "example
":
<p>An ampersand (&) may be escaped numerically (&#38;) or with a general entity (&amp;).</p>
文書中に現れた参照"&example;
"は、このテキストを再び解析させる事となろう。その時、このp
要素の開始タグと終了タグが認識され、三つの参照が認識されて展開され、次の内容を持つp
要素となるだろう(次の内容は、区切り子やマークアップを含まない、すべてのデータである)。
A reference in the document to "&example;
" will cause the text to be reparsed, at which time the start- and end-tags of the p
element will be recognized and the three references will be recognized and expanded, resulting in a p
element with the following content (all data, no delimiters or markup):
An ampersand (&) may be escaped numerically (&) or with a general entity (&).
更に複雑な例を用いれば、規則とその効果を完全に説明できるだろう。次の例では、行番号は単に後で参照する為に付けられたものである。
A more complex example will illustrate the rules and their effects fully. In the following example, the line numbers are solely for reference.
1 <?xml version='1.0'?> 2 <!DOCTYPE test [ 3 <!ELEMENT test (#PCDATA) > 4 <!ENTITY % xx '%zz;'> 5 <!ENTITY % zz '<!ENTITY tricky "error-prone" >' > 6 %xx; 7 ]> 8 <test>This sample shows a &tricky; method.</test>
これは、次の結果を生む。
This produces the following:
4行目で、文字37への参照は即座に展開され、パラメータ実体"xx
"は、値"%zz;
"を持つものとしてシンボルテーブルに格納される。置換テキストは再スキャンされないので、パラメータ実体"zz
"への参照は認識されない(もし認識されてしまったら、"zz
"はまだ宣言されていないのでエラーになるだろう)。
in line 4, the reference to character 37 is expanded immediately, and the parameter entity "xx
" is stored in the symbol table with the value "%zz;
". Since the replacement text is not rescanned, the reference to parameter entity "zz
" is not recognized. (And it would be an error if it were, since "zz
" is not yet declared.)
5行目で、文字参照"<
"は即座に展開され、パラメータ実体"zz
"は、置換テキスト"<!ENTITY tricky "error-prone">
"を持つものとして格納される。これは整形式の実体宣言である。
in line 5, the character reference "<
" is expanded immediately and the parameter entity "zz
" is stored with the replacement text "<!ENTITY tricky "error-prone">
", which is a well-formed entity declaration.
6行目で、"xx
"への参照が認識され、"xx
"の置換テキスト(即ち"%zz;
")が解析される。今回は"zz
"への参照が認識され、その置換テキスト("<!ENTITY tricky "error-prone">
")が解析される。よって、置換テキスト"error-prone
"を持って、一般実体"tricky
"が宣言される事となる。
in line 6, the reference to "xx
" is recognized, and the replacement text of "xx
" (namely "%zz;
") is parsed. The reference to "zz
" is recognized in its turn, and its replacement text ("<!ENTITY tricky "error-prone">
") is parsed. The general entity "tricky
" has now been declared, with the replacement text "error-prone
".
8行目で、一般実体"tricky
"への参照が認識され、展開される。よって、このtest
要素の完全な内容は、それ自体が説明的な(文法的でない、ただの)文字列、This sample shows a error-prone method.(この例はエラーになりやすい方法を示す。)となる。
in line 8, the reference to the general entity "tricky
" is recognized, and it is expanded, so the full content of the test
element is the self-describing (and ungrammatical) string This sample shows a error-prone method.
今度は次の例を考えてみる。
In the following example
<!DOCTYPE foo [ <!ENTITY x "<"> ]> <foo attr="&x;"/>
実体値に現れた一般実体への参照はバイパスされる為、この例におけるxの置換テキストは"<"の4文字になる。一般実体ltの置換テキストは、例えば5文字の"<"など、「小なり(less-than)」の文字への文字参照である(4.6 定義済み実体 Predefined Entities参照)。これらの何れも「小なり」文字を含んでいない為、結果は整形式となる。
the replacement text of x is the four characters "<" because references to general entities in entity values are bypassed. The replacement text of lt is a character reference to the less-than character, for example the five characters "<" (see 4.6 Predefined Entities). Since neither of these contains a less-than character the result is well-formed.
もしxの定義が
If the definition of x had been
<!ENTITY x "<">
であったなら、文書は整形式でなくなる。何故なら、xの置換テキストは"<"という一つの文字になるが、これは属性値の中では許されないからである(整形式制約: 属性値の中に一切無い< WFC: No < in Attribute Values参照)。
then the document would not have been well-formed, because the replacement text of x would be the single character "<" which is not permitted in attribute values (see WFC: No < in Attribute Values).
3.2.1 要素内容 Element Contentで触れたように、要素型宣言の内容モデルは決定的である事が求められる。この要求は、SGMLとの互換性の為に導入されている(SGMLでは、決定的内容モデルを「明白な」「曖昧でない」(unambiguous)ものと呼んでいる)。SGMLシステムを使って組み立てられたXMLプロセッサは、非決定的内容モデルをエラーとするかも知れない。
As noted in 3.2.1 Element Content, it is required that content models in element type declarations be deterministic. This requirement is for compatibility with SGML (which calls deterministic content models "unambiguous"); XML processors built using SGML systems may flag non-deterministic content models as errors.
例えば、内容モデル((b, c) | (b, d))
は非決定的である。何故なら、最初にb
を与えられても、内容モデルのどちらのb
にマッチするものか、b
に続く要素がどちらかを調べない事には、XMLプロセッサは知る事ができないからである。この場合、b
への二つの参照は一つの参照にまとめる事ができ、(b, (c | d))
というモデルとなる。これで、最初のb
は、内容モデルに一つしかない名前にマッチするようになる事は明らかである。プロセッサは、次に何が続くかを調べる必要は無い。c
もd
も受け入れられるだろう。
For example, the content model ((b, c) | (b, d))
is non-deterministic, because given an initial b
the XML processor cannot know which b
in the model is being matched without looking ahead to see which element follows the b
. In this case, the two references to b
can be collapsed into a single reference, making the model read (b, (c | d))
. An initial b
now clearly matches only a single name in the content model. The processor doesn't need to look ahead to see what follows; either c
or d
would be accepted.
もっと形式的に言えば、標準アルゴリズム、例えばAho、Sethi、Ullmanによって書かれたCompilers: Principles, Techniques, and Tools [Aho/Ullman]のセクション3.9のアルゴリズム3.5を使って、内容モデルから有限状態オートマトンが構築され得る。そのようなアルゴリズムでは大概の場合、正規表現のそれぞれの位置(つまり、正規表現の為の構文木のそれぞれの末端ノード)の為にフォローセットが構築される。ここで、一つより多くの後続の位置が同じ要素型の名前を持っているようなフォローセットを持つ位置があるかも知れない。もしそのようなフォローセットを持っている位置があった場合、その内容モデルの存在はエラーとなる。これはエラーとして報告されるかも知れない。
More formally: a finite state automaton may be constructed from the content model using the standard algorithms, e.g. algorithm 3.5 in section 3.9 of Aho, Sethi, and Ullman [Aho/Ullman]. In many such algorithms, a follow set is constructed for each position in the regular expression (i.e., each leaf node in the syntax tree for the regular expression); if any position has a follow set in which more than one following position is labeled with the same element type name, then the content model is in error and may be reported as an error.
すべてではないが、多くの非決定的内容モデルを自動的に等価な決定的モデルにまとめる事ができるアルゴリズムが存在する。Brüggemann-KleinのFormal Models in Document Processing (1991) [Brüggemann-Klein]を参照してほしい。
Algorithms exist which allow many but not all non-deterministic content models to be reduced automatically to equivalent deterministic models; see Brüggemann-Klein 1991 [Brüggemann-Klein].
XMLのエンコーディング宣言は、それぞれの実体の内部ラベルとして機能し、どの文字エンコーディングが使われているかを示す。しかし、XMLプロセッサが内部ラベルを読む事ができるようになる前に、XMLプロセッサはどの文字エンコーディングが使われているか──内部ラベルが示そうとしているものはどれかを知らなければならない事は明らかである。一般的には、これを知る事はまず無理である。しかし、XMLでは必ずしも無理な話ではない。それはXMLが一般的な場合を二つの方法で制限しているからである。つまり、実装はそれぞれ有限の数の文字エンコーディングしかサポートしない事が想定されており、XMLエンコーディング宣言は、普通の場合でもそれぞれの実体で使われている文字エンコーディングを自動検知する事を可能にする為に位置と内容が制限されている。また、多くの場合はXMLのデータストリームそのものに加えて、他の情報源も利用可能である。XML実体が付随する(外部の)情報と共にプロセッサに渡されるか否かによって、二つの場合に分ける事ができるだろう。これらの場合を順番に考えてみる。
The XML encoding declaration functions as an internal label on each entity, indicating which character encoding is in use. Before an XML processor can read the internal label, however, it apparently has to know what character encoding is in use—which is what the internal label is trying to indicate. In the general case, this is a hopeless situation. It is not entirely hopeless in XML, however, because XML limits the general case in two ways: each implementation is assumed to support only a finite set of character encodings, and the XML encoding declaration is restricted in position and content in order to make it feasible to autodetect the character encoding in use in each entity in normal cases. Also, in many cases other sources of information are available in addition to the XML data stream itself. Two cases may be distinguished, depending on whether the XML entity is presented to the processor without, or with, any accompanying (external) information. We will consider these cases in turn.
外部エンコーディング情報を持たず、UTF-8でもUTF-16でもないエンコーディングで表されているXML実体は、XMLエンコーディング宣言から始まらなければならないので、そのような実体では最初の文字列は'<?xml
'しかあり得ない。よって、仕様に適合するプロセッサはすべて、入力の2から4オクテットを読み取る事で、次のどのケースが適用されるかを自動検知する事ができる。このリストを読むに当たって、UCS-4では、'<'が"#x0000003C
"で、'?'が"#x0000003F
"、そしてUTF-16のデータストリームに必須とされるバイトオーダーマークは"#xFEFF
"である事を知っておくと役に立つかも知れない。##という記法は、任意のバイト値を表す為に使われる。但し、二つの連続する##が両方とも00になる事は無い。
Because each XML entity not accompanied by external encoding information and not in UTF-8 or UTF-16 encoding must begin with an XML encoding declaration, in which the first characters must be '<?xml
', any conforming processor can detect, after two to four octets of input, which of the following cases apply. In reading this list, it may help to know that in UCS-4, '<' is "#x0000003C
" and '?' is "#x0000003F
", and the Byte Order Mark required of UTF-16 data streams is "#xFEFF
". The notation ## is used to denote any byte value except that two consecutive ##s cannot be both 00.
バイトオーダーマークがある場合は次の通り。
With a Byte Order Mark:
00 00 FE FF |
UCS-4、ビッグエンディアン(1234の順) |
FF FE 00 00 |
UCS-4、リトルエンディアン(4321の順) |
00 00 FF FE |
UCS-4、一般的でないオクテットの並び(2143) |
FE FF 00 00 |
UCS-4、一般的でないオクテットの並び(3412) |
FE FF ## ## |
UTF-16、ビッグエンディアン |
FF FE ## ## |
UTF-16、リトルエンディアン |
EF BB BF |
UTF-8 |
00 00 FE FF |
UCS-4, big-endian machine (1234 order) |
FF FE 00 00 |
UCS-4, little-endian machine (4321 order) |
00 00 FF FE |
UCS-4, unusual octet order (2143) |
FE FF 00 00 |
UCS-4, unusual octet order (3412) |
FE FF ## ## |
UTF-16, big-endian |
FF FE ## ## |
UTF-16, little-endian |
EF BB BF |
UTF-8 |
バイトオーダーマークが無い場合は次の通り。
Without a Byte Order Mark:
00 00 00 3C |
UCS-4か、ASCII文字をASCII値でエンコードし32ビットをコード単位とする他のエンコーディング。順に、ビッグエンディアン(1234)、リトルエンディアン(4321)、そして二つの一般的でないオクテットの並び(2143と3412)である。この場合、エンコーディングがUCS-4なのか、(実装がサポートする)他の32ビットエンコーディングなのかを決める為、エンコーディング宣言を読み取らなければならない。 |
3C 00 00 00 |
|
00 00 3C 00 |
|
00 3C 00 00 |
|
00 3C 00 3F |
UTF-16BEか、ビッグエンディアンISO-10646-UCS-2か、ASCII文字をASCII値でエンコードしビッグエンディアンの並びの16ビットコード単位を持つ他のエンコーディング(どのエンコーディングなのかを決める為、エンコーディング宣言を読み取らなければならない)。 |
3C 00 3F 00 |
UTF-16LEか、リトルエンディアンISO-10646-UCS-2か、ASCII文字をASCII値でエンコードしリトルエンディアンの並びの16ビットコード単位を持つ他のエンコーディング(どのエンコーディングなのかを決める為、エンコーディング宣言を読み取らなければならない)。 |
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、あるいは、データストリームが間違ってラベルされている(必須のエンコーディング宣言を欠いている)か、壊れているか、一部しかないか、何らかのラッパに包含されているかである。 |
00 00 00 3C | UCS-4 or other encoding with a 32-bit code unit and ASCII characters encoded as ASCII values, in respectively big-endian (1234), little-endian (4321) and two unusual byte orders (2143 and 3412). The encoding declaration must be read to determine which of UCS-4 or other supported 32-bit encodings applies. |
3C 00 00 00 |
|
00 00 3C 00 |
|
00 3C 00 00 |
|
00 3C 00 3F |
UTF-16BE or big-endian ISO-10646-UCS-2 or other encoding with a 16-bit code unit in big-endian order and ASCII characters encoded as ASCII values (the encoding declaration must be read to determine which) |
3C 00 3F 00 |
UTF-16LE or little-endian ISO-10646-UCS-2 or other encoding with a 16-bit code unit in little-endian order and ASCII characters encoded as ASCII values (the encoding declaration must be read to determine which) |
3C 3F 78 6D |
UTF-8, ISO 646, ASCII, some part of ISO 8859, Shift-JIS, EUC, or any other 7-bit, 8-bit, or mixed-width encoding which ensures that the characters of ASCII have their normal positions, width, and values; the actual encoding declaration must be read to detect which of these applies, but since all of these encodings use the same bit patterns for the relevant ASCII characters, the encoding declaration itself may be read reliably |
4C 6F A7 94 |
EBCDIC (in some flavor; the full encoding declaration must be read to tell which code page is in use) |
Other | UTF-8 without an encoding declaration, or else the data stream is mislabeled (lacking a required encoding declaration), corrupt, fragmentary, or enclosed in a wrapper of some kind |
メモ Note:
上に挙げられている場合の内、エンコーディングを決める為にエンコーディング宣言を読み取る事を必要としない場合でも、セクション4.3.3で説明されているように、エンコーディング宣言が存在するならばその宣言は読み取られなければならず、エンコーディング名は実際に実体で使われているエンコーディングとマッチしている事を検査されなければならない。また、現在はエンコーディング方法を決める為にエンコーディング宣言を使う事が必要とされない場合もあるが、将来的にはそれらの場合でもエンコーディング宣言が必要になるような新しい文字エンコーディングが作られる事もあり得る。
In cases above which do not require reading the encoding declaration to determine the encoding, section 4.3.3 still requires that the encoding declaration, if present, be read and that the encoding name be checked to match the actual encoding of the entity. Also, it is possible that new character encodings will be invented that will make it necessary to use the encoding declaration to determine the encoding, in cases where this is not required at present.
この段階まで自動検知を行えば、XMLエンコーディング宣言を読み取って文字エンコーディング識別子を解析するのには十分である。但し、エンコーディングファミリのメンバは区別する必要がある(例えば、UTF-8、8859、そして8859のパートをそれぞれ区別しなければならないし、使われているEBCDICコードページを知らなければならない。他の場合でも同様である)。
This level of autodetection is enough to read the XML encoding declaration and parse the character-encoding identifier, which is still necessary to distinguish the individual members of each family of encodings (e.g. to tell UTF-8 from 8859, and the parts of 8859 from each other, or to distinguish the specific EBCDIC code page in use, and so on).
エンコーディング宣言の内容は、エンコードされてはいるもののASCIIレパートリーの文字に制限されている為、プロセッサは、どのエンコーディングファミリが使われているかを検知次第、エンコーディング宣言全体を信頼を持って読み取る事ができる。実際には、広く使われている文字エンコーディングはすべて上に挙げられたカテゴリの中の一つに当てはまる為、たとえオペレーティングシステムレベルあるいは転送プロトコルレベルの外部情報源が信頼できない時でも、XMLエンコーディング宣言は文字エンコーディングの信頼に値するインバンドラベリングを合理的に可能にする。UTF-7などの、ASCII値のバイトをオーバーロードして使う文字エンコーディングは、信頼を持って検知できない事がある。
Because the contents of the encoding declaration are restricted to characters from the ASCII repertoire (however encoded), a processor can reliably read the entire encoding declaration as soon as it has detected which family of encodings is in use. Since in practice, all widely used character encodings fall into one of the categories above, the XML encoding declaration allows reasonably reliable in-band labeling of character encodings, even when external sources of information at the operating-system or transport-protocol level are unreliable. Character encodings such as UTF-7 that make overloaded usage of ASCII-valued bytes may fail to be reliably detected.
[訳者註開始]
訳者註
インバンド(In-Band)に、とは、ここでは「外部の情報源を用いる事無く、XML文書が含まれるストリームの中で」といった意味合いです。
[訳者註終了]
プロセッサは、使われている文字エンコーディングを検知し終わったら、その後を適切に処理する事ができる。文字エンコーディングによってそれぞれ別の入力ルーチンを呼び出したり、入力から送られるそれぞれの文字について適切な変換関数を呼んだりできる。
Once the processor has detected the character encoding in use, it can act appropriately, whether by invoking a separate input routine for each case, or by calling the proper conversion function on each character of input.
何らかのソフトウェアが、実体の文字セットやエンコーディングをエンコーディング宣言を更新しないまま変更してしまった場合、他のセルフラベリングシステムと同様、XMLエンコーディング宣言はうまく機能しない。文字エンコーディングルーチンの実装者は、実体をラベルする為に使われる内部及び外部情報の正確性を保つよう注意を払うべきである。
Like any self-labeling system, the XML encoding declaration will not work if any software changes the entity's character set or encoding without updating the encoding declaration. Implementors of character-encoding routines should be careful to ensure the accuracy of the internal and external information used to label the entity.
もう一つのケースは、特定のファイルシステムや特定のネットワークプロトコルで、XML実体がエンコーディング情報と共に与えられた時に起こる。幾つかの情報源が利用可能である時、それらの相対的な優先度や衝突を扱う望ましい方法などは、XMLを伝達する為に使われるより上層のプロトコルの一部として指定される事が望ましい。特に、[IETF RFC 3023]、あるいはその後継文書を参照してほしい。この文書はtext/xml
とapplication/xml
の二つのMIMEタイプを定義し、便利な案内も提供する。しかし、相互運用性に配慮して、次の規則に従う事をお勧めする。
The second possible case occurs when the XML entity is accompanied by encoding information, as in some file systems and some network protocols. When multiple sources of information are available, their relative priority and the preferred method of handling conflict should be specified as part of the higher-level protocol used to deliver XML. In particular, please refer to [IETF RFC 3023] or its successor, which defines the text/xml
and application/xml
MIME types and provides some useful guidance. In the interests of interoperability, however, the following rule is recommended.
XML実体がファイルに収められている場合、バイトオーダーマークやエンコーディング宣言があるならば、それらが文字エンコーディングを決定する為に使われる。
If an XML entity is in a file, the Byte-Order Mark and encoding declaration are used (if present) to determine the character encoding.
この仕様書は、W3C XML Working Group (WG)によって準備され、公開を承認された。この仕様書のWGによる承認は、必ずしもすべてのWG参加者が承認投票を行った事を意味するものではない。XML WGの現在のメンバと過去に参加していたメンバは次の通り。
This specification was prepared and approved for publication by the W3C XML Working Group (WG). WG approval of this specification does not necessarily imply that all WG participants voted for its approval. The current and former members in the XML WG are:
この仕様書の第五版は、W3C XML Core Working Group (WG)によって準備された。この版の公開時のXML Core WGの参加者は次の通り。
The fifth edition of this specification was prepared by the W3C XML Core Working Group (WG). The participants in the WG at the time of publication of this edition were:
この第四版は、XMLspec DTD, v2.10に少し手を加えたバージョンのDTDでエンコードされた。XHTMLバージョンは、xmlspec.xsl、diffspec.xsl、REC-xml.xslの三つのXSLTスタイルシートを組み合わせて生成された。
This Fourth Edition was encoded in a slightly modified version of the XMLspec DTD, v2.10. The XHTML versions were produced with a combination of the xmlspec.xsl, diffspec.xsl, and REC-xml.xsl XSLT stylesheets.
次に挙げる提案は、要素名、属性名、処理命令対象、実体名、記法名、型IDの属性の値として使われるXML名前を構築する上で、最も良い方法だと考えられるものを明文化したものである。これらは、文書の著者やスキーマの設計者の為の案内となるよう意図されている。Unicodeへの参照は、Unicode Standardのバージョン5.0か、それより大きいバージョンを持つそれを指す。それらの内のどのバージョンが使われるかについては、文書の著者やスキーマの設計者の裁量に委ねられる。
The following suggestions define what is believed to be best practice in the construction of XML names used as element names, attribute names, processing instruction targets, entity names, notation names, and the values of attributes of type ID, and are intended as guidance for document authors and schema designers. All references to Unicode are understood with respect to a particular version of the Unicode Standard greater than or equal to 5.0; which version should be used is left to the discretion of the document author or schema designer.
最初の二つの提案は、Unicode Standardバージョン5.0 [Unicode]のUnicode Standard Annex #31(UAX #31)の識別子に適用される規則に直接由来する。これらは、すべての制御文字、空白を取らない内包マーク、非10進数字、プライベート利用文字、(例外はあるが)句読点、シンボル文字、未割り当てコード点、そしてホワイトスペース文字を除外するものである。その他の提案は、殆どがこの仕様書の以前の版の附録Bに由来するものである。
The first two suggestions are directly derived from the rules given for identifiers in Standard Annex #31 (UAX #31) of the Unicode Standard, version 5.0 [Unicode], and exclude all control characters, enclosing nonspacing marks, non-decimal numbers, private-use characters, punctuation characters (with the noted exceptions), symbol characters, unassigned codepoints, and white space characters. The other suggestions are mostly derived from Appendix B in previous editions of this specification.
すべての名前において、最初の文字は、Unicode属性ID_Startを持つ文字か、そうでなければ'_'(#x5F)である事が望ましい。
The first character of any name should have a Unicode property of ID_Start, or else be '_' #x5F.
最初の文字以外の文字は、Unicode属性ID_Continueを持つ文字か、UAX #31で"Characters for Natural Language Identifiers"と題された表に含まれる文字である事が望ましい。但し、"'"(#x27)と"’"(#x2019)は例外である(使ってはならない)。
Characters other than the first should have a Unicode property of ID_Continue, or be one of the characters listed in the table entitled "Characters for Natural Language Identifiers" in UAX #31, with the exception of "'" #x27 and "’" #x2019.
名前に含まれる文字は、[UnicodeNormal]で定義される正規形Cを使って表現されている事が望ましい。
Characters in names should be expressed using Normalization Form C as defined in [UnicodeNormal].
極限分解文字列を持つ表意文字([#xF900-#xFAFF]と[#x2F800-#x2FFFD]の範囲の文字を含むが、12個の例外がある)は、名前に使わない方が良い。
Ideographic characters which have a canonical decomposition (including those in the ranges [#xF900-#xFAFF] and [#x2F800-#x2FFFD], with 12 exceptions) should not be used in names.
互換性分解文字列を持つ文字(Unicode Character Databaseの5番目のフィールドに「互換性フォーマッティングタグ」を持つもの。このタグを持つ文字は、5番目のフィールドが"<"で始まる)は、名前に使わない方が良い。この提案は、例えば#x0E33(THAI CHARACTER SARA AM)や#x0EB3(LAO CHARACTER AM)など、互換性分解文字列を持つけれどもその言語の文章で普通に使われる文字には当てはまらない。
Characters which have a compatibility decomposition (those with a "compatibility formatting tag" in field 5 of the Unicode Character Database -- marked by field 5 beginning with a "<") should not be used in names. This suggestion does not apply to characters which despite their compatibility decompositions are in regular use in their scripts, for example #x0E33 THAI CHARACTER SARA AM or #x0EB3 LAO CHARACTER AM.
シンボルのみに付く為の結合文字([#x20D0-#x20EF]と[#x1D165-#x1D1AD]の範囲の文字を含む)は、名前に使わない方が良い。
Combining characters meant for use with symbols only (including those in the ranges [#x20D0-#x20EF] and [#x1D165-#x1D1AD]) should not be used in names.
行をまたぐ註釈文字(ルビ、即ち振り仮名の範囲指示用。[#xFFF9-#xFFFB])は、名前に使わない方が良い。
The interlinear annotation characters ([#xFFF9-#xFFFB]) should not be used in names.
バリエーションセレクタ文字は、名前に使わない方が良い。
Variation selector characters should not be used in names.
無意味な名前、発音できない名前、読みづらい名前、他の名前と間違えやすい名前は、使わない方が良い。
Names which are nonsensical, unpronounceable, hard to read, or easily confusable with other names should not be employed.