2009年1月26日月曜日

XMLを扱う (その5)

ChangeLog-modeからもってきたので、読みにくかったらすいません。

そういえば、XML namespaceというのを正確には理解していない気がする。まずそ
れをやる。

** 読むべきは、Namespaces in XML 1.0 (Second Edition)

** 隅から隅まで理解したいわけじゃない。そして、XMLのnamespaceって
Common Lispなどのプログラミング言語の名前空間とはかなり違うものであ
ること自体はそこそこ捉えている。

** 興味は、namespaceを指定するURIのあり様がいまどうなっているのか、
ということ。namespaceを実際に規程するのがスキーマ定義文書だとすると、
それが要素や属性を規程する様との兼ね合いにおいてそれを理解したいと
いうこと。

*** an XML namespaceはURIで特定される。

*** an expanded nameはa namespace name とa local nameのa pairである。

*** a name NがURI Iで特定されるa namespaceに属するとき、the namespace
nameはIである。

*** a name Nがどのnamespaceにも属さないとき、them namespace nameは
値が空である。

*** いずれにしても、the local nameはNである。

*** URI自体は、XML文書の中での要素や属性にそのまま使うことはない。
かわりに、qualified namesを使う。

*** qualified namesは、2通りあり、prefixed namesかunprefixed names
である。

*** 属性にてnamespaceを宣言する構文(よくみるやつ)は、prefixesと
namespace namesをbindする。そこで、a default namespaceを指定でき、
それがunprefixed namesとなる。

*** 前項の構文はそこかしこの要素の属性として記述できる。その記述に
したがってスコーピングされる。


*** namespace参照につかわれるURIについて

**** 空文字列は禁止。

**** 相対URIは廃止された。自文書参照も廃止された。

**** URIは、名前が同じ名前空間に属するかどうかの判定に使われる。そ
の判定は、URIどうしを文字列として比較して行う。

**** 次のものは場合によってURIとして指しているリソースは同じかもし
れないが、名前空間としては別である。

------------
http://www.example.org/wine
http://www.Example.org/wine
http://www.example.org/Wine
------------

**** 次のものはURIとして指しているリソースは同じかもしれないが、名
前空間としては別である。

------------
http://www.example.org/~wilbur
http://www.example.org/%7ewilbur
http://www.example.org/%7Ewilbur
------------

*** 名前空間の指定

こんな感じ。

------------
<x xmlns:edi='http://ecommerce.example.org/schema'>
<!-- the "edi" prefix is bound to http://ecommerce.example.org/schema
for the "x" element and contents -->
</x>
------------

*** qualified names

こんな感じ。

------------
<!-- the 'price' element's namespace is http://ecommerce.example.org/schema -->
<edi:price xmlns:edi='http://ecommerce.example.org/schema' units='Euro'>32.18</edi:price>
------------
------------
<x xmlns:edi='http://ecommerce.example.org/schema'>
<!-- the 'taxClass' attribute's namespace is http://ecommerce.example.org/schema -->
<lineItem edi:taxClass="exempt">Baby food</lineItem>
</x>
------------

** 名前空間とスキーマと妥当性検証について

さて、URIによって名前空間が特定される。名前空間はXMLSchemaで記述さ
れているとする。すると、URIと具体的なXMLSchemaのbindを管理している
人がいる。そのbindはどうすればわかるのか? URIが、
http://www.w3.org/1999/xhtml
などの場合は、このドメインの所有者に問合わせればいいのだろう。では、
urn:loc.gov:books
などの場合は、どうするのだ?というとIANAをみればいいのかな。

URN Namespaces

いずれかによって、XMLSchemaを入手できる。ここで疑問がある。このよう
にして人間はbindを知ることができるが、ソフトウエアであるXMLプロセッ
サ(やバリデータ)はどうやってこのbindを知るのだろう?

jingの場合は引数で明示的にSchema (例えばrnc)を渡す。すなわち
default namespace のSchemaをここで指定するのだろう。そしてそのrncの
中には、

namespace ab = "http://www.hoge.com/addressBook"

などと参照するnamespaceの定義がある。ここでは、

http://www.hoge.com/addressBook.rnc

がリソースとして存在していることを仮定しているようだ。

nxml-modeの場合は、locating filesにlocating rulesを記述しておき、
それによって探してくる方式だ。例えば、

------------
<?xml version="1.0"?>
<locatingRules xmlns="http://thaiopensource.com/ns/locating-rules/1.0">
<namespace ns="http://www.w3.org/1999/xhtml" uri="xhtml.rnc"/>
<documentElement localName="book" uri="docbook.rnc"/>
</locatingRules>
------------

など。というわけで、何かを仮定したり、何かで人が指定してあげるとい
うことなのだろう。

さて、それらXMLSchemaはどう役に立つのかというと、

------------
<?xml version="1.0"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
xmlns:isbn='urn:ISBN:0-395-36341-6'>
<title>Cheaper by the Dozen</title>
<isbn:number>1568491379</isbn:number>
<notes>
<!-- make HTML the default namespace for some commentary -->
<p xmlns='http://www.w3.org/1999/xhtml'>
This is a <i>funny</i> book!
</p>
</notes>
</book>
------------

みたいなケースにおいて、urn:ISBN:0-395-26341-6に紐付けられたSchema
によって、isbn:numberの型が何であるかがわかる。また、
urn:loc.gov:booksに紐付けられたSchemaによって、book要素の中にtitle
要素を入れていいことがわかる。ここで要注意なのは、さらには、この
Schemaによって、isbn:number要素も入れていいこともわからなくてはいけ
ないのだ。そうでなければ、ここでのbook要素の妥当性チェックをすると
きに、isbn:numberが未知の要素であることになりエラーとなってしまうだ
ろう。

XML namespacesだけを考えているときは、そこかしこにあるSchemaを
xmlnsで指定して語彙拡張できるような単純足し算なものということでで
よいのだけど、 そうやってつくった文書全体の妥当性チェックを考えると、
結局デフォルトSchemaで足し算のあり様がどのようなものなのかを詳細に
記述しなければならない。先の2つの親たるSchemaがあればいいだけでな
く、それをどういう風に組み合わせて使うのかを定義するSchemaが必要で
あり、それは構造に関しては少なからぬ再定義が必要となる。

それゆえ、namespaceを使って再利用するのは構造をもったデータ型でなく、
いわゆる Simple data type がよいのかもしれない。

平日に多少でも進めたのがうれしい。

次回は例を作ってためしてみる。

0 件のコメント: