第19回　落とし穴が潜む属性値の正規化（補記）

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


■XML 1.1とXML 1.0 Third Editionについて

XML 1.1とXML 1.0 Third Editionの概要

　2004年2月4日に、Extensible Markup Language （XML） 1.1と、Extensible Markup Language（XML）1.0（Third Edition）がW3Cより勧告された。この連載で解説してきたExtensible Markup Language（XML）1.0（Second Edition）の後継と位置付けられる勧告が2つも同時に出てきたことになる。この連載では、従来どおりの路線を継承する方針に加えて、この2つのいずれかの勧告を対象とする方針の計3種類のどれかを選択する必要が生じた。

　この2つが勧告されることは予測されていたのだが、正誤表の反映にすぎないThird Editionよりも、新規勧告となるXML 1.1の方が後から出てくるだろうと考えていて、このような事態を予測していなかった。おそらく、同時に勧告されたという事態に、面食らっている読者も多いのではないかと思う。

　そこで、本連載の今後の解説は、Extensible Markup Language（XML） 1.0 （Third Edition）を対象として行う、とした。また、Second Editionを前提に行った過去の解説分についても、時期を見てThird Editionに対応させたいと思う。ただし、正誤表の一部はすでに本文中で反映済みであるため、そこはThird Editionに対応しているといってもよい。

　さて、念のために3つの方針のうち、これを選んだ理由について簡単に述べておく。

　まず、Second EditionではなくThird Editionとする方針を選ぶことができた理由について説明する。この連載では、Second Editionに対応するJIS規格であるJIS X 4159の存在を前提にしており、用語の日本語表記などもこれに従っている。このJIS規格そのものに、JIS X 4159:2004 追補1、拡張可能なマーク付け言語（XML） 追補1と呼ばれる文書が次年度に発行される見込みである。これは、Second Editionに対応するJIS X 4159に追加して補う文書であり、JIS X 4159をThird Edition相当の内容に改訂する意図を持ったものである。つまり、対応する日本語訳としてのJIS X 4159についてもThird Edition対応が行われ、そのための原案文書もすでにかなりの完成度として作成されている。それにより、この連載で今後Third Editionを扱うとしても、特に問題は起こらないと考えた。厳密にJIS X 4159準拠を目指すなら完全とはいえない可能性があるが、XML 1.0勧告を読み、理解するという趣旨であれば、問題ないレベルであると思う。

　ではXML 1.1はどうかというと、いまのところXML 1.1に対応するJIS規格を作成する具体的な予定はない。具体的な予定がない、ということは、本当にXML 1.1が利用されるようになるか、まだ懐疑的な見方が多いためである。それは、この連載がXML 1.1に対応することに価値があるか不透明であることも意味する。一応、なぜ懐疑的に見られているのかという理由の概略を説明しておく。

XML 1.1の与えるインパクトとは？

　まず最も重要なのは、XML 1.1の「5.1 Validating and Non-Validating Processors」にある以下の文章である。

Programs which generate XML SHOULD generate XML 1.0, unless one of the specific features of XML 1.1 is required.

　大ざっぱに訳すと、「XMLを生成するプログラムは、特定のXML 1.1の機能が必要とされない限り、XML 1.0を生成することが望ましい」ということになる。

　つまり、XML 1.1という勧告があるとしても、XML 1.1だけに存在する機能を使っていないXML文書は、XML 1.0のXML文書として生成されることが望ましい（SHOULD）とされている。しなければならない（MUST）ではなく、望ましい（SHOULD）とやや弱い表現ではあるが、いまの世の中にある大多数のXMLプロセッサがXML 1.0対応である以上、この規定をあえて破る必要性は考えにくい。

　では、具体的にXML 1.1にしか存在しない機能とは何だろうか。詳しい説明は別途予定しているXML 1.1の解説記事で触れるとして、簡単に説明すると主に以下の2点といえるだろう。

1. 改行文字として#x85と#x2028が追加された
2. 名前文字についての制限が大幅に緩和された

　（このほかに、「C0およびC1制御文字（#x0以外）は、文字参照としてのみ許されるようになった」「“full normalization”という概念が導入された」という変更もあるが、ここでは略す。詳しくはXML 1.1の解説記事で触れる予定だ）

　この2点のうちのいずれかの機能を使う場合のみXML 1.1を名乗るXML文書を作成する意味が出てくる。しかし、このいずれも、一般の利用者に強いニーズがあるとは考えにくい。

