- PR -

『XMLにおける「ボヘミアンと貴族の階級闘争」を読み解く』を読み解いてみたら例示が欲しくなりました

参照元記事 | 同じ記事を参照しているスレッド一覧
1|2|3 次のページへ»
投稿者投稿内容
NothingButXMLInfoSet
ベテラン
会議室デビュー日: 2003/03/31
投稿数: 65
投稿日時: 2003-04-15 22:28
引用:

これまであまり日の当たっていなかった「少量多品種」「不定型」なデータの処理に対して、効率アップを実現する救世主だと認識していた。・・・事前に厳密なデータ設計をするよりも、取りあえず必要な処理ができればOKという場面も多くあるし、素早く安価にシステムを構築する方が重要とされる場合もある。

私を含め、＠ITの読者の中には、このようなことが必要とされる場面が想像できない方が多いのではないでしょうか。実際に目に付きやすいシステム例を挙げていただけると理解が深まるのですが。

引用:

PSVIとは、スキーマを用いた妥当性の検証が終了した段階での、情報セットのことを意味する。通常、XML文書はXMLパーサにより解釈され、その結果はアプリケーションに渡される。PSVIという用語は、この検証が終了した段階で、XML文書には含まれていないXMLパーサが付け加えた情報がある、ということを明確に示すために存在している。

この部分は少し大雑把過ぎます。XMLパーサーがパースを行うと、結果としてXML InfoSetが作成されます。アプリケーションに渡されるのはInfoSetです。XML Schemaプロセッサは、InfoSetをさらに処理することで、「XML SchemaによるValidationの後（Post）のInfoSet」を作ります。記事で挙げられているデフォルトの属性は、InfoSetにすでに含まれている可能性もあります。PSVIには確かにXML文書に「明示的に」含まれていなかった情報が含まれていますが、その前段階としてXMLパーサーがパースを行った結果作成されたInfoSetにも、すでにXML文書に「明示的に」含まれていなかった情報が含まれています。XML Schemaでは、これらはXML文書に「暗黙的に」含まれていたものと解釈しています。「もともとなかった情報を付け加えた」わけではありません。

引用:

例えば、あるシステムでXML文書の処理のレスポンスが悪いので改善したいという要望が出たとしよう。・・・すると、スキーマでデフォルト値が設定されていたXML文書の処理では、改善前と後で処理結果が同じにならない可能性がある。

これはXML Schemaでは、暗黙的にあったはずの情報をシステムが勝手に消してしまったものと解釈されます。XML Schemaがなければデータに意味はないとするのはこういう点からです。何もデータ型がどうこうという話だけではありません。

＃XPathにデータ型がほとんどなかったなんていう議論もちょっとよくわかりませんけど。。。

引用:

一方、ボヘミアンが支持するスキーマ言語であるRELAX NGにはPSVIが存在しないので、スキーマ妥当性の検証を行っても行わなくても、処理結果に相違は生まれない。

XML Schemaでも処理結果に相違は生まれないようになることはあります。それは、XML Schemaのおかげではなく、本来データが持っている意味の上でそうなっているからです。RELAX NGの昨日を使って、処理結果に相違が生まれるようにすることも可能なはずです。それはRELAX NGのせいではなく。本来データが持っている意味がそういう手段で表現されているからです。

引用:

スキーマを使わない「整形式のXML文書」の処理は行わないと考えている。貴族はすべてのXML文書を「妥当なXML文書」とすべし、という立場だ。

この部分には注意が必要です。XML Schemaが言っているのは、「PSVIを見なければ真のデータは取得できない」ということです。「整形式」と「妥当性」という言葉はXML 1.0の範疇の言葉であり。XML Schema仕様には「整形式文書の表現としてのInfoSetを扱う」と明記してあります。DTDを使った検証によって「妥当なXML文書」と判断されたかどうかは、PSVIの作成には　影響しないし、貴族が考えるデータの意味を左右するわけでもありません。

引用:

