拡張可能な&markup;言語 (XML)

diff -r 000000000000 -r 1918ee327afb tests/auto/qxmlstream/XML-Test-Suite/xmlconf/japanese/pr-xml-utf-8.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/tests/auto/qxmlstream/XML-Test-Suite/xmlconf/japanese/pr-xml-utf-8.xml Mon Jan 11 14:00:40 2010 +0000 @@ -0,0 +1,3548 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +"> + + +'"> + + + + + + + + + +amp, +lt, +gt, +apos, +quot"> + + + + + + + +]> + + + + + +

+拡張可能な&markup;言語 (XML) +第1.0&version; +PR-xml-&iso6.doc.date; +World Wide Web Consortium +&draft.day;&draft.month;&draft.year; +

この草案は，XML WG及び他の関係者によるレビューのためのものであって，公開の議論のためのものではない。 +

+ + +http://www.w3.org/TR/PR-xml-&iso6.doc.date; + + +http://www.w3.org/TR/WD-xml-961114 + +http://www.w3.org/TR/WD-xml-lang-970331 + +http://www.w3.org/TR/WD-xml-lang-970630 + +http://www.w3.org/TR/WD-xml-970807 + +http://www.w3.org/TR/WD-xml-971117 + + +Tim Bray +Textuality and Netscape +tbray@textuality.com +Jean Paoli +Microsoft +jeanpa@microsoft.com +C. M. Sperberg-McQueen +University of Illinois at Chicago +cmsmcq@uic.edu + + +

この&TR-or-Rec;は, 1997年12月にWorld Wide Web Consortiumから +公表された勧告案Extensible Markup Language version第1.0版を翻訳し, 技 +術的内容を変更することなく作成した&TR-or-Rec;である。This &eTR-or-Rec; +is a translation of the XML proposed recommendation 1.0 +published by the World Wide Web Consortium in December 1997. It is +intended that &eTR-or-Rec; is technically identical to the original.

+ +

原文にある、著作権に関しての記述を次に示す。The +original copyright notice is shown below:

+ +

この版のXMLの規定は，公開レビュー及び議論を +目的とする。テキスト及び法律上の注意を改変しない限り，自由に +配布してもよい。This version of the XML specification is for +public review and discussion. It may be distributed freely, +as long as all text and legal notices remain intact.

+ +

この&TR-or-Rec;の元となったXML勧告案は，1998年2月にWorld +Wide Web Consortiumから公表されたXML勧告によってすでに置き換 +えられている。この標準情報は，XML勧告に従って訂正することを +予定している。The XML Proposed Recommendation is superseded +by the XML Recommendation which was published by the World +Wide Web Consortium in February 1998. It is intended that +this &eTR-or-Rec; be revised accordingly in the near future.

+ +

この&TR-or-Rec;は，安定したものであって，昨年来のXML活動を通じて作成された，一連の作 +業草案を元とする。現在，広範囲に使用されている国際的なテキスト処理の標 +準(標準一般化&markup;言語，Standard Generalized Markup Language, ISO +8879:1986に追加及び訂正を加えたもの)の，WWW上での使用のために⊂ +化した言語を，この&TR-or-Rec;は，規定する。ISO 8879のどの機能をこの +⊂に残すか，という決定についての詳細は，別途用意する。XMLは， +既にいくつかの商品でサポートされ，XMLをサポートするフリーウェアの数も増えて +いる。XMLに関する公開の論議も，オンラインで入手できる。It is a +stable document derived from a series of working drafts produced over +the last year as deliverables of the XML activity. It specifies a +language created by subsetting an existing, widely used international +text processing standard (Standard Generalized Markup Language, ISO +8879:1986 as amended and corrected) for use on the World Wide Web. +Details of the decisions regarding which features of ISO 8879 to +retain in the subset are available +separately. XML is already supported by some commercial +products, and there are a growing number of free implementations. +Public discussions of XML are accessible +online.

+ +

この&TR-or-Rec;では，に定義する +URI(Uniform Resource Identifier)を使用する。URIの制定作業は進行中であっ +て，及びを更新する予定と +なっている。この作業がRFCとして受け入れられない場合は，この規程内のURI +への参照は，URL(Uniform Resource Locator)への参照に代わる。This +specification uses the term URI, which is defined by , a work in progress expected to update and . Should the work not be +accepted as an RFC, the references to uniform resource identifiers +(URIs) in this specification will become references to uniform +resource locators (URLs).

+ +

XMLの仕様に準拠しているかどうかの基準となるはW3Cのサイトにあ +る原文である。The normative version of the specification is +the English version found at the W3C site.

+ +

この標準情報は原仕様と技術的に同一であることを意図しているが、 +翻訳上の誤りはあり得る。Although this technical report is +intended to be technically identical to the original, it may +contain errors from the translation.

+ +

備考: 原規定との規定箇所の対応関係を明らかにするため、この +&TR-or-Rec;の節構成及び節番号は、原規定のそれらをできるだけ保存してい +る。この&TR-or-Rec;のWeb版は、原規定のHTMLタグをそのまま保存している。 +

+ + + +

拡張可能な&markup;言語(XML)はSGMLの簡単な方言であって，この&TR-or-Rec;で，そのすべてを規定する。XMLの目標は，現在のHTMLと同様に，一般性のあるSGMLをウェブ上で配布，受信及び処理できることとする。XMLは実装が容易であって，SGML及びHTMLのどちらに対しても相互運用性を保つ設計がなされている。

+ + +

Chicago, Vancouver, Mountain View, et al.: +World-Wide Web Consortium, XML作業グループ, 1996, 1997.

+ + +

Created in electronic form.

+ + +English +Extended Backus-Naur Form (formal grammar) + + + +1997-12-03 : CMSMcQ : yet further changes +1997-12-02 : TB : further changes (see TB to XML WG, +2 December 1997) +1997-12-02 : CMSMcQ : deal with as many corrections and +comments from the proofreaders as possible: +entify hard-coded document date in pubdate element, +change expansion of entity WebSGML, +update status description as per Dan Connolly (am not sure +about refernece to Berners-Lee et al.), +add 'The' to abstract as per WG decision, +move Relationship to Existing Standards to back matter and +combine with References, +re-order back matter so normative appendices come first, +re-tag back matter so informative appendices are tagged informdiv1, +remove XXX XXX from list of 'normative' specs in prose, +move some references from Other References to Normative References, +add RFC 1738, 1808, and 2141 to Other References (they are not +normative since we do not require the processor to enforce any +rules based on them), +add reference to 'Fielding draft' (Berners-Lee et al.), +move notation section to end of body, +drop URIchar non-terminal and use SkipLit instead, +lose stray reference to defunct nonterminal 'markupdecls', +move reference to Aho et al. into appendix (Tim's right), +add prose note saying that hash marks and fragment identifiers are +NOT part of the URI formally speaking, and are NOT legal in +system identifiers (processor 'may' signal an error). +Work through: +Tim Bray reacting to James Clark, +Tim Bray on his own, +Eve Maler, + +NOT DONE YET: +change binary / text to unparsed / parsed. +handle James's suggestion about < in attriubte values +uppercase hex characters, +namechar list, + +1997-12-01 : JB : add some column-width parameters +1997-12-01 : CMSMcQ : begin round of changes to incorporate +recent WG decisions and other corrections: +binding sources of character encoding info (27 Aug / 3 Sept), +correct wording of Faust quotation (restore dropped line), +drop SDD from EncodingDecl, +change text at version number 1.0, +drop misleading (wrong!) sentence about ignorables and extenders, +modify definition of PCData to make bar on msc grammatical, +change grammar's handling of internal subset (drop non-terminal markupdecls), +change definition of includeSect to allow conditional sections, +add integral-declaration constraint on internal subset, +drop misleading / dangerous sentence about relationship of +entities with system storage objects, +change table body tag to htbody as per EM change to DTD, +add rule about space normalization in public identifiers, +add description of how to generate our name-space rules from +Unicode character database (needs further work!). + +1997-10-08 : TB : Removed %-constructs again, new rules +for PE appearance. +1997-10-01 : TB : Case-sensitive markup; cleaned up +element-type defs, lotsa little edits for style +1997-09-25 : TB : Change to elm's new DTD, with +substantial detail cleanup as a side-effect +1997-07-24 : CMSMcQ : correct error (lost *) in definition +of ignoreSectContents (thanks to Makoto Murata) +Allow all empty elements to have end-tags, consistent with +SGML TC (as per JJC). +1997-07-23 : CMSMcQ : pre-emptive strike on pending corrections: +introduce the term 'empty-element tag', note that all empty elements +may use it, and elements declared EMPTY must use it. +Add WFC requiring encoding decl to come first in an entity. +Redefine notations to point to PIs as well as binary entities. +Change autodetection table by removing bytes 3 and 4 from +examples with Byte Order Mark. +Add content model as a term and clarify that it applies to both +mixed and element content. + +1997-06-30 : CMSMcQ : change date, some cosmetic changes, +changes to productions for choice, seq, Mixed, NotationType, +Enumeration. Follow James Clark's suggestion and prohibit +conditional sections in internal subset. TO DO: simplify +production for ignored sections as a result, since we don't +need to worry about parsers which don't expand PErefs finding +a conditional section. +1997-06-29 : TB : various edits +1997-06-29 : CMSMcQ : further changes: +Suppress old FINAL EDIT comments and some dead material. +Revise occurrences of % in grammar to exploit Henry Thompson's pun, +especially markupdecl and attdef. +Remove RMD requirement relating to element content (?). + +1997-06-28 : CMSMcQ : Various changes for 1 July draft: +Add text for draconian error handling (introduce +the term Fatal Error). +RE deleta est (changing wording from +original announcement to restrict the requirement to validating +parsers). +Tag definition of validating processor and link to it. +Add colon as name character. +Change def of %operator. +Change standard definitions of lt, gt, amp. +Strip leading zeros from #x00nn forms. +1997-04-02 : CMSMcQ : final corrections of editorial errors +found in last night's proofreading. Reverse course once more on +well-formed: Webster's Second hyphenates it, and that's enough +for me. +1997-04-01 : CMSMcQ : corrections from JJC, EM, HT, and self +1997-03-31 : Tim Bray : many changes +1997-03-29 : CMSMcQ : some Henry Thompson (on entity handling), +some Charles Goldfarb, some ERB decisions (PE handling in miscellaneous +declarations. Changed Ident element to accept def attribute. +Allow normalization of Unicode characters. move def of systemliteral +into section on literals. +1997-03-28 : CMSMcQ : make as many corrections as possible, from +Terry Allen, Norbert Mikula, James Clark, Jon Bosak, Henry Thompson, +Paul Grosso, and self. Among other things: give in on "well formed" +(Terry is right), tentatively rename QuotedCData as AttValue +and Literal as EntityValue to be more informative, since attribute +values are the only place QuotedCData was used, and +vice versa for entity text and Literal. (I'd call it Entity Text, +but 8879 uses that name for both internal and external entities.) +1997-03-26 : CMSMcQ : resynch the two forks of this draft, reapply +my changes dated 03-20 and 03-21. Normalize old 'may not' to 'must not' +except in the one case where it meant 'may or may not'. +1997-03-21 : TB : massive changes on plane flight from Chicago +to Vancouver +1997-03-21 : CMSMcQ : correct as many reported errors as possible. + +1997-03-20 : CMSMcQ : correct typos listed in CMSMcQ hand copy of spec. +1997-03-20 : CMSMcQ : cosmetic changes preparatory to revision for +WWW conference April 1997: restore some of the internal entity +references (e.g. to docdate, etc.), change character xA0 to   +and define nbsp as  , and refill a lot of paragraphs for +legibility. +1996-11-12 : CMSMcQ : revise using Tim's edits: +Add list type of NUMBERED and change most lists either to +BULLETS or to NUMBERED. +Suppress QuotedNames, Names (not used). +Correct trivial-grammar doc type decl. +Rename 'marked section' as 'CDATA section' passim. +Also edits from James Clark: +Define the set of characters from which [^abc] subtracts. +Charref should use just [0-9] not Digit. +Location info needs cleaner treatment: remove? (ERB +question). +One example of a PI has wrong pic. +Clarify discussion of encoding names. +Encoding failure should lead to unspecified results; don't +prescribe error recovery. +Don't require exposure of entity boundaries. +Ignore white space in element content. +Reserve entity names of the form u-NNNN. +Clarify relative URLs. +And some of my own: +Correct productions for content model: model cannot +consist of a name, so "elements ::= cp" is no good. + +1996-11-11 : CMSMcQ : revise for style. +Add new rhs to entity declaration, for parameter entities. +1996-11-10 : CMSMcQ : revise for style. +Fix / complete section on names, characters. +Add sections on parameter entities, conditional sections. +Still to do: Add compatibility note on deterministic content models. +Finish stylistic revision. +1996-10-31 : TB : Add Entity Handling section +1996-10-30 : TB : Clean up term & termdef. Slip in +ERB decision re EMPTY. +1996-10-28 : TB : Change DTD. Implement some of Michael's +suggestions. Change comments back to //. Introduce language for +XML namespace reservation. Add section on white-space handling. +Lots more cleanup. +1996-10-24 : CMSMcQ : quick tweaks, implement some ERB +decisions. Characters are not integers. Comments are /* */ not //. +Add bibliographic refs to 10646, HyTime, Unicode. +Rename old Cdata as MsData since it's only seen +in marked sections. Call them attribute-value pairs not +name-value pairs, except once. Internal subset is optional, needs +'?'. Implied attributes should be signaled to the app, not +have values supplied by processor. +1996-10-16 : TB : track down & excise all DSD references; +introduce some EBNF for entity declarations. +1996-10-?? : TB : consistency check, fix up scraps so +they all parse, get formatter working, correct a few productions. +1996-10-10/11 : CMSMcQ : various maintenance, stylistic, and +organizational changes: +Replace a few literals with xmlpio and +pic entities, to make them consistent and ensure we can change pic +reliably when the ERB votes. +Drop paragraph on recognizers from notation section. +Add match, exact match to terminology. +Move old 2.2 XML Processors and Apps into intro. +Mention comments, PIs, and marked sections in discussion of +delimiter escaping. +Streamline discussion of doctype decl syntax. +Drop old section of 'PI syntax' for doctype decl, and add +section on partial-DTD summary PIs to end of Logical Structures +section. +Revise DSD syntax section to use Tim's subset-in-a-PI +mechanism. +1996-10-10 : TB : eliminate name recognizers (and more?) +1996-10-09 : CMSMcQ : revise for style, consistency through 2.3 +(Characters) +1996-10-09 : CMSMcQ : re-unite everything for convenience, +at least temporarily, and revise quickly +1996-10-08 : TB : first major homogenization pass +1996-10-08 : TB : turn "current" attribute on div type into +CDATA +1996-10-02 : TB : remould into skeleton + entities +1996-09-30 : CMSMcQ : add a few more sections prior to exchange + with Tim. +1996-09-20 : CMSMcQ : finish transcribing notes. +1996-09-19 : CMSMcQ : begin transcribing notes for draft. +1996-09-13 : CMSMcQ : made outline from notes of 09-06, +do some housekeeping + + +

+ + +一般事項 + +

拡張可能な&markup;言語XML(eXtensible Markup Language)は，XML文書というデータオブジェクトのクラスを規定し，XML文書を処理するプログラムの動作の一部を規定する。XMLは，SGML(標準一般化&markup;言語，Standard Generalized Markup Language)の制限した⊂とする。構造上，XML文書は，かならずSGML規格に適合する。

XML文書は，実体という記憶単位からなり，実体は，&parsed-data;又は&unparsed-data;からなる。&parsed-data;は，文字からなり，その一部は，文書の文字データを構成し，一部は，&markup;を構成する。&markup;は，文書の記憶レイアウト及び論理構造についての記述を表す符号とする。XMLは，記憶レイアウト及び論理構造についての制約条件を記述する機構を提供する。

XML&processor;というソフトウェアモジュールは，XML文書を読み込み，その内容及び構造へのアクセスを提供するために用いる。 XML&processor;は，他のモジュールのために動作することを前提とし，そのモジュールを&application;という。この&TR-or-Rec;は，XML&processor;が行わなければならない振舞いを規定する。つまり，XMLデータの読込み方法を規定し，&application;に提供する情報を規定する。

+ + +経緯及び目標 +

1996年にWorld Wide Web Consortium(W3C)の中に設立したXML作業グループ(以前は， SGML編集レビュー委員会と呼ばれた)が，XMLを開発した。この作業グループの議長を，Sun MicrosystemsのJon Bosakが勤める。W3Cが組織し，以前はSGML作業グループと呼ばれたXML SIG(Special Interest Group)も，XMLの制定に非常に活発に参画した。 +Dan Connollyは，作業グループのW3Cにおける連絡係を務めた。

XMLの設計目標を，次に示す。 +

a) XMLは，Internet上でそのまま使用できる。

b) XMLは，広範囲の&application;を支援する。

c) XMLは，SGMLと互換性をもつ。

d) XML文書を処理するプログラムを書くことは，容易でなければならない。

e) XMLでは，オプションの機能はできるだけ少なくし，一つも存在しないことを目指す。

f) XML文書は，人間にとって読みやすく，十分に理解しやすい。

g) XMLの設計は，すみやかに行えなければならない。

h) XMLの設計は，厳密及び簡潔でなければならない。

i) XML文書は，容易に作成できる。

j) XMLでは，&markup;の数を減らすことは，重要ではない。

XML第&XML.version;&version;を理解し，それを処理する計算機プログラムを書くために十分な情報は，この&TR-or-Rec;及び関連する規格(文字用として，Unicode及びISO/IEC 10646，&language-identification;タグ用として，インタネット RFC 1766，&language-code;用として，ISO 639，並びに&country-code;用として，ISO 3166)で，すべて示す。

この&version;のXMLの規定は，公開レビュー及び議論を目的とする。テキスト及び法律上の注意を改変しない限り，自由に配布してもよい。

+ + +定義 +

XML文書の規定のために使用する用語は，この&TR-or-Rec;内で定義する。次に示す語句は，それらの用語を定義するため，及びXML&processor;の動きを規定するために使用する。 + + +1.2.1 してもよい(may) +

適合する文書又はXML&processor;は，記述されたとおりに動作してもよいが，そのとおりにする必要はない。

+ + +1.2.2 しなければならない(must) +

適合する文書又はXML&processor;は，記述されたとおりに動作することが要求される。そうでなければ，&error;とする。 +

+ + +1.2.3 &error;(error) +

この&TR-or-Rec;が定める規則に対する違反。結果は定義しない。適合するソフトウェアは，&error;を検出して報告してもよく，&error;から回復してもよい。

+ + +1.2.4 &fatal-error;(fatal error) +

適合するXML&processor;が検出しなければならず，&application;に報告しなければならない&error;。&fatal-error;を発見したあと，&processor;は，それ以降の&error;を探すためにデータ処理を続行してもよく，&error;を発見した場合は，その&error;を&application;に報告してもよい。&error;訂正をサポートするために，&processor;は，未処理データ(文字データ及び&markup;の混在したもの)を文書から取り出し，&application;に渡してもよい。しかし，一度，&fatal-error;を検出したら，&processor;は，通常の処理を続行してはならない。つまり，&processor;は，文字データ及び文書の論理構造についての情報を，通常の方法で&application;に渡し続けてはならない。

+ + +1.2.5 &at-user-option;(at user option) +

適合するソフトウエアは，記述されたとおりに振る舞ってもよい(may)，又は振る舞わなくてはならない(must)(文章中の助動詞による。)。そのとおりに振る舞う場合は，記述された振舞いを選択又は拒否する手段を&user;に提供しなければならない。

+ + +1.2.6 &validity;制約(validity constraint) +

すべての&valid;なXML文書に適用する規則。&validity;制約の違反は，&error;とする。&at-user-option;，検証を行うXML&processor;は，この&error;を報告しなければならない。

+ + +1.2.7 &well-formed;制約(well-formedness constraint) +

すべての&well-formed;のXML文書に適用する規則。&well-formed;制約の違反は，&fatal-error;とする。

+ + +1.2.8 &match;(match) +

a) &string;又は名前の&match;　比較する二つの&string;又は名前は，同一でなければならない。ISO/IEC 10646において，複数の表現が可能な文字［例えば，&composed-form;及び基底+&diacritical-mark;(ダイアクリティカルマーク)形式］は，どちらの&string;も同じ表現のときに限り，&match;する。&at-user-option;，&processor;は，その文字を標準形に正規化してもよい。比較のとき、大文字と小文字との区別をする。 b) &string;と文法中の規則との&match;　ある生成規則から生成する言語に，ある&string;が属するとき，この&string;は，この生成規則に&match;するという。 c) 内容と内容モデルとの&match;　ある要素が，要素の&validity;の制約に示す意味で適合するとき，この要素は，その宣言に&match;するという。

+ + +1.2.9 互換性のため(for compatibility) +

XMLの機能であって，XMLがSGMLと互換であることを保証するためだけに導入されるもの。

+ + +1.2.10 相互運用性のため(for interoperability) +

拘束力はもたない推奨事項。&WebSGML;以前から存在するSGML&processor;が，XML文書を処理できる可能性を高めるために取り入れるもの。

+ + +

+ + + + +文書 +

+ +この&TR-or-Rec;で定義する意味で，&well-formed;とするデータオブジェクトを，XML文書という。&well-formed;のXML文書が，さらに，ある制約条件を満足すれば，&valid;なXML文書とする。 +

+ + + +

いずれのXML文書も，論理構造及び物理構造をもつ。物理的には，文書は，実体と呼ぶ単位からなる。ある実体は，文書内に他の実体を含むために，その他の実体を参照してもよい。文書は，“ルート”すなわち文書実体から始まる。論理的には，文書は，宣言，要素，コメント，文字参照及び処理命令を含み，これらすべては，文書内で明示的な&markup;によって示す。論理構造及び物理構造は，以降に示すとおりに，厳密に入れ子になっていなければならない。

+ + + + +&well-formed;のXML文書 +

あるテキストオブジェクトが，次のいずれかのとき，そのテキストオブジェクトを&well-formed;のXML文書と呼ぶ。 + +

a) 全体として，documentというラベルをもつ生成規則に&match;する。

b) この&TR-or-Rec;で定義する，すべての&well-formed;制約に従う。

+ +

c) それぞれの&parsed-entity;が，&well-formed;となる。

+ +文書 +document +prolog +element +Misc* + +

document生成規則に&match;するとは，次を意味する。 + +

a) 一つ以上の要素を含む。

+ + + + +

b) ルート又は文書要素という要素が一つだけ存在し，これは，他の要素の内容に含まれない。これ以外のすべての要素は，その開始タグが他の要素の内容に含まれれば，対応する終了タグも同じ要素の内容に含まれる。つまり，要素は，開始タグ及び終了タグによって区切られ，入れ子構造をなす。 +

+ +

これらの結果として，文書内のどの非ルート要素Cに対しても，ある他の要素Pが存在し，Cは，Pの内容に含まれるが，Pの内容に含まれる他の要素に含まれることはない。このとき，PをCの親といい，CをPの子という。

+ + +文字 +

+ + + +&parsed-entity;は，テキスト(文字の並びであって，&markup;又は文字データを表してもよい。)を含む。文字は，テキストの最小単位であって，ISO/IEC 10646に規定される。許容する文字は，タブ，改行，復帰並びにUnicode及びISO/IEC 10646が許容する図形文字とする。 + +文字の範囲 + +Char +#x9 | #xA | #xD | [#x20-#D7FF] | [#xE000-#xFFFD] +| [#x10000-#x10FFFF] +任意のUnicode文字。ただし，&surrogate-blocks;，FFFE及びFFFFは除く。 + + + +

&character-value;をビットパタンに符号化する機構は，実体ごとに違ってもよい。すべてのXML&processor;は，ISO/IEC 10646のUTF-8符号化及びUTF-16符号化を受け付けなければならない。二つのどちらが用いられているかを明示するための機構，及び他の符号化方法を利用するための機構は，文字の符号化に記述する。

どの符号化方法を用いるかに関係なく，ISO/IEC 10646の文字集合にあるすべての文字は，そのUCS-4&code-value;と等価な10進数又は16進数によって，参照できる。

+ + + +共通の構文構成子 + +

2.3では，文法内で広く使用するいくつかの記号を定義する。

