Re: [pps] Call for review of the PPS core working draft 02

["Koichi Wada" <kwada@infoteria.co.jp>]

和田＠インフォテリアです。

>> ●ルートとなるエレメントは〜である。
>
> これは、実はまだ未定なのです。メッセージによってルート
> エレメントが変わることを想定しています。

この仕様にしたがってXMLを作ろうと思うと、どこから始めてよいかわからないように感じまして、
〜のいずれかをルートとするXMLとなるという説明をして、
〜がどういう集合になるか（全部または限定）の定義をつけるとよいのではないかと思ったしだいです。

未定とするばあいは、どれもが用途に応じてルートになりうるということで、それは書いておいたほうがよいように思います。

>> ●各エレメントはアトリビュートに必要なパラメータを設定する。
>
> 必須となっていないアトリビュートには、パラメータを設定しなくても
> よいことにしたいのですが。

こちらは、必須／省略可の区別ではなくて、
通常のメッセージ仕様は、テキストノードに値を設定しますが、それらとは違い、アトリビュートを用いていると説明のためのものです。
そういう説明を入れておくと、PSLXボキャブラリなどといっているものは、アトリビュートの値に関することだということが、わかりやすくなると思いました。

>> ●アトリビュートに設定される値に関しては、用途に応じてボキャブラリーを定義し、送信側と受信側で、合意していなければならない。
>
> うん、ここはポイントですね。そのとおりなのですが、問題はどうやって
> 合意するかです。（１）拡張仕様（ＰＳＬＸ拡張、Ｓ９５拡張、あるいは
> 独自仕様）を事前に人間系で確認する。（２）サフィックスや名前空間などで
> 自動認識する、などが考えられますが。後者は実装上可能でしょうか？

下に書いてますが、まず、XML Schemaの仕様のようにすれば、名前空間を使って拡張仕様に用いるボキャブラリが定義できることがわかりました。したがって、名前空間URIによって使う仕様が自動的に定まるということはできます。

ただ、どのようにして合意するかについては、メッセージ仕様の外になると思います。通常は事前に人間系での合意となるのではないでしょうか。
または、ebXMLのCPPAのような合意事項を交換し、これをサーバーにインストールするとそれにあわせて動作するようなつくりになると思います。

>> pslx:が属性値に現れるとなると、属性値はXML名前空間がカバーする範囲ではないと思いますので、プレフィックスとURIを定めてもあまり意味がないような気がします。形式的にはXML名前空間の仕様からは解釈されず、何を書いてもいいからです。
>
> イメージは、XML Schemaの仕様定義から来ているのですが。
> ＸＭＬスキーマ定義で、例えば、
> <xsd:attribute name="value" type="xsi:dateTime"/>
> みたいに定義しているのは、内部ではどうやっている
> のでしょうか？

XML Schemaの仕様書の1を見ると、たとえば、2.6.1 xsi:typeの値はQNameになるという定義が書いてありました。そして、QNameの解釈の仕方は別のところにありました。つまり、この仕様書の中で同じように定義を書けばできるということがわかりました。(参照でも良いかもしれません。)

> ただ、各アプリケーションに、プレフィックスを取り出し、
> 名前空間と対応づける、という部分をプログラミングさせる
> のは確かにちょっと酷かもしれませんねえ。どうしましょう？？

これは通常のXMLパーザーの外側に実装することが必要になります。ここはSchemaのValidatorや、ebXMLのライブラリみたいに、ライブラリにすることになると思います。

和田浩一 kwada@infoteria.co.jp