ボヘミアン的なニーズは何もいまになって急に生まれたものではない。「貴族」的な方法ではうまく扱えない領域は何十年も前から存在しており、それに取り組むためのさまざまな試みが行われてきた。

ここが肝なんだと思います。私をはじめ、多くの貴族さんたちにはそのような試みは見えないし、存在を意識できないのです。何か「あ！」という例があれば私の疑問は一気に氷解しそうなんですけどね。。。
井上孝司
ぬし
会議室デビュー日: 2001/09/08
投稿数: 668
お住まい・勤務地: 東京都
投稿日時: 2003-04-16 00:23
井上です。

極めて私的な話ですが、私みたいに「俺ボキャブラリ」で XML 化した文書データを XSLT で HTML 化して Web サーバに上げる、なんていう使い方をしていると、後からいろいろと機能拡張したくなって XML 側にタグを書き足すことは、内容が固まるまでは頻繁にありました。そこで「XML Schema で書いたスキーマがないと駄目です」なんていわれたら、困っちゃいますねぇ…

もちろん、用途によっては厳密な validation が必要なこともあるでしょうし、そういう意味では「貴族」側の言い分も分からないではないのですが、自分みたいにゲリラ的な (?) XML の使い方をしていると、validation 必須などという窮屈な時代になってしまった日には、何か別の方法を探したくなりそうです。
_________________
www.kojii.net
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2003-04-16 10:11
>ここが肝なんだと思います。私をはじめ、多くの貴族さんたちにはそのような試みは
>見えないし、存在を意識できないのです。何か「あ！」という例があれば私の疑問は
>一気に氷解しそうなんですけどね。。。

その前に，PSVIやXML Schemaを使うメリットを，一つでも挙げる方が先なのでは？
妥当性検証でさえも，実際のプログラム作成ではほとんど何の効果も期待
できそうにないですしねえ．

