第34回　XML勧告を理解するために必要な外部の文書　Page 2

川俣 晶
株式会社ピーデー
2005/6/3

■附属書A（規定）文献（A References）

　さて、Appendicesの「A References（附属書A）」である。ここには、さまざまな文書、文献が記されている。内容に入る前に、1つだけ用語について確認しておこう。XML 1.0勧告のAppendicesには、「Non-Normative」という言葉が添えられたものと、そうではないものがある。A Referencesは添えられていない。JIS X 4159では、規定という言葉が添えられたものと、参考という言葉が添えられたものがある。原文でNon-Normativeであったものが、参考とされていて、そうではないものが規定とされている。つまり、「A References」に対応する「附属書A（規定）文献」は、見てのとおり規定という言葉が添えられている。

　これらの言葉はいったい何を示しているのだろうか？

　まず、標準を定める技術仕様書は、基本的に仕様を規定する文章によって構成されることを確認しておこう。その技術仕様に適合していると主張するには、文章に書かれたとおりの条件を満たすようにソフトウェアを開発する、あるいは利用する必要がある。このような文章を「規定」あるいは「Normative」と呼ぶ。しかし、仕様書に含まれる文章のすべてが「規定」としての機能を与えられているわけではない。実際には、規定だけから構成される仕様書は分かりにくいことが多く、規定を分かりやすくするための説明文を添えることが多い。このような文章は、英語では「Non-Normative」あるいは「Informative」などと呼ばれ、日本語では「参考」などと呼ばれる。

　つまり、「Non-Normative」あるいは「参考」と記された部分は、仕様の規定ではなく、分かりやすくするために添えられた文章にすぎないということである。それに対して、「規定」とされた文章は、もちろん仕様を規定する一部である。問題は、何も書かれていないケースだが、これは暗黙的に仕様書の文章は規定を行うためのものであるという原則から、「規定」（Normative）と見なせることが分かる。

　つまり、英文において何も記されていない「A References」は「規定」と見なせるし、「規定」と明記された「附属書A（規定）文献」はもちろん「規定」と見なすことができる。つまり、これから読んでいく「A References」は、原文でも、JIS規格でも、「規定」として扱われるということである。

■引用規定（A.1 Normative References）

　さて、ここからは「A.1 Normative References（A.1 引用規定）」である。これは、見出しそのものに「Normative」（規定）という文字が見えることから分かるとおり、間違いなく規定を構成する一部となる部分である。

　ここで参照されている文書を順に見ていこう。

IANA-CHARSETS

(Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. (See http://www.iana.org/assignments/character-sets.)

　 インターネット上のさまざまな固有の番号や名前を登録する組織として、Internet Assigned Numbers Authority、略してIANAが存在する。IANAは、文字符号化スキームの名前の登録を受け付けており、そのリストがCHARACTER SETSとして公開されている。これは、それを示している。

　これについては、第27回「実体における文字符号化の問題を整理する」の「4.3.3 Character Encoding in Entities（4.3.3 実体における文字符号化）」の中で解説を行っているので、ここでは詳細な説明は割愛する。

　なお、この文書は、文字符号化スキームの登録申請が受理されるごとに内容は常に変化し得るものである。その点で、出版されると内容が変化することはない印刷物とは、性格が異なることに注意が必要である。ちなみに、インターネット上の電子文書であっても、RFCなどは発行されると基本的に内容は変化しないものである。それとは性質が異なるということである。

IETF RFC 2119

IETF (Internet Engineering Task Force). RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Scott Bradner, 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)

　これは、「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」という用語の意味を厳密に規定する文書である。タイトルに「Key words for use in RFCs to Indicate Requirement Levels」と書いてあるとおり、これはRFCで使用される要件のレベルについて示す言葉である。要件のレベルとは、必須であるとか、任意選択であるとか、そのような要求の度合いについての言葉である。ちなみに「RFCで」というタイトルではあるが、XML 1.0勧告は、W3Cが勧告する文書であり、IETFが発行するRFCではない。しかし、内容的に有益であり、RFC以外で使用することは何ら問題はないといえる。むしろ、用語の意味を統一する意味で、たとえRFCではなくても、この文書を参照する価値があるといえるだろう。

　なお、JIS X 4159にはこの文書についての言及が含まれていない。これは、本文中にこれらの単語が使用されていないことによるものだろう。当然、日本語の文章中に「MUST」のような英単語は出現しない。

IETF RFC 2396

IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 1998. (See http://www.ietf.org/rfc/rfc2396.txt.)

　これはURI（Uniform Resource Identifiers）の一般的な構文を規定する文書である。XMLでは、リソースの所在を指定するためなどにURIを使用している。

　この文書で規定されているのは、例えばスキームの後にコロン記号（:）を書く、というような構文や使用できる文字についてなどである。例えば、http://www.atmarkit.co.jp/というURIで、httpというスキーム名の後にコロン記号（:）を書かねばならない根拠を、この文書が与えている。また、http://www.aland.to/~lintrank/table.htmlというURIが誤りであり、チルダ記号（~）を「%7e」と書かねばならない根拠もここにある。

IETF RFC 2732

IETF (Internet Engineering Task Force). RFC 2732: Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. 1999. (See http://www.ietf.org/rfc/rfc2732.txt.)

　これは、IPv6のIPアドレスの書式について規定する文書である。XMLとIPv6は直接関係がなく、ここにこのような文書が出てくるのは少々奇異に思える。しかし、それはこの文書が参照されている文脈を見れば理解できると思う。この文書は、「4.2.2 External Entities（4.2.2 外部実体）」の中の、以下のような文章で参照されている。

　（as defined in [IETF RFC 2396], updated by [IETF RFC 2732]）

　つまり、ここで引用したかったのは、あくまでURIの一般的な構文を規定する[IETF RFC 2396]であって、それをIPv6対応のためにアップデートする文書としてすでにこの文書が存在していたため、それを併記したということである。

　しかし、積極的に、IPv6関係の文書も参照されているのだから、XMLはIPv6に対応していると読んでも問題はないだろう。

IETF RFC 3066

IETF (Internet Engineering Task Force). RFC 3066: Tags for the Identification of Languages, ed. H. Alvestrand. 2001. (See http://www.ietf.org/rfc/rfc3066.txt.)

　言語（日本語や英語）を識別するコードを規定する文書である。xml:lang属性の値として使用するものである。本連載の第12回「XMLにおける空白、行末、言語識別」ですでに詳しく解説済みなので、それを参照願いたい。

ISO/IEC 10646

ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane and ISO/IEC 10646-2:2001. Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 2: Supplementary Planes, as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts. [Geneva]: International Organization for Standardization. (See http://www.iso.ch/ for the latest version.)

ISO/IEC 10646:2000

ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 2000.

　ここは少々込み入っている。さらにJIS X 4159との関係も込み入っている。二重に込み入っているため、分けて読んでみよう。

　まず原文をそのまま見ていこう。ここには、2種類の参考文献が示されている。1つは「ISO/IEC 10646」であり、もう1つは「ISO/IEC 10646:2000」である。その実体はというと、「ISO/IEC 10646」は「ISO/IEC 10646-1:2000」と「ISO/IEC 10646-2:2001」の双方であり、「ISO/IEC 10646:2000」は「ISO/IEC 10646-1:2000」のみである。そして、「ISO/IEC 10646」は「ISO/IEC 10646の新版による修正および置換、ならびに新しい部の追加による拡張を適用する。最新版については、http://www.iso.chを参照」という文章が付加されている。

　大ざっぱにいえば、「ISO/IEC 10646」という名前で示される文書は、将来発行される分を含めて「ISO/IEC 10646」と題されるすべての文書を含むことになる。もちろん、すでに発行されている2つのパートも含まれる。

　それに対して、「ISO/IEC 10646:2000」の方は、そのような広がりを一切否定し、ただ単に「ISO/IEC 10646-1」の2000年度版である「ISO/IEC 10646-1:2000」というたった1つの文書を示している。なぜ、このような参照が必要とされるかは、それが参照された文脈を見ると分かる。それは、第27回で読んだ「4.3.3 Character Encoding in Entities（4.3.3 実体における文字符号化）」にある。

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 2.4 of [Unicode], and section 2.7 of [Unicode3] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF).

UTF-16で符号化した実体は、[ISO/IEC 10646:2000]の附属書H,[Unicode]の2.4, [Unicode3]の2.7で規定するマーク（ZERO WIDTH NO-BREAK SPACE文字、#xFEFF）で始まらなければならず、UTF-8で符号化した実体は、マークで始まってもよい。

　ここで注目すべき点は「Annex H（附属書H）」である。Hとは付属書にAから順に与えられた文字である。ある内容を持った付属書に、常に「H」の文字が当てられるとは限らない。それ故に、ここではあくまで2000年版の「ISO/IEC 10646-1」の付属書Hだと明示する必要があったのだろうと推測する。

　さて、具体的に「ISO/IEC 10646-1:2000」と「ISO/IEC 10646-2:2001」がどう違うのかということを説明しておく。どちらも、全世界の文字を収録する国際的な文字集合を規定する国際規格の一部であることは間違いない。その中で、「ISO/IEC 10646-1:2000」の方は、主に16bitのコード範囲で表現できる文字に関する規定を含み、「ISO/IEC 10646-2:2001」はそれを超えるコード範囲（UTF-16で表現したときに、サロゲートペアを必要とする、つまり32bitを必要とする範囲）の文字に関する規定を含む。

　次はJIS規格との関連について説明しよう。JIS X 4159では、「ISO/IEC 10646-1:2000」の代わりに、「JIS X 0221-1:2001 国際符号化文字集合（UCS）−第1部 体系および基本多言語面」を参照している。これは、「ISO/IEC 10646-1:2000」と一致している国内規格である。しかし、「ISO/IEC 10646-2:2001」に相当する国内規格は存在していないため、これはそのまま表記されている。分かりにくいが、規格制定のタイミングによってこのような一貫性の欠如が生じることがあり、残念ながらやむを得ないといわざるを得ない。

Unicode

The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.

　これはUnicodeの旧規格であるUnicode 2.0を参照している。Unicode 2.0はXML 1.0勧告のFirst Editionが出たときの最新Unicodeである。古いバージョンを名指しにした参照が出現する理由は、おそらく「ISO/IEC 10646:2000」と同じだろう。これの解説で引用した文章中に、やはり「section 2.4 of [Unicode]」という表記が出てきている。別バージョンのUnicode規格書の「section 2.4」が同じ内容とは限らないので、バージョンを明示する価値がある。

Unicode3

The Unicode Consortium. The Unicode Standard, Version 3.2, defined by: The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) and the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).

　こちらは、バージョン3.2を明示したUnicodeである。とはいえ、これは少々まわりくどい記述になっている。というのは、独立した「Unicode 3.2」という文書は存在しないためである。「Unicode 3.0」という文書があり、それに対して、3.1との差分を示す「Unicode Standard Annex #27: Unicode 3.1」という文書と、それと3.2の差分を示す「Unicode Standard Annex #28: Unicode 3.2」という文書を付け加えることで、Unicode 3.2となる。

　余談だが、執筆時点でのUnicodeの最新バージョンは、Unicode 4.1.0となる。（次ページへ続く）

2/3

Index
やさしく読む「XML 1.0勧告」 第34回 XML勧告を理解するために必要な外部の文書
	Page 1 ・附属書の位置付け ・References（文献）を提示する意味
	Page 2 ・附属書A（規定）文献（A References） ・引用規定（A.1 Normative References）
	Page 3 ・参考文献（A.2 Other References）

連載　やさしく読む「XML 1.0勧告」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）