ものがたり
戻る

2004-11-21

■

YaSTのアイコンはGNOME Usability Guideline1から考えたら落第生だよなぁ、とか思う今日この頃。たとえば、ブートを表すアイコンが「靴」であったり、ランレベルを表すアイコンが（「走る」を連想させる）「道路」のマークではいけないのだ。英語が分からないと意味が分からないのだから。

で、もうfeedbackしたから、SuSEの中の人が伝え直す必要は無いんだけど、SuSEってbugzilla持ってないのね…しかも「bugzillaよりMLの方が優れている」とかいう意見がMLでは中心みたいだし。メタ情報への理解というか、ナレッジ マネジメントってそういうものなのかなあ。僕はbugzillaの方がずっと優れていると思うけど。NovellはNovellで外からでも検索できるknowledgebaseを独自に持っているようだけど、これは「MLのが優れている」と言われている割には、MLとリンクしていないようで、“bugzilla”と検索しても、ML上の該当する議論は出てこなかった。

Xxxxed in Translation

うーん、cool communityってどう日本語化したらいいんでしょう。Novell JPのサイトでは優良コミュニティとかなってるけど、これってものすごく見下してる感じで印象悪いですよねぇ。僕だったらイケてるコミュニティ、とか訳すところだけど。売り物のwebサイトでそんなこと出来るか、っていう反論が予想されるけど、そもそも原文でもcoolなんて（比較的）俗な言葉が使われていることを考えれば、そんなにおかしくもないはず（って何か山形氏のクルーグマン日本語訳の解説みたいなこと書いてるな）。いや、まあ、あの会社のページで「イケてる」はどう考えても無理だ。提案するのはやめとこ。気に入ったら採用して下さい中の皆さん（ココがヲチされていることは知っています）。

…と思いつつ、新しいgoogle神様の翻訳betaに投げてみたら、訳してくれないし。

翻訳で原文のニュアンスを伝えるのは、けっこう難しい。そもそも「であるだ調」と「ですます調」を決定する時点で、失敗したりする（この選択は翻訳にとっては重要なものだ。だから、特定の翻訳スタイルを押しつけるような翻訳「コミュニティ」は、実際には翻訳の品質を下げている、と思っている）。個人的な仕事では、Xalanの翻訳については失敗したなあ、と思っている。Xalanの文書はですます調がフィットする紳士的な文体なのに対して、XSLTCの文書は軽快なノリで書かれているのだけど、すっかり逆にやってしまった。

もっと難しいのが、英語をよく分かってない人が書いた文章の翻訳で、僕が一番困るのは実は自分の書いたページを日本語に訳すことだったりする…。ちなみに僕は自分の書いた日本語の文章を英訳するのも困ったりする。壊れた英文を意図的に書けるほど、僕は英語に通じていないので…

XSD Inference (4)モデルグループとパーティクル

Introduction

第4回は内容モデルのうち、モデルグループとパーティクルの推測に関する話。モデルグループとパーティクルはどちらも内容モデルを表すのに使われるものだけど、complex contentの内容として、complexType, extension, restrictionの各要素の子として出現できるのがモデルグループで、内容グループ自身あるいはその子として出現しうるものがパーティクルで、これらは同じものではない（XML Schema Structuresの3.8と3.9の違い）。2

サポートされる内容グループ

XSD Inferenceでサポートされる内容グループは、かなり限られている。

まず、出現回数は、0, 1, maxOccursの3種類に限られている（つまりDTDと同じレベル）。これが不便な制約だと感じる人はほとんどいないだろう。逆に、インスタンス上では12回しか出現しなかったからmaxOccurs=12だ、なんて推測をされても困る。

そして内容モデルだが、具体的には以下の2種類しかサポートされていない：

これ以外は全てNGだ。具体的には

そもそもXSD Inferenceでは、最初に挙げた2パターンしか生成されないのだから、それしかサポートされないわけだ。でも、何でこの2つ以外はサポートされないのだろうか？

