2006/03/03 10:32 |
From:"MURATA Makoto (FAMILY Given)" <eb2m-mrt@asahi-net.or.jp> [relax-std-j 00157] 徐々に注目されつつあるNVDL |
複数名前空間をもつXML文書を検証したいという要求が徐々に高まりつつあり、 それにつれてNVDLが注目されつつあります。たとえば、UBLの委員会です。 http://lists.oasis-open.org/archives/ubl/200602/msg00117.html 規格はほとんど仕上がりました。FDISが、以下のページにあります。 http://www.jtc1sc34.org/repository/0694c.htm 残念ながら、日本語に翻訳するときにいっぱい編集上の誤りを見つけて しまいました。それに対応する修正がここにあります。 http://www.jtc1sc34.org/repository/0717.htm -- 国際大学 村田 真 <EB2M-MRT@asahi-net.or.jp>
2005/12/23 13:57 |
From:Atsushi Eno <atsushi@ximian.com> [relax-std-j 00156] Re: NVDLのFinal Draft International Standard |
参照先: [relax-std-j 00155] NVDLのFinal Draft International Standard ("MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp>)
2005-12-23 (金) の 10:31 +0900 に MURATA Makoto (FAMILY Given) さんは書 きました: > やっと出しました。 > > http://www.jtc1sc34.org/repository/0694c.htm > > > FCDとくらべて技術的に変わっているのは、以下の三点です。 > > 1) wildcard -> wildCard > > 2) attachPlaceHolder -> attachPlaceHolder > > 3) trigger要素を拡張して、XHTML + XForms in a single > namespaceに対応できるようにした。詳細は、 > > http://lists.dsdl.org/dsdl-discuss/2005-11/0007.html > http://lists.dsdl.org/dsdl-discuss/2005-11/0022.html > > にあります。 triggerのname属性はnameList属性に変わったようですね。 とりあえずMonoの実装には全て反映させておきました。(動作は未確認ですが) ふと思ったのですが、世の中に転がっているNRLのスクリプトは NVDLのテスト用にそのまま流用できるかもしれませんね。 Atsushi Eno
2005/12/23 10:31 |
From:"MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp> [relax-std-j 00155] NVDLのFinal Draft International Standard |
やっと出しました。 http://www.jtc1sc34.org/repository/0694c.htm FCDとくらべて技術的に変わっているのは、以下の三点です。 1) wildcard -> wildCard 2) attachPlaceHolder -> attachPlaceHolder 3) trigger要素を拡張して、XHTML + XForms in a single namespaceに対応できるようにした。詳細は、 http://lists.dsdl.org/dsdl-discuss/2005-11/0007.html http://lists.dsdl.org/dsdl-discuss/2005-11/0022.html にあります。 他の修正は、すべてeditorialです。例えば、URIではなくIRIと いう語を用いるようにし、namespace URIはnamespace nameに直 しました。schema属性に現れるnon-ASCII characterを%HHでエス ケープするのは、本当に必要なときに限って行なうのでしょうね。 -- 国際大学 村田 真 <EB2M-MRT@asahi-net.or.jp>
2005/03/12 17:46 |
From:Atsushi Eno <atsushi@ximian.com> [relax-std-j 00154] NvdlValidatingReader |
えのもとです。 NVDLの実装ですが、何とか動いているようなものが出来たのでご報告します。 実装はC#/Monoベースで作成しています。 Microsoft.NETでも動くかもしれませんが、全く確認していません。 http://monkey.workarea.jp/tmp/20050312/Commons.Xml.Relaxng.dll ええと、↑は生のアセンブリです。すみません。 ドキュメントは今のところmono用に英語で書いたものと: http://svn.myrealbox.com/source/trunk/mcs/class/Commons.Xml.Relaxng/README まだ書きかけのメモしかありません(ユーザー向けではない感じですが…) http://monkey.workarea.jp/tmp/20050307/nvdl-introduction-ja.html ソースコードはMonoのSVNリポジトリ上で公開されています。 http://svn.myrealbox.com/source/trunk/mcs/class/Commons.Xml.Relaxng/ (最初にRELAX NG実装を作ったので、アセンブリ名がRELAX NGなんですが、 このアセンブリ名を変更する/できる予定はありません。) 内容は空白ですが、ndocで生成したAPIリファレンスもあります。 (内容は今後mono用にmonodocというツールで書く予定です) http://monkey.workarea.jp/tmp/20050307/api/ thaiopensource.comとsf.netのXForms ValidatorとW3C石川さんのところに あった文法定義をいくつか拝借して、NVDL仕様に載っているサンプルを 動かすところまではやってみました。 http://monkey.workarea.jp/tmp/20050312/nvdltests.zip Atsushi Eno
2005/02/06 08:39 |
From:"MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp> [relax-std-j 00153] Re: schemaType in nvdl.nvdl |
参照先: [relax-std-j 00152] schemaType in nvdl.nvdl (Atsushi Eno <atsushi@ximian.com>)
> http://www.asahi-net.or.jp/~eb2m-mrt/dsdl/fcd/nvdl.nvdl > > この中に以下のようなvalidate要素の定義があるのですが、 > > <validate schema="nvdl.rng"> > > このnvdl scriptでは、schemaType属性が無く、validate要素にもトップの > rules要素にも無く、そしてvalidate要素にはschema要素も出現しません。 > この場合については、どのような検証が定義されているのでしょうか? ご指摘有難うございます.8.7.2 Determining schemas and schema languages の記述に抜けがありました。media typeがない場合も、schemaTypeがなければ、 XMLであるとみなしてparseし、ルートの名前空間からスキーマを決めます. FCD投票のときに、日本コメントで修正しておきます. ムラタ -- MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>
2005/02/06 07:42 |
From:Atsushi Eno <atsushi@ximian.com> [relax-std-j 00152] schemaType in nvdl.nvdl |
えのもとです。こんにちは。 今回はnvdl.nvdlについて質問させて下さい。 http://www.asahi-net.or.jp/~eb2m-mrt/dsdl/fcd/nvdl.nvdl この中に以下のようなvalidate要素の定義があるのですが、 <validate schema="nvdl.rng"> このnvdl scriptでは、schemaType属性が無く、validate要素にもトップの rules要素にも無く、そしてvalidate要素にはschema要素も出現しません。 この場合については、どのような検証が定義されているのでしょうか? ええと、もう少し質問を正確に書きます。ここで想定されているのは http://purl.oclc.org/dsdl/nvdl/ns/predefinedSchema/1.0 だろうと 思うのですが、それで合っていますでしょうか? Atsushi Eno
2005/01/30 11:31 |
From:"MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp> [relax-std-j 00151] Re: NVDL FCD日本語訳(一部) |
参照先: [relax-std-j 00149] NVDL FCD日本語訳(一部) (Atsushi Eno <atsushi@ximian.com>)
> > 結局、NVDLの仕様を理解できていない部分が多くて気になったので、 > 部分的に翻訳してしまいました。せっかくなのでここに置いておきます。 > http://monkey.workarea.jp/tmp/nvdl-fcd-ja.html 有難うございます。JISにしようという話もありますので、 そのときにも役立ちます。 ムラタ -- MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>
2005/01/30 11:18 |
From:"MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp> [relax-std-j 00150] Re: new to the list / (NVDL) PlanElemについて |
参照先: [relax-std-j 00148] Re: new to the list / (NVDL) PlanElemについて (Atsushi Eno <atsushi@ximian.com>)
> > 実際に、どう検証すべきかは、すべてのinterpretationを考慮しない > > と決定できません。 > > そうですね。よく考えてみたらこの辺は悩みどころです。普通は途中で > 検証器が増製できることはないですので… 実装するときは、各sectionごとにいくつかのmodeをスタックに積みます。 もちろん、sectionから抜けるときには、スタックから取り除きます。 attachまたはunwrapアクションを持つmodeについては、親sectionのmodeに リンクを張ります(正確に言うと、親sectionのすべてのmodeではなく、 現在のmodeに遷移するactionを持っているものだけです)。 あるsectionに属する要素を処理している間は、現在のmodeのactionの うち、validateなものすべてにdispatchします。現在のmodeのactionに attachがあれば、リンクをたどって親modeのvalidateにdispatchします。 このとき、親modeがunwrapをもてば、さらに祖先のmodeまで見に行きます。 -- MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>
2005/01/30 04:47 |
From:Atsushi Eno <atsushi@ximian.com> [relax-std-j 00149] NVDL FCD日本語訳(一部) |
えのもとです。 結局、NVDLの仕様を理解できていない部分が多くて気になったので、 部分的に翻訳してしまいました。せっかくなのでここに置いておきます。 http://monkey.workarea.jp/tmp/nvdl-fcd-ja.html # 翻訳してみたはいいけどきちんと理解できているかはかなり微妙です.. Atsushi Eno
2005/01/30 04:36 |
From:Atsushi Eno <atsushi@ximian.com> [relax-std-j 00148] Re: new to the list / (NVDL) PlanElemについて |
参照先: [relax-std-j 00147] Re: new to the list / (NVDL) PlanElemについて ("MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp>)
えのもとです。 村田さん、ありがとうございます。 > このような選択をする機会は、文書全体を通して何度もあります。 > 「ここでアクション1を選び、あそこでアクション2を選び、.... > 最後にアクションmを選ぶ」という一連の選択結果をinterpretationと > して導入します。interpretationは、もちろんいくつも存在する > ことになります。 > > 実際に、どう検証すべきかは、すべてのinterpretationを考慮しない > と決定できません。 そうですね。よく考えてみたらこの辺は悩みどころです。普通は途中で 検証器が増製できることはないですので… > syn[I]は、解釈Iのもとでattarchやunwrapを実行して得られる要素を > 表します。 あ、なるほど。8.3を読み直すと、確かに要素を表していますね。 ... we introduce a partial function syn[I] that maps an element section s in the given instance to an element ... # <i>I</i>が/に見えたというのは秘密です… > validationは、一つのsectionに対して行われるとは限りません。 > sectionへのattachが繰り返されれば、どんな複雑な要素も > validationの対象になります。 はい、この辺りはすっきりしたように思います。 Atsushi Eno