＃デメリットのほうは，XML Schemaを理解して，スキーマを作成するのが
＃面倒というのが第一にある．これは他の言語でもなんでも同じだが．
＃＃XML Schemaの場合は，他にパフォーマンスの問題もある．
ほむら
ぬし
会議室デビュー日: 2003/02/28
投稿数: 583
お住まい・勤務地: 東京都
投稿日時: 2003-04-16 12:12
ども、ほむらです。
-----------------
井上氏　へ
僕がXMLとかXML Schemaを勉強するときに参考にしたサイトで
SchemaをもとにXSLTを作るというのがありました。
(
http://www.yuragi.jp/playxslt/index.html
の先にある
　10番 XML Schemaを活かしたXSLT開発技法
です
)
熟練した方に紹介するようなサイトでもないかと思いますが
(実際問題この手法がどの程度役に立つのかはわかりませんし）
なかなかに面白いやり方なのかなと応用範囲を考えてみたこともあります。
変換に時間がかかってしまうことは否めないところでしょうか
エイリアスの意味を知ったコンテンツでもあります。
-----------------
悪夢を統べるもの氏 へ

XML schema .... 適用方法がわからなくて挫折してしまいました。
以下は僕の想像です。ご容赦＞＜。
-----------------
XML schemaはただ、XMLのデータ受け渡しとか、変換のような
読み込んで出力するなんて場合には恩恵はないと思っています。
制約が強くなるだけだし。。
ですが、反対にアプリ側からユーザーにデータを入力をさせた場合
データを照合するという場合には利用できると思っています。
たとえば、XMLのデータを入力するなんてソフトを考えた場合、

あらかじめ入力すべきデータ構造がソフト的に理解できていれば
いろいろな入力支援・・・・D&Dで雛型のノードセットを挿入するとか
入力時にクリックしただけで項目を選択させれるとか・・・が可能ではないでしょうか？

XML schema利用できる場面は極めて少ないようにおもいますが
利用できた場合のメリットは開発サイドからは大きいと思います。

追記：
ちなみに、僕も貴族的ＸＭＬには、反対です。
なぜなら、僕的にXML文書とはデータであり情報ではないからです。
その関係で、データに型を付け加えるなんて逆にナンセンスと思ってしまいます。
いってみれば、
表現に関する雛型がＸＳＬであるならば
情報に関する雛型がschemaではないかなと。。。
で、現状XML文書を考えてみた場合XSLTがなくとも支障のない場合もおおいわけで。
これは、将来的にもかわらないはずと信じています。

訂正がてらに追記を追加

[ メッセージ編集済み 編集者: ほむら 編集日時 2003-04-16 14:24 ]
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2003-04-16 17:36
objectです。

私は、「ボヘミアンと貴族の階級闘争」は、ただ単にXMLでの問題では無く、また人間対人間の問題でも無いと思っています。
人間の認識に於ける大きな問題だと思っています。

従って、XMLに関する問題を個々に取り上げた所で、何の解決にもならないと思います。

そこで、私は物理学者「武谷三男」氏の言葉を取り上げたいと思います。
「物理学の発展は第一に即自的な現象を記述する段階たる現象論的段階、第二に向自的な、何がいかなる構造にあるかという実体論的段階、第三にそれが相互作用の下でいかなる運動原理に従って運動しているかという即自的かつ向自的な本質論的段階の三つの段階に於いて行われる事を示した。」

この中で、第一と第二の方法はそれぞれ古くから言われている、
・帰納的方法
・演繹的方法
に関係するのでは無いでしょうか？（全体としては弁証法です）

第二・三の段階は、あくまでも、第一の段階を経る事によって訪れると私は思います。
第一を否定した場合、第二・三の段階は無いと理解すべきだと思います。
実際、XML Schemaが、最初からあった訳では無いし、XMLが存在しなければXML Schemaは生まれて来なかったと思います。

ボヘミアンと貴族は、相補的な関係であり、対立する関係では無いと思います。
そういう意味で、最終的にはボヘミアンを葬り去る事が無いよう、私は祈ります。
ボヘミアンと貴族の「階級闘争」にしてはいけないと私は思います。
masayh
会議室デビュー日: 2002/03/30
投稿数: 10
投稿日時: 2003-04-16 18:29
現実世界はインスタンスだけなので、それをそのまま表現するだけならインスタンス、この場合は、XMLドキュメントだけで済ますことは可能です。しかし、そのインスタンスの構造や振舞いに関する支配法則、制約などを記述すること、あるいは、ある一連の共通な性質で分類しようとすれば、なんらかの分類のためのメカニズムが必要です。集団(クラス)の属性を記述するのがタイプです。したがって、XML Schemaもタイプシステムですから、そのタイプによる分類の1技術です。

しかし、制約を記述するのはタイプだけではありませんし、それだけでも不十分です。例えば、MeyerのDesign by CotractはInterfaceのタイプだけでは表現不可能な制約条件を補足して規定します。クラスの属性間の関係や、Interfaceの呼び出しの条件はタイプだけでは記述できませんから。また、Smalltalkのような静的な型がない言語では、より制約を型以外のところで表現しなければなりません。

OOPではクラス定義がないとインスタンスが生成できませんが、それは実装上の話であり、実世界ではクラスがなくてもインスタンスは存在できます。

現に、クラスではない、別の抽象的なモデルでインスタンスを管理することは可能で、例えば、アスペクトやロールなどのモデル要素はある「関心」でインスタンスを扱えます。

こういうことを考えるとXML Schemaは必須の技術ではありません。ただ、分類のためには便利なツールであり、実装上はいいツールとなるでしょう。データ変換や他のデータモデルとの対応づけ、そういうもろもろな処理ではあれば便利です。
NothingButXMLInfoSet
ベテラン
会議室デビュー日: 2003/03/31
投稿数: 65
投稿日時: 2003-04-18 21:39
皆様ありがとうございます。

ボヘミアン的なXMLの利用法の広く応用されている具体例として、RSS(2.0)があります。このRSSというやつが、およそ静的な型をベースにしたプログラミング言語では扱えないシロモノで、スキーマを記述しようにもどうせxs:anyの羅列になってしまうというものです。こういうデータにスキーマを当てはめて静的構造を作り出そうとすると、その静的構造はすぐに古くなってしまい、「今」流れているRSSには対応できなくなってしまいます。井上さんが挙げられた「俺ボキャブラリ」が、ある種の均衡を保ちながら世界中で運用され、独自に拡張されている状況です。

「静的構造をベースにシステムを設計し、静的な型システムを持つプログラミング言語で実装する」というシステム開発の手順では、RSSのようなものを相手にできません。この点が、ボヘミアンが主張するXMLの柔軟性であり、貴族の堅苦しさであろうと思います。

＃でも、その堅苦しさが世の趨勢であることは、＠ITの人気記事ランキングに毎度UMLとJavaが含まれ、XMLのフォーラムはちっとも盛り上がらない（失礼！）ことからも、間違いないでしょう。

ただし、貴族が単純に妥当性検査のためだけにスキーマ必須、検証必須と言っているわけではないことも無視するわけにはいきません。貴族は、スキーマをmasayhさんがおっしゃるような、ある種の実行時型情報として扱おうとしているだけです。この種の「制約」の中には、DTDのIDとIDREFや、XML Schemaのxs:unique、xs:key、xs:keyrefなどで記述できるものもあります。Schematronならもっと柔軟に記述できますし、場合によってはXSLTを使って制約を記述することもできるでしょう。

実際にXSLTを使ってデータをHTMLに整形するとき、そこでは暗黙のうちにXSLTをある種の実行時型情報として利用していて、「強調すべき項目」「箇条書きでまとめるべき項目」という情報がXSLTによって追加されているのです。「スキーマによる情報の追加＝悪」という単純な図式は成り立ちません。強調すべきかどうかは、XSLTが「後から付加した」情報ではなく、むしろデータそのものが最初からそういう「プロパティ」を持っていたと考えるべきでしょう。

要するに、意味を伝える手段をタグの文字列と＜＞のネスト構造だけにするのか、それとも他のさまざまな機能を積み重ねてもいいものなのか、と考えれば、前者はあまりにも単純すぎて実用に耐える場面は限られるという結論はそれほどズレてはいないのではないでしょうか。
ほむら
ぬし
会議室デビュー日: 2003/02/28
投稿数: 583
お住まい・勤務地: 東京都
投稿日時: 2003-04-21 11:46
ども、ほむらです。
----------------
引用:
実際にXSLTを使ってデータをHTMLに整形するとき、そこでは暗黙のうちにXSLTをある種の実行時型情報として利用していて、「強調すべき項目」「箇条書きでまとめるべき項目」という情報がXSLTによって追加されているのです。「スキーマによる情報の追加＝悪」という単純な図式は成り立ちません。強調すべきかどうかは、XSLTが「後から付加した」情報ではなく、むしろデータそのものが最初からそういう「プロパティ」を持っていたと考えるべきでしょう。

個人的には「スキーマによる情報の追加＝悪」なのではなく。
スキーマによる情報の追加を必須とすることに納得いかないんです。。。
今の用途として(将来的にも変わらないと思いますが)

ＸＳＬＴはHTML等 出力形式変換での使用方法が主流だと思います。
変換するためには型という情報は不要に思います。あえて言うのであれば
すべてが文字列であればいいと思います。
このことからXSLTとスキーマが同時に必要なる必要もないわけで・・・
逆にソフト側からXMLのデータをデータとして読み込むときにXSLTは必要ないはずです。

# XSLT有害論を読んでいて思ったんですが、今回のこの貴族的な人方たちは
# このXSLT否定派に関係するんじゃないかなと思ってみたりして^^;;;;


[ メッセージ編集済み 編集者: ほむら 編集日時 2003-04-21 11:47 ]
1|2|3 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）