…というわけで、上記2つのパターンに絞ってサポートする方が現実的だ。（xs:choiceを含むxs:sequenceという書き方は、何となくやぼったく見えるが、なぜこうしたのかはちょっと分かっていない。）

パーティクル推測プロセス

推測の進め方は、ここから上記2パターンに分けられる。その方が簡単だし。基本的には、sequenceとしての推測が不可能になったときに、はじめてchoiceのsequenceに移行するというモデルに基づいていて、choiceのsequenceはいわば最終形態なのである。

maxOccurs=“unbounded” であるchoiceのsequenceとなるパターンの場合、まずchoiceに含まれる先頭のelementから、QNameのマッチするものを探す（名前のマッチングについては後の説明も参照）。もし存在すれば、そのelementの定義が現在のXmlReader上のElementを許容するように拡張する（新しいものを定義することはできない; unique particle attribution違反）。もし存在しなければ、新しく追加する。

単純なsequenceの推測はより複雑だ。sequenceの内容は、順序通りに出現しなければならないので、「現在推測中のパーティクルの位置」も重要になる。また、補助的な引数として、「現在推測中のパーティクルは出現したか」を保持しておくことも必要になる（これを仮に「出現フラグ」と呼ぼう）。

まず、sequenceに含まれるelement（これ以外は許容されていないことに注意）の名前にマッチするものを、「先頭から現在推測中のパーティクルの位置マイナス1まで」探す（最初はこの探索が行われない）。もし同じQNameをもつ要素が出現してしまったら、この時点で、このsequenceは維持することができない3。なぜなら、XML Schema Structures 3.8.6の制限により、同じQNameをもつelementがあるモデルグループの子孫として含まれている場合、その型は同一でなければならない、という制約があり、同じQNameをもつelementについて、もし結果的に違うelementが推測されてしまったら、このモデルグループは不正なスキーマ コンポーネントになってしまうからだ（InferenceはXmlReaderベースで行われるので、バックトラッキングができないことも問題になる4）。

もしここまでで名前の一致するelementパーティクルが出現しなければ、「現在推測中のパーティクル」のQNameとelementを比較する。もし一致した場合、ここで「出現フラグ」がonになっていなかったら、「出現フラグ」をonにし、もしonになっていたら、maxOccursをunboundedにする。そして、その要素型が現在のXmlReader上のElementを許容するように拡張する。もしQNameが一致しなければ、ここで「出現フラグ」がonであれば、そのパーティクルは正常に推測されていたということなので、「出現フラグ」をoffにして、出現フラグがoffであれば、この最後のパーティクルは出現しなかったということになる。ここでの処理には2パターン考えられるが、おそらくMS.NETではminOccursを0にし、monoでは単純にsequenceとしてはもはや失敗したとみなしてchoiceに移行する。

elementパーティクルのマッチング

elementパーティクルを探索するとき、外部名前空間に属する要素はNameではなくRefNameを調べなければならないことに注意しなければならない。このことは、現在のモデルグループを含むcomplexTypeを含むXmlSchemaのTargetNamespaceが参照される、ということを意味している。

これがコンパイルされたXmlSchemaElementであれば、QualifiedNameプロパティを参照することができるが、推測中のパーティクルはコンパイルされていないので、QualifiedNameを使うことはできない。

Footnotes

  1. だったと思うけど、違うガイドラインだったかも。いずれにしてもdeveloperWorksに載っていた記事だったはず。 ↩

  2. たとえばxs:elementやxs:anyは内容グループではないので、xs:complexType/xs:element というパスはあり得ない。 ↩

  3. 本当は、続くパーティクルの出現を調べて、もし出現しなければ、以降のパーティクルのminOccursを0にすることで、sequenceを維持することはできる。MS.NETとmonoの実装の間で、ここに微妙な違いがあるように思えるが、具体的な境界条件は未調査だ。 ↩

  4. まあこれは実装の都合の問題ではあるけれど。 ↩

この記事を共有:
Hatenaで共有 Blueskyで共有 Mastodonで共有
前の記事
Xxxxed in Translation
次の記事
mono += mcs