　改行文字の追加とは、主にメインフレーム（大型コンピュータ）で使用される改行文字（#x85）をXMLの改行文字と認めることが主な変更である。しかし、もともとメインフレームでXMLを使う機会が多くないうえに、メインフレーム上の文字コードはパソコンなどとは互換性がないため、インターネット／イントラネットに送信する際にコード変換することになり、その際に改行コードも変換すれば済むので、特に必須の機能ではないという意見もある。

　もう1つの名前の文字の制限緩和とは、XML 1.0勧告後にISO 10646/Unicodeに追加された名前文字をXMLの名前文字として利用可能にするという変更である。

　例えば、日本では珍しい人名漢字などがこれに含まれる。一見、便利な機能拡張であるかのように思えるが、名前文字とは要素や属性の名前やNMTOKEN型の属性値で使われる文字でしかない。通常の文字データとして記述できる文字の範囲は、XML 1.0の時点で十分に広く、XML 1.0勧告後に割り当てが行われた文字に対応するコードも最初から包含している。つまり、今回の変更が影響するのは、要素などの名前に拡張された文字を使いたい場合に限られる。

　珍しい人名漢字などは、文字データとして記述するニーズこそあるだろうが、要素名などに使うとは思えない。おそらく名前を記述する要素は<name>や<名前>のように記述されるため、要素名に珍しい人名漢字などが入り込むケースはほとんどあり得ないだろう。また、要素名などを英語で表記する場合には、まったく影響のない機能ということもできる。

　以上のことから考えると、アメリカや日本でXML 1.1を利用する必然性はほとんど存在しないのではないかと思える。上述のJIS規格の動向とも併せて検討した結果、この連載ではXML 1.1よりもXML 1.0 Third Editionを扱っていくという方針を決定したわけである。

使われない標準仕様が生まれるのはなぜか

　余談になるが、なぜ使われない可能性が指摘される標準仕様が生まれるのか、その理由について付記しておこう。これは、この連載の趣旨にも合致する話題である。

　もし、標準仕様というものが、「論理的に正確で正しいものが、冷静に仕様書にまとめられている」とするなら、生まれた直後に「これが使われることはないだろう」と評される仕様書が勧告されるのは奇異に思えるかもしれない。今回は特に、旧版の改訂版が同時に勧告されるという異例の事態になっていて、いかにXML 1.1が期待されていないか、ということが強く印象付けられる。しかし、生まれた瞬間にだれもが死んでいると認識している標準仕様は、実はこの世界ではしばしば生まれてくる。

　なぜ、そのような事態が起こるのかといえば、標準仕様を決定することに関与する人たちも人間であり、それぞれに背負った組織があるためである。自分の主義主張を押し通そうとする者もいれば、組織の都合で自らの都合の良い方向に変えていこうとする者もいる。そして、実際の標準仕様が成立するか否かの決め手になるのは、論理的な冷静さよりも、個人の情熱であったり、政治的な駆け引きのゲームであったり、大きな権限を持つ組織や大金を動かす大組織であったりすることも珍しくないのである。W3Cのような多くの企業が参加している場では企業間の駆け引きになったりするし、ISOのような国際規格の世界になると、国家間の駆け引きになったりもする。しかし、国家間の駆け引きといっても、実際には担当者の主義主張の戦いとなる場合もある。

　そのような戦いを手練手管で勝ち抜くことが、標準に携わる者の必須スキルということもできる。XML 1.1をじっと眺めると、そのような手練手管らしきものがうっすらと見えてこないだろうか。例えば、メインフレームの改行文字を追加することに不同意な人たちが多いにもかかわらず、それが行われたのは一種の手練手管といえるかもしれない。また、改行文字追加が行われたものの、それを使わない場合はXML 1.0として出力すべきという文言を付け加えて、XML 1.1に対応しなくてもほとんどのケースでは問題なく運用できるようにしてしまったことも、一種の手練手管といえるのかもしれない。このあたりは、XML 1.1仕様制定の現場を知らない部外者の想像にすぎないが、そのようなことが起こっても何ら不思議ではないのが標準仕様作りだというのは、間違いないだろうと思う。

　そこから必然的に導かれる結論は、標準仕様が世の中で実際に役に立つとは限らない、ということである。これは経験的な事実として裏付けられているといってもよい。では、標準仕様など作らない方がよいのか、というと、そうではない。やはり、標準が存在することによって得られる恩恵はある。出来が多少悪くても、恩恵が大きければ、それは生まれてくる必然性があった標準仕様だと筆者は思う。今回のXML 1.1の抱える問題は、XML 1.0に付け加えた恩恵があまりに薄いということにすぎない。

本文に戻る

 

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

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