0

key（）関数を使用してメタデータを取り込むスタイルシートがあるとします。つまり、次のようなインスタンスドキュメントがあります。

<items>

<item type="some_type"/>

<item type="another_type"/>

</items>

処理中にアイテムに関連付けたい追加データのテーブル：

<item-meta>

<item type="some_type" meta="foo"/>

<item type="another_type" meta="bar"/>

<item type="yet_another_type" meta="baz"/>

</item-meta>

最後に、インスタンスドキュメントでスキーマ検証を実行し、型属性をitem-metaで発生する型のセットに制限するとします。したがって、スキーマでは、制限/列挙の代わりにkey/keyrefを使用します。これは、制限/列挙を使用するには、有効な型属性の個別のリストを作成する必要があるためです。

ただし、key/keyrefが実際に機能するようには見えません。（MSXML 6.0で）試してみると、スキーマキーのセレクターはxpath引数でdocument（）関数を受け入れないようです。そのため、外部ファイルに表示されているか、外部ファイルに表示されているかにかかわらず、item-metaデータを調べることはできません。スキーマファイル自体にあります。キーを探すことができるのはインスタンスドキュメントだけのようです。

したがって、有効なタイプの個別のリストが本当に必要ない場合は、事前検証変換を実行し、item-metaのものを取得してから、検証を実行してから、元の変換を実行する必要があります。これは、XMLスキーマとスタイルシートを比較的簡単に使用する必要があるため、複雑すぎるように思われます。

もっと良い方法はありますか？

4

3 に答える 3

1

key/keyref のセレクターは、非常に制限された xpath 構文のみを許可します。短いが、完全に正確ではない: セレクターは、宣言された要素のサブノードを指している必要があります。

制限された構文の完全な定義は-> hereです。

だから、いいえ、申し訳ありませんが、より良い方法はありません。

ところで: W3C は、この制限は XML スキーマ プロセッサの実装者の負担を軽減するために設けられたと述べています。XML スキーマの設計目標の 1 つは、ストリーミング モードでドキュメントを処理できるようにすることでした。これは、XML スキーマのランダムに見える制限の多くを説明しています。

于 2008-09-22T20:30:25.153 に答える
0

いくつかのエラーでXSLTを停止する必要はありません。スキーマが検証せず、次のような元の問題を指し示すものを生成するようにします。

 <error txt="Invalid-Item-Type 'invalid_type'"/>

それとは別に、ここにはディスカッションスレッドがないことに注意してください。投稿は上下する可能性があるため、それに応じて質問を編集することをお勧めします。

ここでの哲学は「1つの質問であり、最良の答えが勝つ」ということを忘れないでください。

于 2008-09-22T21:54:01.877 に答える
0

もう少し考えた結果、スタイルシートに検証のその部分を行わせるというアイデアを思いつきました。スキーマはアイテム タイプをプレーンな文字列として定義し、アイテム メタ テーブルでアイテム タイプを検索できない場合、スタイルシートはメッセージを出力して処理を停止します。

この解決策は、有効な型のリストを複数回書き留めなければならないという元の問題を修正しますが、検証ロジックがスタイルシート ロジックと混在するという問題が発生します。この新しい問題が古い問題ほど深刻ではないかどうかを判断するには、XSD+XSLT に関する十分な経験がありませんが、item-meta テーブルをインスタンス ドキュメント内の各インスタンス ドキュメントにプルすることについて以前に書いたものよりも洗練されているようです。事前検証変換。

于 2008-09-22T21:41:30.270 に答える