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

[Yasuyuki Nishioka <nishioka@k.hosei.ac.jp>]

西岡です。

> >> ●ルートとなるエレメントは〜である。
> >
> > これは、実はまだ未定なのです。メッセージによってルート
> > エレメントが変わることを想定しています。
> 
> この仕様にしたがってXMLを作ろうと思うと、どこから始めてよいかわからないように感じまして、
> 〜のいずれかをルートとするXMLとなるという説明をして、
> 〜がどういう集合になるか（全部または限定）の定義をつけるとよいのではないかと思ったしだいです。

今回の仕様（パート１）は単なる辞書的な利用を考えていて、
これとは別に、各ユースケースごとにメッセージの仕様を
パート２で作ろうと思っています。たとえば、ディスパッチ情報を
生産現場に送る場合、生産オーダをスケジューラーに送る場合
など、個々のユースケースごとにルートタグを設定します。

以前は、すべて共通のタグ＜ＰＳＬＸ＞でくくり、アトリビュート
でメッセージの種類を設定していたのですが、これだと、メッセージごと
に異なるシンタックスを記述できなくなり都合がよくありません。

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

いいえ、パート１で定義したタグはルートにはなりえません。

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

そう意味でしたか。そうですね。これはＰＰＳ（ＰＳＬＸ）の特徴といえる
のかもしれません。ただし、唯一<description>要素には、テキスト
ノードに値が設定できます。ここだけ例外なのですが、統一性を重視
するなら、かえることも可能です。どうしましょうか？

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

-- 
Yasuyuki NISHIOKA, Dr.Eng.
MIT, 41-211
77 Massachusetts Ave
Cambridge MA 02139
Phone 617-452-2982, Fax 617-253-2249
nishioka@mit.edu <nishioka@k.hosei.ac.jp>