S (空白)は，一つ若しくは複数の&space-character;(#x20)，復帰，改行又はタブから成る。 + + +空白 + +S +(#x20 | #x9 | #xD | #xA)+ + + +

便宜上，文字を，&letter;，数字又は他の文字に分類する。&letter;は，アルファベット的又は表音的である基本文字(一つ又は複数の&combining-character;が，後に続くこともある。)，&ideographic;から成る。 + +各クラスにおける実際の文字についての完全な定義は，文字クラスに関する付録に規定する。

Nameは，&letter;又はいくつかの区切り文字の一つで始まり，その後に&letter;，数字，ハイフン，下線，コロン又はピリオドが続く(これらを名前文字という。)。&string;"xml"又は(('X'|'x') ('M'|'m') ('L'|'l'))に&match;する任意の&string;で始まる名前は，この&TR-or-Rec;の現在の版又は将来の版での標準化のために予約する。 +

+ +

XMLの名前の中のコロンは，名前空間での実験のために予約する。コロンの意味は，将来のある時点で標準化するものとし，そのときには，実験的な目的でコロンを使用する文書を更新する必要が生じる可能性がある。XMLで採用する名前空間の機構が，区切り子として実際にコロンを使用するという保証はない。事実上，これは，名前空間の実験の一つとして以外には，XMLの名前の中でコロンを使用しないほうがよいことを意味する。しかし，XML&processor;は，名前文字としてコロンを受け付けることが望ましい。 +

+ +

+Nmtoken (名前&token;)は，名前文字で構成する列とする。 + +名前及び&token; + +NameChar +Letter +| Digit + +| '.' | '-' | '_' | ':' +| CombiningChar + +| Extender + +Name +(Letter | '_' | ':') +(NameChar)* +Names +Name +(S Name)* +Nmtoken +(NameChar)+ +Nmtokens +Nmtoken (S Nmtoken)* + +

&literal;データは，引用符で囲まれた&string;とし，その列の区切り子として使用する引用符は含まない。&literal;は，内部実体(EntityValue)，属性値(AttValue)，外部&identifier;(SystemLiteral)の内容の指定に使用する。目的によっては，&literal;全体を，その中の&markup;の走査を行なわずに，スキップすることがある(SkipLit。)。 + +&literal; + + + +EntityValue +' " ' +([^%&"] +| PEReference +| Reference)* +' " ' + +| +" ' " +([^%&'] +| PEReference +| Reference)* +" ' " + +AttValue +' " ' +([^<&"] +| Reference)* +' " ' + +| +" ' " +([^<&'] +| Reference)* +" ' " + + + +SystemLiteral +SkipLit + + +PubidLiteral +' " ' PubidChar* +' " ' +| " ' " (PubidChar - " ' ")* " ' " + +PubidChar +#x20 | #xD | #xA +| [a-zA-Z0-9] +| [-'()+,./:=?] + +SkipLit +(' " ' [^"]* ' " ') +| (" ' " [^']* " ' ") + + + + +

+ + + + + + +文字データ及び&markup; +

テキストは，文字データ及び&markup;が混在するものとして構成する。&markup;は，開始タグ，終了タグ，空要素，実体参照，文字参照，コメント，CDATAセクションの区切り子，文書型宣言及び処理命令の形を取る。 + +

&markup;ではないすべてのテキストは，文書の文字データを構成する。

アンパサンド文字 (&)及び&left-angle-bracket; (<)は，&markup;の区切り子として，又はコメント，処理命令若しくはCDATAセクション内で使用する場合にだけ，そのままの形で出現してよい。これらの文字は，内部実体宣言の&literal;実体値内に記述してもよい。詳しくは，&well-formed;の実体に関する規定を参照。これらの文字が他の部分で必要な場合，数値による文字参照又は&string;"&"及び&string;"<"を使用し，&escape;しなければならない。&right-angle-bracket; (>) は，&string;">"を使用して表現してもよい。内容の中で列"]]>"を使用するときは，それが，CDATAセクションの終了を&markup;しない限り，互換性のため，">"又は文字参照を使用し，&escape;しなければならない。

+ +

要素の内容では，文字データは，いかなる&markup;の開始区切り子を含まない任意の&char-string;とする。CDATAセクションでは，文字データとは，CDATAセクションの終了区切り子"]]>"を含まない任意の&char-string;とする。 +

+属性値に&single-quote;及び&double-quote;を含むためには，アポストロフィ又は&single-quote;(') は，"'"として表現し，&double-quote;(")は，"""として表現する。 + +文字データ + +CharData +[^<&]* - ([^<&]* ']]>' [^<&]*) + + +

+ + + +コメント + +

コメントは，他の&markup;の外ならば，文書のどこに現れてもよい。さらに，文書型宣言内で，文法が許す場所に現れてもよい。 + +コメントは，文書の文字データの一部ではない。XML&processor;は，&application;がコメントのテキストを取り出すことを可能としてもよいが，そうしなくともよい。 +互換性のため，&string;"--" （&double-hyphen;）は，コメント内で現れてはならない。 + +コメント +Comment +'' + + + +

コメントの例を次に示す。 +<!&como; declarations for <head> & <body> &comc;> +

+ + + +処理命令 + +

処理命令(PI)によって，&application;のための命令を文書に入れることができる。 + + +処理命令 +PI +'<?' PITarget +(S +(Char* - +(Char* &pic; Char*)))? +&pic; +PITarget +Name - +(('X' | 'x') ('M' | 'm') ('L' | 'l')) + + +PIは，文書の文字データの一部ではないが，&application;に渡されなければならない。PIは，命令が渡される&application;を&identify;ために使用する⌖ (PITarget) で始まる。⌖名 "XML"，"xml"などは，この&TR-or-Rec;の現在の版又は将来の版の規格化用に予約する。XMLの記法機構を，PIの⌖を宣言するために使用してもよい。 +

+ + + +CDATAセクション + +

CDATAセクションは，文字データが出現するところであれば，どこに出現してもよい。これは，そうでなければ，&markup;として認識する文字を含む，テキストの区画を&escape;するのに使用する。CDATAセクションは，&string;"<![CDATA["で始まり，&string; +"]]>"で終わる。 + +CDATAセクション +CDSect +CDStart +CData +CDEnd +CDStart +'<![CDATA[' + +CData + +(Char* - +(Char* ']]>' Char*)) + + +CDEnd +']]>' + + + +CDATAセクション内では，列CDEndだけを&markup;として認識するので，&left-angle-bracket;及びアンパサンドは，その&literal;形式で出現してよい。それらは，"<"及び"&"を使用して&escape;する必要はない。CDATAセクションは，入れ子にはできない。 + +

+ +

"<greeting>"及び"</greeting>"を，&markup;ではなく，文字データとして認識するCDATAセクションの例を，次に示す。 +<![CDATA[<greeting>Hello, world!</greeting>]]> +

+ + + +&prolog;及び文書型宣言 + +

XML文書は，使用するXMLの&version;を指定するXML宣言で始めてもよく，又そうするのが望ましい。 + +

この&TR-or-Rec;のこの&version;に適合することを示すためには，&version;番号 "1.0" を使用しなければならない。ある文書が，この&TR-or-Rec;のこの&version;に適合しないとき，値"1.0"を使用するのは，&error;とする。この&TR-or-Rec;の今後の&version;に"1.0"以外の値を付与することが，XML作業グループの意図だが，XMLの将来の&version;を作成することの確約を示すわけではなく，作成したとしても，番号付けについて，特定の方法を使用することの確約を示すわけでもない。将来の&version;の可能性を除外しないので，必要な場合，自動的な&version;の認識を可能とする手段として，この構成子を提供する。&processor;は，サポートしていない&version;でラベル付けした文書を受け取ったとき，&error;を通知してもよい。 +

XML文書内の&markup;の機能は，記憶構造及び論理構造を記述すること，並びに属性及び属性値の対を論理構造に関連づけることにある。XMLは，論理構造についての制約条件を定義するため，及びあらかじめ定義された記憶単位を使用できるための機構として，文書型宣言を提供する。XML文書が&valid;とは，文書型宣言をもち，その文書型宣言に示す制約条件を満たすこととする。 +

文書型宣言は，文書の最初の要素の前に現れなければならない。 + +&prolog; + +prolog +XMLDecl? +Misc* +(doctypedecl +Misc*)? +XMLDecl +&xmlpio; +VersionInfo +EncodingDecl? +SDDecl? +S? +&pic; + +VersionInfo +S 'version' Eq +('"VersionNum"' +| "'VersionNum'") + +Eq +S? '=' S? + +VersionNum +([a-zA-Z0-9_.:] | '-')+ + +Misc +Comment | PI | +S + +

+ +

+例えば，次に示す完全なXML文書は，&well-formed;であるが&valid;ではない。 + +Hello, world! +]]> +次の文書も同様とする。 +Hello, world! +]]> +

+XMLの文書型宣言は，ある文書クラスのための文法を提供する&markup;宣言を含むか，又は参照する。この文法を，文書型定義又はDTDという。文書型宣言は，&markup;宣言を含んだ外部⊂(特別な種類の外部実体)を参照でき，又は内部⊂に直接&markup;宣言を含むこともできる。さらに，その両方も可能とする。ある文書のDTDは，両方の⊂をまとめたものとして構成する。 +

+&markup;宣言は，要素型宣言，属性リスト宣言，実体宣言又は記法宣言とする。次に示す&well-formed;制約及び&validity;制約に規定するが，これらの宣言は，¶meter;実体内に全体又は一部が含まれてもよい。詳しい規定は，物理構造に関する規定を参照のこと。

+文書型宣言におけるNameは，&root;要素の型と&match;しなければならない。 +

+ + + +宣言及び¶meter;実体が厳密に入れ子をなすこと +

¶meter;実体の&replacement-text;は，&markup;宣言内において，厳密に入れ子になっていなければならない。つまり，&markup;宣言(markupdecl)の最初又は最後の文字が，¶meter;実体参照の対象となる&replacement-text;に含まれれば，両方とも同じ&replacement-text;に含まれなければならない。

+ + +内部⊂内の¶meter;実体 +

DTDの内部⊂では，¶meter;実体参照は，&markup;宣言が出現可能な場所だけに出現できる。&markup;宣言内には出現できない(この制約は，外部¶meter;実体又は外部⊂での参照には適用しない。)。 +

+ +

+内部⊂のときと同様に，外部⊂及びDTDにおいて参照する任意の外部¶meter;実体は，非終端記号markupdeclによって許される型の，一連の完全な&markup;宣言で構成されなければならない。&markup;宣言の間には，空白又は¶meter;実体参照を置いてもよい。しかし，外部⊂又は外部¶meter;実体の内容の一部は，条件付きセクションを使用して無視してもよい。内部サブセットでは，これは許されない。 + + +外部⊂ + +extSubset +( +markupdecl +| conditionalSect +| PEReference +| S +)* + + +

外部⊂及び外部¶meter;実体は，その内では，¶meter;実体が&markup;宣言の間だけでなく，&markup;宣言の内でも認識される，という点でも内部⊂とは異なる。 +

文書型宣言付きのXML文書の例を，次に示す。 + + +Hello, world! +]]> +システム&identifier; "hello.dtd"が，文書のDTDのURIとなる。

次の例のとおり，宣言を局所的に与えることもできる。 + + +]> +Hello, world! +]]> +外部⊂及び内部⊂の両方を使用するときは，内部⊂が外部⊂より先に出現したと見なす。これは，内部⊂の実体及び属性リスト宣言が，外部⊂の実体及び属性リスト宣言より優先するという効果をもたらす。 +

+ + + +&standalone;文書宣言 +

XML&processor;は，&application;に文書の内容を渡すが，&markup;宣言は，この内容に影響を与えることがある。属性の&default-value;及び実体宣言をその例とする。XML宣言の一部分として出現できる&standalone;文書宣言は，文書が，その&markup;宣言の存在によって影響されないことを指し示す（普通，その&markup;宣言が存在しないために，これがいえる。）。 + +&standalone;文書宣言 + +SDDecl + +S +'standalone' Eq "'" ('yes' | 'no') "'" + + +| S +'standalone' Eq '"' ('yes' | 'no') '"' + + +

&standalone;文書宣言においては, "yes"の値は，文書実体の外部に（DTDの外部⊂内に，又は内部⊂から参照される外部パラメタ実体内に），XML&processor;から&application;へと渡される情報に影響する&markup;宣言が存在しないことを意味する。"no"の値は，その外部&markup;宣言が存在するか，又は存在する可能性があることを意味する。&standalone;文書宣言は，その宣言が文書外部に存在するかどうかを示すだけに注意すること。外部実体への参照が文書内に存在していても，その実体が内部的に宣言されているときは，文書の&standalone;の状態には影響を与えない。

+ +

外部に&markup;宣言が存在しなければ，&standalone;文書宣言は意味をもたない。外部に&markup;宣言が存在し，&standalone;文書宣言が存在しない場合は，"no" の値の設定を仮定する。

XML文書で standalone="no" が設定されているものは，あるアルゴリズムで&standalone;文書に変換でき，この文書は，ネットワーク配信&application;にとって望ましいかもしれない。

+ +&standalone;文書宣言 +

&standalone;文書宣言は，何らかの外部&markup;宣言が次のいずれかを宣言しているときは，値 "no" を取らなければならない。 + +

a) &default;値付きの属性であって，この属性が適用される要素が，属性値を指定せずに文書内に現れるもの。

b) &magicents;以外の実体であって，その実体に対する参照が文書内に出現するもの。

+ +

c) 値が正規化の対象となる属性であって，正規化の結果として変化する値が文書内で属性に指定されるもの。

+ +

d) 要素内容をもつ要素型であって，空白がその要素型のいずれかのインスタンス内に直接現れるもの。 +

+ +

&standalone;文書宣言付きのXML宣言の例を，次に示す。 +<?xml version="&XML.version;" standalone='yes'?>

+ + +空白の取扱い +

XML文書を編集するときは，&markup;を目立たせ読みやすくするために，“空白”(&space;，タブ及び空白行。この&TR-or-Rec;では，非終端記号のSで表す)を使うと便利なことが多い。その空白は，配布する&version;の文書の一部として含めることを意図しないのを普通とする。しかし，“意味のある”空白であって，配布する&version;に残さなければならないものも多い。例えば，詩及びソースコードにおける空白がある。

XML&processor;は，文書内の&markup;以外のすべての文字を，そのまま変更せずに&application;に渡さなければならない。&validating;XML&processor;は，要素内容の中の空白を他の非&markup;文字から区別し，&application;側に要素内容の中の空白が重要でないということを伝えなければならない。

+"xml:space"という特別な属性を文書に挿入することによって，空白を重要とする意図を示してもよい。この属性を適用する要素に現れる空白を，アプリケーションが重要なものとして扱うことを要求する，という意図を示す。

&valid;な文書では，この属性を使用する場合は，他の属性と同じように宣言しなければならない。宣言するときは，取り得る値を"default"及び "preserve"だけとする列挙型でなければならない。 +

値"default"は，&application;の&default;の空白処理モードを，その要素に適用可能とすることを意味する。値"preserve"は，&application;がすべての空白を保存することを意味する。この宣言の意図は，"xml:space" 属性の別の指定で上書きしない限り，要素の内容に現れるすべての要素に適用すると解釈する。

文書の&root;要素については，この属性の値を指定するか，又はこの属性の&default-value;がある場合を除いては，&application;による空白の取扱いについて，いかなる意図も示さないと解釈する。

例を次に示す。 +]]> +

+ + +行末の取扱い +

XMLの構文&parsed-entity;は，通常コンピュータのファイル内に保存され，編集の便宜のために複数の行に分けることが多い。これらの行は，普通は，CR (#xD)コード及び LF (#xA)コードの何らかの組合せによって分けられる。

&application;の処理を簡単にするため，外部&parsed-entity;又は内部&parsed-entity;の&literal;実体値が，"#xD#xA" の２文字の連続とする&literal;又は#xDの単独の&literal;を含む場合に，XML&processor;は，&application;に単一の文字#xAだけを渡さなければならない(この処理は，入力内に存在する改行コードを構文解析の前に正規化することによって，容易に実現できる。)。

+ + +&language-identification; +

文書処理においては，その文書の中身がどんな自然言語又は形式言語で書かれているか明示することが，役に立つことが多い。

+ +

XML文書内の要素のもつ内容又は属性値において使用する言語を指定するために，"xml:lang" という名前の特別な属性を，文書内に挿入してもよい。 + +属性の値は，“RFC1766：&language-identification;のためのタグ”によって規定される&language-identification;コードに従う。 + +&language-identification; +LanguageID +Langcode +('-' Subcode)* +Langcode +ISO639Code | +IanaCode | +UserCode + +ISO639Code +([a-z] | [A-Z]) ([a-z] | [A-Z]) +IanaCode +('i' | 'I') '-' ([a-z] | [A-Z])+ +UserCode +('x' | 'X') '-' ([a-z] | [A-Z])+ +Subcode +([a-z] | [A-Z])+ + +Langcodeは，次のどれでもよい。 + +

a) “言語の名前表現のためのコード”で規定される2文字の&language-code;

b) Internet Assigned Numbers Authority (IANA)で登録されている&language-code;。これは，先頭が "i-" (又は"I-")で始まる。

c) &user;によって定められた&language-code;，又は私的な使用のために複数の団体間が取り決めたコード。これらは，今後IANAにおいて標準化又は登録されるコードとの競合を避けるために，先頭を"x-" 又は "X-" で始める。

Subcodeは，複数回使ってもよい。最初のサブコードが存在し，その内容が二つの文字から成るときは，ISO3166の“国名を表すコード(国コード)”でなければならない。最初のサブコードが3文字以上から成るときは，Langcodeの先頭が，"x-" 又は "X-"で始まらない限り，指定した言語に対するサブコードとし，IANAに登録されたものでなければならない。

&language-code;は，小文字での表記を，&country-code;は，(存在するならば)大文字での表記を慣行とする。しかし，XML文書内における他の名前とは異なり，これらの値については，大文字及び小文字の区別をしないことに注意すること。

例を次に示す。 +The quick brown fox jumps over the lazy dog.

What colour is it?

What color is it?

+ + Habe nun, ach! Philosophie, + Juristerei, und Medizin + und leider auch Theologie + ]]>durchaus studiert mit heißem Bemüh'n. + ]]>

+ +

xml:langで宣言する意図は，xml:langの別の指定で上書しない限り，指定した要素の内容に含むすべての要素に適用する。

+ +

+&valid;な文書においては，この&TR-or-Rec;の他の場所で規定するとおり，この属性を必ず宣言しなければならない。通常，宣言は，次の形とする。 +xml:lang NMTOKEN #IMPLIED +必要ならば，特定の&default-value;を与えてもよい。英語を母語とする学生用のフランス語の詩集では，説明及び注を英語で記述すれば，xml:lang 属性を次のとおりに宣言することとなる。 + + + ]]> +

+ + + + + + +論理構造 + +

いかなるXML文書も，一つ以上の要素を含む。要素の境界は, 開始タグ及び終了タグによって区切る。要素が空要素のときは，空要素タグで示す。各々の要素は，型をもつ。要素型は名前(共通&identifier;(generic identifier)又はGIと呼ぶことがある。)によって&identified;。要素は，いくつかの属性をもつことができる。属性は，名前及び値をもつ。

+ +要素 +element +EmptyElemTag +| STag content +ETag + +

この&TR-or-Rec;は，要素型及び属性の意味，使用方法，又は(構文に関することを除き)名前に制約を与えない。ただし，先頭が(('X'|'x')('M'|'m')('L'|'l'))に&match;する名前は，この版又は今後の版のこの&TR-or-Rec;での標準化のために予約する。

+ +要素型の&match; +

要素の終了タグの名前は，その要素の開始タグにおける型と&match;しなければならない。

+ + + +開始タグ，終了タグ及び空要素タグ +

空でない任意のXML要素の始まりは，開始タグによって&markup;する。 +開始タグ + +STag'<' Name (S Attribute)* S? '>' +AttributeName Eq AttValue + + +開始タグ及び終了タグ内のNameは，要素の型を表わす。Name及びAttValueの対を要素の属性指定といい，個々の対におけるNameは，属性名及びAttValueの内容(区切り子'又は"の間の&string;)を属性値という。

+ +属性指定の一意性 +

開始タグ又は空要素タグでは，同一の属性名が２度以上出現してはならない。

+属性値の型 +

属性は宣言されていなければならない。属性値の型は，その属性に対して宣言した型でなければならない(属性の型については，属性リスト宣言についての規定を参照。)。

+外部実体への参照がないこと +

属性値には，外部実体への直接的又は間接的な参照を含むことはできない。

+属性値に<を含まないこと +

属性値内で直接的又は間接的に参照する実体(<を除く。)の&replacement-text;には，<を含んではならない。

+ +

開始タグの例を，次に示す。 +<termdef id="dt-dog" term="dog">

開始タグで始まる要素の終わりは，終了タグで&markup;しなければならない。この終了タグは，対応する開始タグの要素型と同じ名前をもつ。 +終了タグETag'</' Name S? '>'

終了タグの例を，次に示す。 +</termdef>

+ +

+ +

要素が空のとき，その要素は，直後に終了タグをもつ開始タグ又は空要素タグで表現しなければならない。空要素タグは，次の特別な形式をとる。 +空要素のためのタグEmptyElemTag'<' Name (S Attribute)* S? '/>'

+ + + +

空要素タグは，内容をもたない任意の要素の表現に利用できる。空要素タグで表現する要素を，キーワードEMPTYを用いて宣言しなくともよい。

空要素の例を，次に示す。 +<IMG align="left" src="http://www.w3.org/Icons/WWW/w3c_home" />

+ + +要素宣言 +

&validity;を保証するため，要素宣言及び属性リスト宣言を用いてXML文書の要素の構造に，制約を加えることができる。

要素宣言は，要素の内容についての制約とする。

要素宣言は，要素の子として出現可能な要素型について，制約を加えることが多い。&at-user-option;，要素宣言をもたない要素型が他の要素宣言によって参照されれば，XML&processor;は，警告を出してもよい。しかし，これは&error;とはしない。

+ +

要素型宣言は，次の形式をとる。 +要素型宣言 +elementdecl +'<!ELEMENT' S +Name +S +contentspec +S? '>' + +contentspec +'EMPTY' +| 'ANY' +| Mixed +| children + + + + + +ここで，Nameは，宣言されている要素の型とする。

+ +要素宣言の一意性 +

要素型を２度以上宣言できない。

+ +要素の&validity; +

要素が&valid;とは，elementdeclに&match;する宣言であって，そのNameがその要素型と&match;し，次のいずれかの条件を満たす場合とする。 +

a) 宣言がEMPTYに&match;し，要素が内容をもたない。

b) 宣言がchildrenに&match;し，要素の子要素の並びが，内容モデルの正規表現によって生成される言語に属する。

c) 宣言がmixedに&match;し，要素の内容が文字データ及び子要素からなる。子要素の要素型は，要素の内容モデルに出現する名前に&match;する。

d) 宣言がANYに&match;し，どの子要素の要素型も宣言されている。

+ +

+ + +

要素宣言の例を，次に示す。 + +<!ELEMENT br EMPTY> +<!ELEMENT p (#PCDATA|emph)* > +<!ELEMENT %name.para; %content.para; > +<!ELEMENT container ANY> +

+ +要素内容 + +

ある型の要素が子要素だけを含む(文字データを含まない。)とき，その要素型は，要素内容をもつ，という。この場合，制約は，内容モデルを含む。内容モデルは，子要素の型及び子要素の出現順序を制御する簡単な文法とする。この文法は，&content-particle;(cps)からなる。&content-particle;は，名前，&content-particle;の選択リスト又は&content-particle;の列リストから構成される。 +要素内容モデル +children(choice | seq) ('?' | '*' | '+')?cp(Name | choice | seq) ('?' | '*' | '+')? +choice'(' S? cp ( S? '|' S? cp )*S? ')' +seq'(' S? cp ( S? ',' S? cp )*S? ')' + + +ここで，Nameは，子として出現してよい要素の型を示す。この文法で選択リストが現れる位置では，選択リスト内のいずれの&content-particle;も要素内容の中に現れてよい。列リストに現れる&content-particle;は，リストで指定する順番のとおりに，要素内容に現れなければならない。名前又はリストの後に出現するオプションの文字は，リスト内の要素又は&content-particle;が，1回以上任意の回数(+)，0回以上任意の回数(*)又は0回若しくは1回(?)出現可能なことを規定する。ここで示す構文及び意味は，この&TR-or-Rec;における生成規則で用いるものと同一とする。

+ + + +

要素の内容が内容モデルに&match;するのは，列，選択及び繰返し演算子にしたがって，内容の中の要素と内容モデル内の要素型とを&match;させながら，内容モデル内の一つのパスをたどれるときに限る。互換性のため，文書内の要素が，内容モデルにおける要素型の複数の出現位置と&match;することは，&error;とする。詳細な規定については，附属書の決定的内容モデルの項を参照。 + + +

+ + +グループ及びパラメタ実体が厳密な入れ子をなしていること +

パラメタ実体の&replacement-text;は，&parenthesis;で囲まれたグループによって，厳密な入れ子を構成しなければならない。つまり，選択，列又は混在部品に，&left-parenthesis;又は&right-parenthesis;のいずれか一方がパラメタ実体の&replacement-text;に含れれば，他方も同じ&replacement-text;に含まれなければならない。

相互運用性のため，パラメタ実体参照が選択，列又は混在内容に含まれれば，その&replacement-text;は空でないことが望ましく，&replacement-text;の先頭及び末尾の空白でない文字は，コネクタ(|又は,)でない方がよい。 +

+ +

要素内容モデルのいくつかの例を，次に示す。 +<!ELEMENT spec (front, body, back?)> +<!ELEMENT div1 (head, (p | list | note)*, div2*)> +<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>

+ + + +&mixed-content; + +

ある要素型の要素内に，子要素に混在して文字データが含まれる可能性があるとき，その要素型は，&mixed-content;をもつという。この場合，子要素の型についての制約が存在してもよいが，子要素の順序又は出現回数についての制約はないとする。 + +&mixed-content;宣言 + +Mixed +'(' S? +'#PCDATA' +(S? +'|' +S? +Name)* +S? +')*' +| '(' S? '#PCDATA' S? ')' + + + + + + +ここで，Nameは，子として出現してもよい要素の型を示す。 +

+ + +要素型の重複の禁止 +

一つの&mixed-content;宣言内に，同じ名前が複数回出現してはならない。 +

+ + + + + +属性リスト宣言 +

+属性は，名前及び値の対を要素に関連付けるために用いる。属性指定は，開始タグ又は空要素タグ内でだけ可能とする。したがって，属性を認識するための生成規則は，開始タグについての規定で示す。属性リスト宣言は，次の目的で用いる。 + +

a) ある要素型に適用する属性の集合を規定する。

b) 属性への型制約を設定する。

c) 属性の&default-value;を規定する。

+ +

+ +属性リスト宣言は，ある要素型と関連付けられた各属性に対し，名前，データ型及び(存在すれば)&default-value;を規定する。 + +属性リスト宣言 +AttlistDecl +'<!ATTLIST' S +Name +AttDef* +S? '>' + +AttDef +S Name +S AttType +S Default + + + +AttlistDecl規則に存在するNameは，要素型の名前とする。&at-user-option;，宣言していない要素型に対し属性を宣言したならば，XML&processor;は，警告を出してもよい。しかし，これは&error;とはしない。 +AttDef規則におけるNameは，属性の名前とする。 + +

+ある要素に対して，複数のAttlistDeclを与える場合，これらすべての内容はマージする。ある要素型の同じ属性に，複数の定義を与える場合には，最初の宣言を有効とし，他の宣言は無視する。相互運用性のために，DTDの作成者は，ある要素型には高々一つの属性リスト宣言しか与えない，ある属性名には高々一つの属性定義しか与えない，及びすべての属性リスト宣言には少なくとも一つの属性定義を与える，という選択をしてもよい。相互運用性のために，XML&processor;は，&at-user-option;，ある要素型に複数の属性リスト宣言を与えたり，ある属性に複数の属性定義を与えたりしたときに，警告を出してもよい。しかし，これは，&error;とはしない。 +

+ + +属性の型 +

+ + +ID +

+この型の値は，生成規則Nameに&match;しなければならない。一つのXML文書内では，一つの名前が，この型の値として複数回現れてはならない。つまり，IDの値は，要素を一意に&identify;しなければならない。 +

+ + +1要素ごとに1ID +

+要素型は，複数のID属性値をもってはならない。 +

+ + +ID属性の&default; +

+ID属性は，&default;として，#IMPLIED又は#REQUIREDを宣言しなければならない。 +

+ + +IDREF +

+IDREF型の値は，生成規則Nameに&match;しなければならない。IDREFS型の値は，生成規則Namesに&match;しなければならない。各々のNameは，XML文書内に存在する要素のID属性の値と&match;しなければならない。つまり，IDREFの値は，あるID属性の値と&match;しなければならない。 +

+ + +実体名 +

+ENTITY型の値は，生成規則Nameに&match;しなければならない。ENTITIES型の値は，生成規則Namesに&match;しなければならない。各々のNameは，DTDで宣言する&unparsed-entity;と&match;しなければならない。 +

+ + +名前&token; +

+NMTOKEN型の値は，非終端記号Nmtokenと&match;する&string;から構成されなければならない。NMTOKENS型の値は，非終端記号Nmtokensと&match;する&string;から構成されなければならない。 +

+ +

+XML&processor;は，&application;に属性値を渡す前に，属性値の正規化で規定するとおりに，属性値を正規化しなければならない。 +

+列挙型の属性は，宣言した値の一つを取ることができる。列挙型には，2種類ある。 + + +列挙属性の型 +EnumeratedType +NotationType +| Enumeration + +NotationType +'NOTATION' +S +'(' +S? +Name +(S? '|' Name)* +S? ')' + + +Enumeration +'(' S? +Nmtoken +(S? '|' +S? +Nmtoken)* +S? +')' + + +

+ + +記法属性 +

この型の値は，宣言している記法の名前の一つと&match;しなければならない。つまり，宣言に存在する記法名は，すべて宣言されていなければならない。 +

+ + +列挙 +

+この型の値は，宣言に存在するNmtoken&token;の一つと&match;しなければならない。 +

+ +

+相互運用性のため，同じNmtokenは，単一要素型の列挙型の属性として，複数回現れない方がよい。 +

+ + + +属性の&default; + +

+属性宣言は，属性の指定が必須かどうかについての情報を与える。必須でない場合には，文書内で属性を指定しないとき，XML&processor;の処理方法の情報も与える。 + + +属性の&default; + +Default +'#REQUIRED' +| '#IMPLIED' +| (('#FIXED' S)? AttValue) + + + + + + +

+ + +属性&default;の正しさ +

+宣言した&default-value;は，宣言した属性型の字句制約を満たさなければならない。 +

+ +

+#REQUIREDを指定したとき，この要素型の開始タグであって，この属性に値を与えないものをXML&processor;が見つけたならば，その文書は&valid;とはしない。#IMPLIEDを指定したとき，この属性を省略したら，XML&processor;は，属性値を指定しないことをアプリケーションに伝えなければならない。このとき，&application;の振舞いについての制約はない。 +

+ +属性が#REQUIREDでも#IMPLIEDでもないときには，AttValueの値が，&default-value;となる。#FIXEDの場合，&default-value;と異なる値が指定されれば，その文書は，&valid;としない。&default-value;を宣言している場合，この属性の省略を見つけたら，宣言した&default-value;を属性値に指定しているとして，XML&processor;は振る舞うことが望ましい。 +

+ +

属性リスト宣言の例を，次に示す。 + +<!ATTLIST termdef + id ID #REQUIRED + name CDATA #IMPLIED> +<!ATTLIST list + type (bullets|ordered|glossary) "ordered"> +<!ATTLIST form + method CDATA #FIXED "POST">

+ + + +属性値の正規化 +

+XML&processor;は，属性値を&application;に渡す前に，次のとおりに正規化しなければならない。 + + + +

a) まず，属性値及びその中の実体内で，行末又は行境界(又はシステムによってはレコード境界)として使われる&string;を，&space-character;(#x20)一つに置き換えなければならない(「行末の扱い」も参照のこと。)。 +

+ +

b) 次に，文字参照及び内部&parsed-entity;への参照は，展開しなければならない。外部実体への参照は，&error;とする。 +

+ +

c) 最後に，属性の型がCDATAでなければ，空白&string;は，すべて&space-character;(#x20)一つに正規化し，残りの空白文字は，削除しなければならない。 +

+ + +&non-validating;&parser;は，宣言が見つからない属性は，すべて，CDATAを宣言しているとして扱うことが望ましい。

+ + + + +条件付きセクション +

+ +条件付きセクションとは，文書型宣言の外部⊂の一部とし，制御キーワードの指定によって，DTDの論理構造に含めたり，除いたりする部分とする。 + + + +条件付きセクション + +conditionalSect +includeSect +| ignoreSect + + +includeSect +'<![' S? 'INCLUDE' S? '[' + +extSubset +']]>' + + +ignoreSect +'<![' S? 'IGNORE' S? '[' +ignoreSectContents* +']]>' + +ignoreSectContents +Ignore +('<![' ignoreSectContents +']]>' +Ignore)* +Ignore +Char* - +(Char* ('<![' | ']]>') +Char*) + + + + +

+ +

条件付きセクションは，DTDの内部⊂及び外部⊂と同様に，完全な宣言，コメント又は入れ子になった条件付きセクションを，いくつか含んでよい。これらの間に，空白が現れてもよい。 +

+条件付きセクションのキーワードがINCLUDEならば，XML&processor;は，この条件付きセクションの内容を，文書の一部として扱わなければならない。条件付きセクションのキーワードがIGNOREならば，その条件付きセクションの内容は，文書の一部として扱わない。構文解析を正しく行うためには，無視する条件付きセクション(IGNORE)に関しても，内容を読まなければならないことに注意すること。これは，入れ子になった条件付きセクションを見つけ，(無視する)最も外側の条件付きセクションを正しく検出するためとする。キーワードをINCLUDEとする小さな条件付きセクションが，キーワードをIGNOREとするより大きな条件付きセクションに含まれるならば，外側及び内側の条件付きセクションの両方とも無視する。 +

+条件付きセクションのキーワードがパラメタ実体参照ならば，XML&processor;は条件付きセクションの扱いを判断する前に，このパラメタ実体を展開しなければならない。 +

+ +

例を次に示す。 + +<!ENTITY % draft 'INCLUDE' > +<!ENTITY % final 'IGNORE' > + +<![%draft;[ +<!ELEMENT book (comments*, title, body, supplements?)> +]]> +<![%final;[ +<!ELEMENT book (title, body, supplements?)> +]]> + +

+ + + + + + + +物理構造 + +

+ +XML文書は，一つ以上の記憶単位から構成する。この記憶単位を，実体という。実体は，内容をもち，文書実体(以降参照)及び外部DTD⊂を除いて，名前で&identified;。 + + + + + + + + + + +各XML文書は，文書実体と呼ぶ実体を一つもつ。XML&processor;は，この文書実体から処理を開始する。文書実体が，文書のすべてを含んでもよい。

+ +

実体は，&parsed-entity;又は&unparsed-entity;とする。&parsed-entity;の内容は，&parsed-entity;の&replacement-text;と呼ぶ。このテキストは，文書の本体の一部として解釈する。 + +

+ +

+ +&unparsed-entity;は，内容がテキストでもそうでなくともよいリソースとする。テキストの場合，XMLでなくともよい。各&unparsed-entity;には，記法が関連付けられ，この記法は，名前で&identified;。記法の名前及び関連付けられた&identifier;を，XML&processor;が&application;に渡すという要件以外は，XMLは，&unparsed-entity;の内容を制限しない。 + +

+ +

&parsed-entity;は，実体参照によって名前で呼び出す。&unparsed-entity;は，ENTITY型又はENTITIES型の属性の値として，名前で参照する。

+ +

+一般実体は，文書内容の中で使用する&parsed-entity;とする。あいまいにならない限り，この&TR-or-Rec;では，一般実体を単に実体と呼ぶ。パラメタ実体は，DTD内で使用する&parsed-entity;とする。これらの２種類の実体は，異なる書式で参照し，異なる文脈で認識する。

+ + + + +文字参照及び実体参照 +

+ +文字参照は，ISO/IEC 10646文字集合の特定の文字，例えば，入力機器から直接入力不可能な文字を参照する。 + + +文字参照 +CharRef +'&#' [0-9]+ ';' +| '&hcro;' [0-9a-fA-F]+ ';' + + + + +正当な文字 +

文字参照で参照する文字は，非終端記号Charに従わなければならない。

+ +文字が "&#x" で始まれば，終端の ";" までの数字及びアルファベットは，ISO/IEC 10646 の文字コードの16進数表現とする。 + +文字が "&#" で始まれば，終端の ";" までの数字は，文字コードの10進数表現とする。 + +

+ +

+ +実体参照は，名前の付いた実体の内容を参照する。一般実体への参照は，アンパサンド(&)及びセミコロン(;)を区切り子として用いる。パラメタ実体への参照は，パーセント記号(%)及びセミコロン(;)を区切り子として用いる。 + +

+ + +実体参照 +Reference +EntityRef +| CharRef +EntityRef +'&' Name ';' + + + + + +PEReference +'%' Name ';' + + + + + + + + + +実体が宣言されていること +

DTDをもたない文書，パラメタ実体参照を含まない内部DTD⊂だけをもつ文書，又は "standalone='yes'" をもつ文書において，実体参照で用いる Name は，その実体の宣言で与える名前と，&match;しなければならない。ただし，&well-formed;の文書は，実体&magicents; を宣言する必要はない。パラメタ実体の場合は，宣言は，参照に先行しなければならない。同様に，一般実体の場合は，属性リスト宣言の&default-value;内での参照より先に，宣言が現れなければならない。

+ +

外部⊂又は外部パラメタ実体で実体を宣言するとき，&non-validating;&processor;が，宣言を読み，処理することを義務づけない。それらの文書では，実体は宣言されなければならないという規則は，&well-formed;制約ではない。 +

+ + + +実体が宣言されていること +

+外部⊂又は外部パラメタ実体をもっていて，"standalone='no'"をもつ文書において，実体参照で用いる Name は，その実体の宣言で与える名前と&match;しなければならない。相互運用性のため，&valid;な文書はあらかじめ定義した実体の規定で指定した書式によって，実体 &magicents;を宣言することが望ましい。パラメタ実体の場合は，宣言は，参照に先行しなければならない。同様に，一般実体の場合は，属性リスト宣言の&default-value;内での参照よりも先に，宣言が現れなければならない。 +

+ + + + + +&parsed-entity; +

+実体参照は，&unparsed-entity;の名前を含んでいてはならない。&unparsed-entity;は，ENTITY型又はENTITIES 型として宣言した属性値としてだけ参照できる。 +

+ + + +再帰なし +

&parsed-entity;は，それ自体への参照を，直接にも間接にも含んではならない。

+ + + +DTDの中 +

+パラメタ実体参照は，DTD内にだけ，出現してよい。 + +

+ + +

+文字参照及び実体参照の例を，次に示す。 +Type <key>less-than</key> (&hcro;3C;) to save options. +This document was prepared on &docdate; and +is classified &security-level;. +

+ +

+パラメタ実体参照の例を，次に示す。 +<!ENTITY % ISOLat2 + SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" > +%ISOLat2; + +

+ + + +実体宣言 + +

+ +実体は，次のとおりに宣言する。 + +実体宣言 + +EntityDecl +GEDecl一般実体 +| PEDeclパラメタ実体 + +GEDecl +'<!ENTITY' S Name +S EntityDef +S? '>' + +PEDecl +| '<!ENTITY' S '%' S +Name S +PEDef S? '>' +パラメタ実体 + +EntityDef +EntityValue + + +| ExternalDef + + + +PEDef +EntityValue +| ExternalID + + + +Name は，実体参照において実体を&identify;。&unparsed-entity;ならば，ENTITY 型又はENTITIES型の属性値内で，実体を&identify;。同一の実体が一回以上宣言されれば，最初の宣言を用いる。&at-user-option;，複数回宣言される実体に関し，XML&processor;は，警告を出してもよい。 + +

+ + + + +内部実体 +

+ +実体の定義が EntityValueのとき，これを内部実体という。これは，別個の物理的記憶単位をもたず，実体の内容は，宣言内で与える。正しく&replacement-text;を生成するには，&literal;実体値内での実体参照及び文字参照の処理が，必要となるかもしれないことに注意する。詳細は，内部実体の&replacement-text;の構築を参照。 + + + +

+ +

+内部実体は，&parsed-entity;とする。 +

+ +

内部実体宣言の例を，次に示す。 +<!ENTITY Pub-Status "This is a pre-release of the specification.">

+ + + +外部実体 +

+ +実体が内部実体でなければ，外部実体とし，次のとおりに宣言する。 + + +外部実体宣言 +ExternalDef +ExternalID +NDataDecl? +ExternalID +'SYSTEM' S +SystemLiteral +| 'PUBLIC' S +PubidLiteral +S +SystemLiteral + + +NDataDecl +S 'NDATA' S +Name + + + +NDataDecl が存在すれば，この実体は，&unparsed-entity;とし，そうでなければ，&parsed-entity;とする。 +

+ + +記法が宣言されていること +

+Name は，宣言した記法の名前と&match;しなければならない。 +

+ + +

+ +キーワード SYSTEM の後の SystemLiteral を，実体のシステム&identifier;と呼ぶ。これはURIとし，その実体の内容を取り出すのに用いてもよい。URIと共に使うことの多いハッシュ("#")及びフラグメント&identifier;は，正式には，URI自体の一部とはしない。フラグメント&identifier;が，システム&identifier;の部分として与えられている場合，XML&processor;は，&error;を出してもよい。この&TR-or-Rec;の範囲外の情報(例えば，ある特定のDTDの特別なXML要素又は特定の&application;の仕様によって定義された処理命令)によって上書きされない限り，相対的なURIは，その実体の位置，すなわち，その実体の宣言があるファイルに相対的とする。したがって，DTDの内部⊂にある実体宣言での相対的なURIは，文書の位置について相対的とする。外部⊂にある実体宣言での相対的なURIは，その外部⊂を含むファイルの位置に相対的とする。 +

+ +

+ +システム&identifier;以外に，外部実体は，公開&identifier;を含んでもよい。 + +実体の内容を取り出すXML&processor;は，この公開&identifier;を用いて，代わりのURIの生成を試みてもよい。XML&processor;がこれに失敗した場合は，システム&literal;として指定したURIを用いなければならない。&match;する前に，公開&identifier;内にある空白文字からなる&string;は，すべて単一の&space-character;(#x20)に正規化しなければならず，前後の空白文字は削除しなければならない。 +

+ +

外部実体宣言の例を，次に示す。 +<!ENTITY open-hatch + SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml"> +<!ENTITY open-hatch + PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN" + "http://www.textuality.com/boilerplate/OpenHatch.xml"> +<!ENTITY hatch-pic + SYSTEM "../grafix/OpenHatch.gif" + NDATA gif >

+ + + + + +&parsed-entity; + +テキスト宣言 +

外部&parsed-entity;は，テキスト宣言で始まってもよい。 + +テキスト宣言 + +TextDecl +&xmlpio; +VersionInfo? +EncodingDecl +S? &pic; + + + + + +

テキスト宣言は，そのままの形で現れなければならず，&parsed-entity;への参照を経由してはならないことに注意する。

外部&parsed-entity;において，テキスト宣言は，先頭以外のいかなる位置にも出現しない。

+ + +&well-formed;の&parsed-entity; +

ラベルdocumentをもつ生成規則に&match;すれば，文書実体は，&well-formed;とする。ラベルExtParsedEntをもつ生成規則に&match;すれば，外部の一般&parsed-entity;は，&well-formed;とする。ラベルExtPEをもつ生成規則に&match;すれば，外部パラメタ実体は，&well-formed;とする。 + + +&well-formed;の&parsed-entity; +ExtParsedEnt +TextDecl? +content + +ExtPE +TextDecl? +extSubset + + +&replacement-text;が，ラベルcontentをもつ生成規則に&match;すれば，内部の一般&parsed-entity;は，&well-formed;とする。DTDを最後まで読み込まないと，確実にこれを判定できないことに注意。すべての内部のパラメタ実体は，定義によって&well-formed;とする。 +

実体が&well-formed;な結果として，XML文書の論理的及び物理的構造は，正しく入れ子となる。開始タグ，終了タグ，空要素タグ，要素，コメント，処理命令，文字参照及び実体参照が，一つの実体で開始し，別の実体で終了することはない。

+ + +実体における文字符号化 + +

XML文書内の外部&parsed-entity;は，各々，別の文字符号化方式を用いてもよい。すべてのXML&processor;は，UTF-8で符号化した実体，UTF-16で符号化した実体を処理できなければならない。 + +

UTF-16で符号化した実体は，ISO/IEC 10646の付録E及びUnicodeの付録Bで規定する&byte-order-mark;(ZERO WIDTH NO-BREAK SPACE文字，#xFEFF)で始まらなければならない。これは，符号化の標識であって，XML文書の&markup;の一部でも，文字データの一部でもない。XML&processor;は，UTF-8で符号化した文書とUTF-16で符号化した文書との区別を行うために，この文字を使用可能でなければならない。

XML&processor;は，UTF-8及びUTF-16で符号化した実体だけを読むことを必須とするが，他の符号化を世界では用いており，それらの符号化を用いる実体をXML&processor;が処理できることが望ましい。UTF-8又はUTF-16以外の符号化方式を用いて格納する&parsed-entity;は，符号化宣言を含むテキスト宣言で始めなければならない。 + +符号化宣言 +EncodingDecl +S +'encoding' Eq +'"' EncName '"' | "'" +EncName "'" + + +EncName +[A-Za-z] ([A-Za-z0-9._] | '-')* +ラテン文字だけを含む符号化名 + + +文書実体では，符号化宣言は，XML宣言の一部とする。EncNameは，使用する符号化方式の名前とする。 +

+ +

符号化宣言では，値UTF-8，UTF-16，ISO-10646-UCS-2及びISO-10646-UCS-4は，Unicode及びISO/IEC 10646の各種符号化のために用いる。値ISO-8859-1からISO-8859-9までは，ISO 8859の対応するパートのために用いる。値ISO-2022-JP，Shift_JIS及びEUC-JPは，JIS X-0208-1997の各種符号化のために用いる。XML&processor;は，それ以外の符号化方式を認識してもよい。Internet Assigned Numbers Authority (IANA)に，(charsetsとして)登録された文字符号化方式については，これら以外についても，登録された名前で参照することが望ましい。これらの登録された名前は，大文字・小文字の区別をせずに定義されているので，これらに対する比較を試みる&processor;は，大文字・小文字の区別をしない方法をとるのが望ましいことに注意する。

XML処理系に渡された実体が，符号化宣言を含むにもかかわらず，宣言で示したもの以外の方式で符号化されていたり，符号化宣言が，外部実体の最初以外の位置に出現すれば，&error;とする。 +

&byte-order-mark;でも符号化宣言でも始まらない実体は，UTF-8符号化でなければならない。

+ +

+処理できない符号化をもった実体をXML&processor;が発見したときは，&application;にその事実を通知し，&fatal-error;として，処理を終了しなければならない。 + +

符号化宣言の例を，次に示す。 +<?xml encoding='UTF-8'?> +<?xml encoding='EUC-JP'?>

+ + + +XML&processor;による実体及び参照の扱い +

次の表は，文字参照，実体参照及び&unparsed-entity;の呼出しが現れる文脈及び各々の場合におけるXML&processor;に要求する振舞いを要約する。一番左の列のラベルは，認識の文脈を示す。 + +内容における参照 +

要素の開始タグ及び終了タグの間の任意の場所での参照。非終端記号contentに対応する。

+ + +属性値における参照 +

開始タグの属性の値，又は属性宣言における&default-value;のいずれかでの参照。非終端記号AttValueに対応する。

+ +属性値として出現 +

参照ではなく，Nameとして出現。ENTITY型として宣言した属性の値，又はENTITIES型として宣言した属性の値における&space;で区切る&token;の一つとして出現する。

+ +実体値における参照 +

実体の宣言における，パラメタ又は内部実体の&literal;実体値内の参照。非終端記号EntityValueに対応する。

+DTDにおける参照 +

DTDの内部⊂又は外部⊂での参照。ただし，EntityValue又はAttValueの外側とする。

+ +

+ + + + + +実体の型 +文字 + + +パラメタ +内部&newline;一般 +外部&newline;&parsed-entity;&newline;一般 +&unparsed-entity; + + + +内容での&newline;参照 +認識&newline;しない +取込み +検証のために取込み +禁止 +取込み + + +属性値での&newline;参照 +認識&newline;しない +取込み +禁止 +禁止 +取込み + + +属性値として&newline;出現 +認識&newline;しない +禁止 +禁止 +通知 +認識&newline;しない + + +実体値での&newline;参照 +取込み +&bypass; +&bypass; +禁止 +取込み + + +DTDでの&newline;参照 +PEとして&newline;取込み +禁止 +禁止 +禁止 +禁止 + + + + +“認識しない” +

DTDの外では，%文字は，いかなる特定の意味も，もたない。したがって，DTDではパラメタ実体参照として認識するものであっても，content内では&markup;としては認識しない。同様に，適切に宣言した属性の値の中に現れる場合を除き，&unparsed-entity;の名前は，認識しない。 +

+ + +“取込み” +

実体は，その&replacement-text;を取り出し，処理すると，参照自体の代わりに，参照があった位置で，文書の一部として含まれるかのように取り込まれる。&replacement-text;は，文字データ及び(パラメタ実体を除く。)&markup;のいずれを含んでもよく，これらは，通常の方法で認識されなければならない。ただし，&markup;の区切り子を&escape;するために用いる実体(&magicents;)の&replacement-text;は，常にデータとして扱う(&string;"AT&T;"は，"AT&T;"に展開され，残されたアンパサンドは，実体参照の区切り子としては認識しない。)。文字参照は，示した文字を参照自体の代わりに処理するとき，取り込まれる。 +

+ + +“検証のために取込み” +

文書の&validity;を検証するには，XML&processor;が&parsed-entity;への参照を認識したとき，その&replacement-text;を取り込まなければならない。実体が外部実体であって，XML文書の&validity;を検証しなければ，実体の&replacement-text;を取り込んでもよいが，そうしなくともよい。

この取決めは，SGML及びXMLの実体の機構が提供する自動取込み機能が，文書作成時のモジュール化を主な目的として設計されており，その他の&application;(特に，文書のブラウズ)には，必ずしも適切ではない，という認識による。例えば，ブラウザは外部&parsed-entity;への参照を見つけると，その実体が存在するという表示だけを行い，表示を要求されたときにだけ，内容を取り出すかもしれない。 +

+ + +“禁止” +

次は禁止されており，&fatal-error;とする。 + +

a) &unparsed-entity;への参照の出現。 +

b) DTDのEntityValue又はAttValue以外の部分における，文字参照又は一般実体への参照の出現。

c) 属性値内の外部実体への参照。

+ + +

+ + +“通知” +

&unparsed-entity;の名前が，ENTITY又はENTITIESの属性の値において&token;として現れたとき，&processor;は，&application;に対して，関連付けられた記法名，記法に対するシステム&identifier;及び(存在すれば)公開&identifier;を通知しなければならない。

+ + +“&bypass;” +

一般実体参照が，実体宣言におけるEntityValue内に現れるとき，それは無視され，そのまま残る。

+ + +“PEとして取込み” +

外部&parsed-entity;の場合と同様に，パラメタ実体は，&validity;を検証するときだけ取り込まれる必要がある。パラメタ実体参照をDTD内に認識して取り込むとき，その&replacement-text;は，その前後に一つの&space-character;(#x20)の付加によって引き伸ばされる。この意図は，パラメタ実体の&replacement-text;が，DTD内のいくつかの文法的&token;を完全に含むと，制約することにある。 +

+ + + + +内部実体&replacement-text;の構築 +

内部実体の取扱いの規定で，実体値を二つの形式に区別することは役に立つ。&literal;実体値は，実体宣言内に実際に存在する，引用符で囲む&string;とする。これは，非終端記号EntityValueに&match;する。&replacement-text;は，文字参照及び¶meter;実体参照の置換え後における，実体の内容とする。

+ +

内部実体宣言内で与える&literal;実体値(EntityValue)は，文字参照，¶meter;実体参照及び一般実体参照を含んでよい。これらの参照は，&literal;実体値内に完全に含まれていなければならない。展開する実際の&replacement-text;(先に示したもの)は，参照する¶meter;実体の&replacement-text;を含まなければならず，&literal;実体値内での文字参照の代わりに参照した文字を含まなければならない。しかし，一般実体参照は，そのまま残し, 展開してはならない。 + +例えば，次の宣言を与えたとする。 + + + +]]> +実体の&replacement-text;"book"は，次のとおりとなる。 +La Peste: Albert Camus, +© 1947 Éditions Gallimard. &rights; +参照"&book;"が，文書の内容又は属性値内に出現していれば，一般実体参照"&rights;"は，展開されている。

これらの単純な規則は，複合相互作用をもつ。 + +難しい例についての詳細は，実体参照の展開の付録を参照のこと。 +

+ + + + + +定義済み実体 +

+実体参照及び文字参照のいずれも，&left-angle-bracket;，アンバサンド及び他の区切り子を&escape;するために使用できる。いくつかの一般実体（&magicents;）を，この目的のために指定する。数値による文字参照も，同様の目的のために使用できる。文字参照は，認識されると直ちに展開され，文字データとして扱われるので，数値による文字参照"<"及び"&"は，文字データ内に出現する<及び&を&escape;するために使用できる。

すべてのXML&processor;は，宣言されているかどうかに関係なく，これらの実体を認識しなくてはならない。相互運用性のため，&valid;なXML文書は，これらの実体を使用する前に，他の実体と同様に，宣言することが望ましい。実体を宣言する場合は，&replacement-text;を&escape;する一文字とする内部実体として，次のとおりに宣言しなければならない。 + + + + + +]]> +"lt"及び"amp"宣言内の"<"及び"&"文字は，実体の置換テキストが，&well-formed;となるように二重に&escape;されることに注意。 +

+ + + + +記法宣言 + + +

+ +記法は，&unparsed-entity;の形式を&identify;名前か，又は処理命令の対象とする&application;を&identify;名前とする。

+記法宣言は，記法の名前及び外部&identifier;を提供する。この名前は，実体及び属性リスト宣言並びに属性指定に用いる。外部&identifier;は，与えられた記法のデータを処理できるヘルパ&application;を，XML&processor;又はクライアントアプリケーションが探すために，利用できる。 + +記法宣言 +NotationDecl +'<!NOTATION' S Name +S +(ExternalID | +PublicID) +S? '>' +PublicID +'PUBLIC' S +PubidLiteral + + +

宣言し，属性値，属性定義又は実体宣言で参照するすべての記法について，XML&processor;は，記法の名前及び外部&identifier;を&application;に提供しなければならない。さらに，外部&identifier;を，システム&identifier;，ファイル名又はその他の情報に展開してもよく，これらを用いて，&application;は，その記法のデータを処理する&processor;を起動する。(しかし，XML&processor;又は&application;が動作するシステムでは利用できない記法を，XML文書が宣言し参照しても，これは，&error;とはしない。）

+ + + + +文書実体 + +

文書実体は，実体の形成する木構造の&root;であって，XML&processor;が，処理を開始する地点とする。この&TR-or-Rec;は，XML&processor;が，文書実体の存在する場所をどのように見つけるかは，規定しない。他の実体と異なり，文書実体は名前をもたず，いかなる識別もなしに&processor;への入力&stream;に出現してもよい。

+ + + + + + +適合性 + +

適合するXML&processor;は，&validating;もの及び&non-validating;ものの，二つに分類される。

&validating;システム及び&non-validating;システムは，この&TR-or-Rec;が規定する&well-formed;制約への違反を報告しなければならない。

&validating;&processor;は，DTD内の宣言によって示された，制約への違反を報告しなければならない。さらに，この&TR-or-Rec;が規定する&validity;制約への違反を，すべて報告しなければならない。 + +

+ + + +記法 + +

XMLの形式的な文法は，簡単な拡張Backus-Naur Form(EBNF)記法によって与える。文法の各規則は，次の形式で，記号を一つ定義する。 +symbol ::= expression

記号は，正規表現で定義するときは大文字で始め，そうでなければ，小文字で始める。&string;&literal;は，引用符で囲む。 + +

+ +

規則の右側の式内では，一つ又は複数の文字からなる&string;と&match;するために，次の式を使用する。 + + +#xN +

ここで，Nは16進の整数とする。ISO/IEC 10646の文字であって，正規形(UCS-4)の&code-value;を符号なし2進数として解釈したとき，指定した値と等しいものと&match;する。#xN形式の先頭にゼロがいくつか現れるかは，意味をもたない。&code-value;における先頭のゼロの数は，文字の符号化によって決定されるので，XMLにとっては意味がない。 +

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

指定した範囲の値(両端の値を含む。）をもつ任意の文字と&match;する。

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

指定した範囲外の値をもつ任意の文字と&match;する。

+ + +[^abc], [^#xN#xN#xN] +

指定した文字以外の値をもつ任意の文字と&match;する。

+ + +"string" +

&double-quote;で囲む&string;&literal;と&match;している&string;&literal;と&match;する。

+ + +'string' +

&single-quote;で囲む&string;&literal;と&match;している&string;&literal;と&match;する。

+ + +これらの記号は，次の形式の組合せで使用する。ここで，A及びBは，単純な式とする。 + + +(expression) +

expressionは，一つのまとまりとして扱い，ここに示す組合せで使ってもよい。

+ + +A? +

A又は何もなしと&match;する(オプションのA)。

+ + +A B +

Aの次にBが出現するものと&match;する。 +

+ + +A | B +

A又はB，ただし，両方ではない，と&match;する。 +

+ + +A - B +

Aと&match;するが，Bとは&match;しない，任意の&string;と&match;する。

+ + +A+ +

Aの1回以上の繰返しと&match;する。

+ + +A* +

Aの0回以上の繰返しと&match;する。

+ + + +生成規則内で使用する他の記法を，次に示す。 + + +/* ... */ +

コメント。

+ + +[ wfc: ... ] +

&well-formed;制約。生成規則に付与した，&well-formed;の文書に関する制約を，名前によって&identify;。

+ + +[ vc: ... ] +

&validity;制約。生成規則に付与した，&valid;な文書に関する制約を，名前によって&identify;。 +

+ + +

+ + + + + + + + +参考文献 + +&normative;参考文献 + + + + + +IETF (Internet Engineering Task Force). +RFC 1766: Tags for the Identification of Languages, +ed. H. Alvestrand. +1995. + + + +(International Organization for Standardization). +ISO 8879:1988 (E). +Code for the representation of names of languages. +[Geneva]: International Organization for +Standardization, 1988. + + +(International Organization for Standardization). +ISO 3166-1:1997 (E). +Codes for the representation of names of countries and their subdivisions +— Part 1: Country codes +[Geneva]: International Organization for +Standardization, 1997. + +ISO +(International Organization for Standardization). +ISO/IEC 10646-1993 (E). Information technology — Universal +Multiple-Octet Coded Character Set (UCS) — Part 1: +Architecture and Basic Multilingual Plane. +[Geneva]: International Organization for +Standardization, 1993 (plus amendments AM 1 through AM 7). + + +The Unicode Consortium. +The Unicode Standard, Version 2.0. +Reading, Mass.: Addison-Wesley Developers Press, 1996. + + + + + +他の参考文献 + + + +Aho, Alfred V., +Ravi Sethi, and Jeffrey D. Ullman. +Compilers: Principles, Techniques, and Tools. +Reading: Addison-Wesley, 1986, rpt. corr. 1988. + + +Berners-Lee, T., R. Fielding, and L. Masinter. +Uniform Resource Identifiers (URI): Generic Syntax and +Semantics. +1997. +(Work in progress; see updates to RFC1738.) + +Brüggemann-Klein, Anne. +Regular Expressions into Finite Automata. +Extended abstract in I. Simon, Hrsg., LATIN 1992, +S. 97-98. Springer-Verlag, Berlin 1992. +Full Version in Theoretical Computer Science 120: 197-213, 1993. + + + +Brüggemann-Klein, Anne, +and Derick Wood. +Deterministic Regular Languages. +Universität Freiburg, Institut für Informatik, +Bericht 38, Oktober 1991. + + + +IETF (Internet Engineering Task Force). +RFC 1738: Uniform Resource Locators (URL), +ed. T. Berners-Lee, L. Masinter, M. McCahill. +1994. + + + +IETF (Internet Engineering Task Force). +RFC 1808: Relative Uniform Resource Locators, +ed. R. Fielding. +1995. + + + +IETF (Internet Engineering Task Force). +RFC 2141: URN Syntax, +ed. R. Moats. +1997. + + +ISO +(International Organization for Standardization). +ISO/IEC 8879-1986 (E). Information processing — Text and Office +Systems — Standard Generalized Markup Language (SGML). First +edition — 1986-10-15. [Geneva]: International Organization for +Standardization, 1986. + + + +ISO +(International Organization for Standardization). +ISO/IEC 10744-1992 (E). Information technology — +Hypermedia/Time-based Structuring Language (HyTime). + +[Geneva]: International Organization for +Standardization, 1992. +Extended Facilities Annexe. +[Geneva]: International Organization for +Standardization, 1996. + + + + + + + + +文字クラス + +

ここで定義する文字クラスは，Unicode文字データベースから，次のとおりに得ることができる。 + + +

a) 名前開始文字は，Ll, Lu, Lo, Lt, Nlカテゴリ内の一つでなければならない。

+ + +

b) 名前開始文字以外の名前文字は，Mc, Me, Mn, Lm, Ndカテゴリ内の一つでなければならない。

+ + +

c) &compatibility-area;にある文字(文字符号で#xF900より大きく#xFFFEより小さい文字)は，XMLにおける名前としては，許されない。

+ + +

d) &font-decomposition;か&compatibility-decomposition;をもつ文字(つまり，データベース内の５番目のフィールドに"compatibility formatting tag"があるもの。これは，５番目のフィールドが，"<"で始まることによってマーク付けされる。)は，許されない。

+ + +

e) 次の文字は，名前開始文字として扱う。これは，&property-file;が，これらの文字をアルファベットに類似すると見なすことによる。それらは +[#x02BB-#x02C1], #x0559, #x06E5, #x06E6とする。

+ + +

f) 文字符号が#x20DD-#x20E0の文字は，(Unicode の5.14にしたがって)除外する。

+ + +

g) 文字符号が#x00B7の文字は，&property-list;にしたがって，&extender;(extender)に分類する。

+ + +

h) 文字#x0387は，これに相当する正規形が#x00B7なので，名前文字に追加する。

+ + +

i) 文字':'及び'_'は，名前開始文字として許す。

+ + +

j) 文字'-'及び'.'は，名前文字として許す。

+ + +

+ + +XML及びSGML + +

XMLは，SGMLの⊂として設計されている。すなわち，すべての&valid;なXML文書は，規格に適合するSGML文書にもなる。SGMLが文書に課す制限以外に，XMLがいかなる制限を課すかに関する詳細は，別の規程を参照のこと。この規程は，XMLの制約条件を示すSGML宣言を含み，これは，SGML&parser;に使用できる。 +

+ + +実体参照及び文字参照の展開 +

この付録は，実体参照及び文字参照を認識し，展開する，一連の流れを，例に使って示す。

+DTDが，次の宣言を含む場合を考える。 +An ampersand (&) may be escaped +numerically (&#38;) or with a general entity +(&).

" > +]]> +XML&processor;は，実体の宣言を構文解析した時点で文字参照を認識し，これを解決する。実体"example"の値として，次の&string;を保存する。 +An ampersand (&) may be escaped +numerically (&) or with a general entity +(&).

+]]> +文書内で"&example;"を参照すると，このテキストは，再び構文解析される。このとき，要素"p"の開始タグ及び終了タグを認識し，三つの参照を認識し展開する。その結果，要素"p"は，次の内容をもつ(すべてデータとし，区切り子又は&markup;は存在しない。)。 + +

規則及びその効果をより詳細に示すため，さらに複雑な例を示す。次の例で，行番号は，参照の便宜のためだけに付ける。 + +2 +4 +5 ' > +6 %xx; +7 ]> +8 This sample shows a &tricky; method. +]]> +これを処理すると，次のとおりとなる。 + +

a) 4行目で，37番目の文字への参照を直ちに展開し，パラメタ実体"xx"を，シンボルテーブルに"%zz;"という値とともに保存する。&replacement-text;を再び走査することはないので，パラメタ実体"zz"への参照は認識しない("zz"は，まだ宣言されていないので，走査されれば，&error;となる。)。

b) 5行目で，文字参照"<"を直ちに展開し，パラメタ実体"zz"を"<!ENTITY tricky "error-prone" >"という&replacement-text;とともに保存する。これは，&well-formed;の実体宣言とする。

c) 6行目で，"xx"への参照を認識し，"xx"の&replacement-text;(すなわち，"%zz;")を構文解析する。"zz"への参照を続いて認識し，&replacement-text;("<!ENTITY tricky "error-prone" >")を構文解析する。一般実体"tricky"は，この時点では，宣言されており，その&replacement-text;は，"error-prone"とする。

d) 8行目で，一般実体"tricky"への参照を認識し，展開する。要素"test"の完全な内容は，次の(内容をそれ自体表現する。)&string;となる。つまり，This sample shows a error-prone method. +

+ +

+ + +決定的内容モデル +

互換性のため，要素宣言における内容モデルは，決定的とする必要がある。 +

+ +

SGMLは，決定的内容モデル(SGMLでは，非あいまいと呼ぶ。)を要求する。SGMLシステムを用いて作成したXML&processor;は，非決定的内容モデルを&error;としてもよい。

例えば，内容モデル((b, c) | (b, d))は非決定的となる。これは，最初にbを与えたとき，モデル内のいずれのbと&match;するのが望ましいか，その次の要素を先読みすることなしには，&parser;は知ることができないことによる。この場合は，bへの二つの参照は，一つの参照にまとめることができ，モデルは，(b, (c | d))となる。これで，最初のbが，内容モデル内の一つの名前とだけ&match;することは明らかとなる。&parser;は，先読みして，次に来るものを知る必要がない。cもdも，受理される。

形式的に示す。Aho, Sethi, and Ullman の3.9のアルゴリズム3.5の標準的なアルゴリズムを用いて，内容モデルから有限オートマトンを構成することができる。この種の多くのアルゴリズムでは，正規表現における各々の位置(つまり，正規表現の構文木における各々の末端ノード)に対して，follow set(次にどの位置に移動可能かを表すもの)を構成する。ある位置に対するfollow setにおいて，複数の位置が同じ要素型名でラベル付けされていれば，その内容モデルは&error;となり，&error;を返す場合もある。 +

すべての非決定的内容モデルを等価な決定的内容モデルに変換することはできないが，多くの非決定的内容モデルを変換するアルゴリズムが存在する。Brüggemann-Klein 1991 を参照のこと。

+ + +文字符号化の自動検出 +

+XMLの符号化宣言は，各実体の内部ラベルとして機能し，どの文字符号化を使用するかを示す。しかし，XML&processor;は，内部ラベルを読む前に，どの文字符号化を使用するかを知る必要があり，これが，内部ラベルが示そうとすることになる。一般的には，これは，絶望的な状態となる。しかし，XMLにおいては，完全には絶望的ではない。これは，XMLが，次の二つの点で一般的な場合に対する制限を加えることによる。一つの制限は，どの実装も有限個の文字符号化だけのサポートを想定することとする。他の一つの制限は，各実体で使用する文字符号化を自動検出可能とする，XMLの符号化宣言の位置及び内容に関する制限とする。多くの場合に，XMLのデータストリームに加え，他の情報が利用できる。ここでは，XMLの実体が&processor;に渡されるとき，(外部)情報を伴うかどうかによって，二つの場合に分ける。まず最初の場合を示す。

+UTF-8形式又はUTF-16形式ではないXML実体は，最初の文字を‘<?xml'とするXML符号化宣言で始まらなければならないので，どの適合した&processor;も，入力にある2オクテット又は4オクテットを調べれば，次のどの場合があてはまるかを検出できる。このリストを読む際には，UCS-4の'<'が"#x0000003C"，'?'が"#x0000003F"，及びUTF-16のデータ&stream;の必要とする&byte-order-mark;が"#xFEFF"ということを知っておくと役立つかもしれない。

+ + +

a) 00 00 00 3C: UCS-4, big-endian マシン (1234順)

+ + +

b) 3C 00 00 00: UCS-4, little-endian マシン (4321順)

+ + +

c) 00 00 3C 00: UCS-4, 普通ではないオクテット順 (2143)

+ + +

d) 00 3C 00 00: UCS-4, 普通ではないオクテット順 (3412)

+ + +

e) FE FF: UTF-16, big-endian

+ + +

f) FF FE: UTF-16, little-endian

+ + +

g) 00 3C 00 3F: UTF-16, big-endian, &byte-order-mark;なし(したがって，厳密にいえば，&error;とする。)。

+ + +

h) 3C 00 3F 00: UTF-16, little-endian, &byte-order-mark;なし(したがって，厳密にいえば，&error;とする。)。

+ + +

i) 3C 3F 78 6D: UTF-8, ISO 646, ASCII, ISO 8859の各パート，Shift-JIS，EUC，並びに任意の他の7ビット，8ビット又は混在幅の符号化であって，ASCII文字を通常の位置，幅及び値とすることを保証するもの。これらのどれに対応するかを検出するためには，実際の符号化宣言を読み込まなければならない。しかし，これらすべての符号化は，ASCII文字に対して同じビットパターンを使用するので，符号化宣言自体は，正確に読込み可能とする。 +

+ + +

j) 4C 6F A7 94: EBCDIC (又はその変種。どのコードページを使用するかを知るためには，符号化宣言全体を読み込まれなければならない。)

+ + +

k) その他: 符号化宣言なしのUTF-8。そうでないときには，データ&stream;が壊れているか，断片的になっているか，何らかの形式にしたがって埋め込まれている。

+ + +

+この程度の自動判別でも，XMLの符号化宣言を読み込み，文字符号化の&identifier;を解析するには十分とする。&identifier;の解析は，類似する各々の符号化の一つ一つを区別するために必要とする(例えば，UTF-8及び8859を区別するため，8859の各パートを区別するため，使用している特定のEBCDICコードページを区別するため，など。)。 +

+符号化宣言の内容をASCII文字に限定しているので，どの分類の符号化を使用するかを検出すれば，&processor;は，符号化宣言全体を正確に読み込むことができる。現実問題として，広く使用されている文字符号化は，上の分類のいずれかにあてはまるので，オペレーティングシステム又は伝送プロトコルが与える外部情報を信頼不可能なときでさえも，内部ラベルで文字符号化をかなり正確に示すことが，XML符号化宣言によって可能となる。 +

+&processor;が使用する文字符号化を検出しさえすれば，それぞれの場合に対して別個の入力ルーチンを呼び出す，又は入力する各文字に対し適切な変換関数を呼び出すことによって，適切な動作が可能となる。

+自分自体にラベル付けをするいかなるシステムでも同様だが，ソフトウェアが，符号化宣言を更新せずに実体の文字集合又は符号化を変えたならば，XMLの符号化宣言は，機能しない。文字符号化ルーチンの実装者は，実体のラベル付けに使用する内部及び外部の情報の正確さの保証に注意するのが望ましい。 +

２番目の場合は，XMLの実体の他に，符号化情報が存在するときであって，いくつかのファイルシステム及びネットワークプロトコルでは，その符号化情報が存在する。複数の情報が利用できるとき，それらの相対的な優先度及びそれらが矛盾したときの望ましい処理方法は，XMLの配送に使用する，より高水準のプロトコルの一部として規程するのがよい。例えば，内部ラベル及び外部&header;に存在するMIME形式のラベルの相対的な優先度に対する規則は，text/xml及びapplication/xmlのMIME型を定義するRFC文書の一部となる方がよい。しかし，相互運用性のために，次の規則に従うことが望ましい。 + +

a) XMLの実体がファイルに存在すれば，&byte-order-mark;及び符号化宣言PIは，(存在すれば)文字符号化を決定するために使用する。他のすべての&hueristics;及び情報は，&error;回復のためだけに用いる。 +

b) XMLの実体をMIME型text/xmlで配送するときは，このMIME型のもつcharsetパラメタが文字符号化方法を決定する。他のすべての&hueristics;及び情報は，&error;回復のためだけに用いる。 +

c) XMLの実体を MIME型application/xmlで配送するときは，&byte-order-mark;及び符号化宣言PIを(存在すれば)文字符号化の決定のために使用する。他のすべての&hueristics;及び情報は&error;回復のためだけに用いる。 +

+ +これらの規則は，プロトコルについての資料がないときにだけ用いる。特に，MIME型text/xml及びapplication/xmlを定義したら，これらを規定するRFCに存在する規定が，これらの規則に取って代わる。 +

+ + + + +&informative;W3C XML ワーキンググループ + +

この&TR-or-Rec;は，W3C XML ワーキンググループ(WG)が準備し，公開を承認した。WGがこの&TR-or-Rec;を承認するということは，WGのすべての委員が承認投票を行ったということを必ずしも意味しない。XML WGの現在の委員及び以前の委員を次に示す。

+ + + +Jon Bosak, SunChair +James ClarkTechnical Lead +Tim Bray, Textuality and NetscapeXML Co-editor +Jean Paoli, MicrosoftXML Co-editor +C. M. Sperberg-McQueen, U. of Ill.XML Co-editor +Dan Connolly, W3C +Steve DeRose, INSO +Dave Hollander, HP +Eliot Kimber, Highland +Eve Maler, ArborText +Tom Magliery, NCSA +Murray Maloney, Muzmo and Grif +村田　真，富士ゼロックス情報システム(株) +Joel Nava, Adobe +Peter Sharpe, SoftQuad +John Tigue, DataChannel + + + + + + + +