第26回 解析対象実体の「テキスト宣言」と「整形式」 Page 2
川俣 晶
株式会社ピーデー
2004/10/15
ここからは「4.3.1 The Text Declaration(4.3.1 テキスト宣言)」を読んでいこう。まず、テキスト宣言を記述する場所について記述されている。
External parsed entities SHOULD each begin with a text declaration. |
外部解析対象実体は、テキスト宣言で始まることが望ましい。 |
外部解析対象実体は、XML勧告で規定される構文によって記述される実体のうち、文書実体の外部にあるものを示す。そのような実体を記述する場合に、その先頭にはテキスト宣言を記述することが望ましい(SHOULD)としている。
では、具体的にテキスト宣言とは何かというと、生成規則が以下のように記述されている。
Text Declaration
|
この生成規則は、例えば以下のような文字列にマッチする。
<?xml version="1.0" encoding='UTF-8'?>
これを見て、「あ、見たことがある」と思った読者も多いと思う。'<?xml'で始まり、'?>'で終わり、versionやencodingが登場する構文といえば、XML宣言が思い出される。果たして、テキスト宣言とはXML宣言の別名なのだろうか。その答えはノーである。実際に、XML宣言を定義する生成規則である生成規則[23] XMLDeclと比較してみればそれがよく分かる。
|
相違点は、3つある。まず、VersionInfoの後に「?」記号が付いているか否かに注目してみよう。XML宣言では、生成規則[24] VersionInfoつまり、version="1.0"に相当する部分に「?」記号は付いていない。つまり、XML宣言でバージョン表記は省略できない。しかし、テキスト宣言では生成規則[24] VersionInfoの後ろに「?」記号があり、省略可能であることを示している。つまり、バージョン表記なしのXML宣言はあり得ないが、バージョン表記なしのテキスト宣言はあり得るのである。
次に、EncodingDeclの後に「?」記号が付いているか否かに注目してみよう。XML宣言では、生成規則[80] EncodingDeclつまり、encoding="……"に相当する部分に「?」記号が付いている。つまり、XML宣言でencoding表記は省略できる。しかし、テキスト宣言では生成規則[80] EncodingDeclの後ろに「?」記号がなく、省略不可であることを示している。つまり、encoding表記なしのXML宣言はあり得るが、encoding表記なしのテキスト宣言はあり得ないのである。
最後にSDDecl?の有無を見てみよう。生成規則[32] SDDeclは非依存文書宣言に対応する生成規則である。非依存文書宣言を記述することは、XML宣言でのみ可能であり、テキスト宣言では記述できない。非依存文書宣言は文書についての宣言であるが、テキスト宣言は文書ではなく、文書の一部に付くものなので、文書全体についての宣言を含むことができないのは当然の規定といえる。
このように、この2つを見比べると、かなりの違いがあることが分かる。以下のように記述した場合、XML宣言としてもテキスト宣言としても正しいが、どちらでも正しい宣言はどちらかといえば例外的であることが分かる。
<?xml version="1.0" encoding='UTF-8'?>
両者が一致しないことから、複数のXML文書を取り込んだXML文書は作れないことが分かる。例えば、多数のXML文書の中から、特定の条件を満たすノードをXPath式で抽出したいと考えたとしよう。その場合、個々のXML文書を外部解析対象実体と見なして、1つの文書実体からすべて参照させることができれば、容易にすべての文書を1つのXPath式の対象とすることができる。しかし、すでに説明したように、XML文書(文書実体)の先頭に記述されるXML宣言と、外部解析対象実体に記述されるテキスト宣言は完全には一致しないので、そのような処理は一般的には実現できない。なお、文書実体と外部解析対象実体が一致しない理由としては、文書型宣言の有無などのほかの条件もあることを補足しておく(複数のXML文書を集めた大きなXML文書を作成することの難しさについては、Java World誌の連載「XMLボキャブラリの理論と実践」で檜山正幸さんが詳細に論じていることも補足しておく)。
しかし、逆の解釈もまたあり得る。上記の例のように、XML宣言としてもテキスト宣言としても正しい宣言を記述することができる。それに続く部分も、文書実体として解釈しても、外部解析対象実体としても正しい書き方を行うことが可能だろう。そのような厳しい条件を課して記述された文書実体があれば、文書実体にも外部解析対象実体にもなる、という事例がないともいい切れない。しかし、それはかなり特殊な状況であって、一般論としてはあり得ないと思った方がよいだろう。
さて、次はテキスト宣言に関する詳細な規定である。
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. |
まずテキスト宣言は、そのままの形で現れなければならず、解析対象実体への参照を経由してはならない。外部解析対象実体において、テキスト宣言は、先頭以外のいかなる位置にも出現しない。外部解析対象実体中のテキスト宣言は、置換テキストに含まれるとは見なさない。 |
「そのままの形」とは、「解析対象実体への参照を経由しない」ということである。これは当然の要請といえる。テキスト宣言は、その外部解析対象実体がどのようなバージョンのXML勧告によって記述されているか、どのような符号化(encoding)が使用されているかを示すために使われる。従って、それらがその外部解析対象実体の外部で宣言されることは不適切ということになる。例えば、ある外部解析対象実体の符号化方式をシフトJISからUTF-8に変更したからといって、DTD中の解析対象実体の宣言を直さねばならないような使い方は不便極まりない。これは禁止されるのが当然の要請だろう。
別の角度から見ても、これは納得できる制約である。一般的なXMLプロセッサ(XMLパーサ)の実装では、外部解析対象実体を1回の処理手順ですべて処理することは考えにくい。多くの場合、符号化された文字を内部処理で使用される符号に置き換える処理と、解析処理は別々に行われることになるだろう。例えば、最近の多くのプログラム言語(C#やVisual Basic .NETやJavaなど)では、UTF-8やシフトJISで記述されたXML文書を、まずUTF-16に直したうえで処理を行うことになるだろう。そのような構造を実現するためには、解析処理を行うことなく符合化方式を決定できねばならない。符号化方式の変換が終わってから解析に取り掛からねばならないためである。もし、解析結果によってしか符号化方式が分からないとすれば、それは実行不可能ということになる。
次の文は、テキスト宣言は外部解析対象実体の場合には、その先頭にしか記述してはいけない、ということである。決して外部解析対象実体の中間あたりに記述してはならない。これも、実装の都合を考えれば、納得のいく制約である。符号化方式を特定するために、符号化方式が未知である外部解析対象実体の内部からテキスト宣言を探し出す処理は、実現に困難が伴う可能性が高く、とても悩ましい。
次の文でいうテキスト宣言とは、もちろん外部解析対象実体の先頭に記述されるものである。それが、置換テキストの一部にならない、ということである。置換テキストの一部にならないということは、最終的に応用ソフトに渡される情報の中に、テキスト宣言に関する情報が含まれないことを意味する。そのため、応用ソフトは、テキスト宣言があったかどうか、そこに記述されたバージョン情報や符号化(encoding)情報について知ることはできない。
以上で、「4.3.1 The Text Declaration(4.3.1 テキスト宣言)」は終わりである。あっさりと終わってしまった感じもあるが、それはXML宣言との大きな共通性のためだろう。確かにXML宣言とテキスト宣言は一致しないが、XML宣言とテキスト宣言は参照する生成規則を共有しており、相違点はそれらを書くか書かないか、省略できるかできないか、という部分に限られる。それを除いた個別の内容は、XML宣言と共通であるため、それらをここで規定する必要はない、ということだろう。(次ページへ続く)
2/3 |
Index | |
やさしく読む「XML
1.0勧告」 第26回 解析対象実体の「テキスト宣言」と「整形式」 |
|
Page
1 ・解析対象実体の概要 ・解析対象実体とは何か |
|
Page 2 ・テキスト宣言 |
|
Page 3 ・整形式の解析対象実体 |
連載 やさしく読む「XML 1.0勧告」 |
- QAフレームワーク:仕様ガイドラインが勧告に昇格 (2005/10/21)
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か (2005/10/12)
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ (2005/9/13)
文字符号化方式(UTF-8、シフトJISなど)を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様(XKMS 2.0)が勧告に昇格 (2005/8/16)
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
|
|