3

これまで、次の例に示すように、「name」属性と「value」属性を持つプレースホルダー要素を定義することで拡張機能を処理してきました。

<root>
   <typed-content>
      ...
   </typed-content>
   <extension name="var1" value="val1"/>
   <extension name="var2" value="val2"/>
....
</root>

現在、 xsd：anyの使用に切り替えることを計画しています。最善のアプローチを選択するのを手伝っていただければ幸いです

  1. processContents = "strict"を指定した場合、xsd：anyの以前のアプローチに対する付加価値は何ですか。
  2. EAI / ESBツール/ライブラリは、返された任意の要素に対してXPATH式を実行できますか？
  3. バインディングコードを生成する際に、これを個別に処理するさまざまなバインディングツールが表示されます。これは、namespace = "http：// mynamespace"を含め、コード生成時に "http：// mynamespace"のスキーマを提供する場合と同じケースですか？
  4. これはWS-Iに準拠していますか？
  5. 私が見逃している落とし穴はありますか？

ありがとうございました

4

2 に答える 2

2
  1. を使用すると、元のスキーマを変更せず<xsd:any processContents="strict">にXMLインスタンスドキュメントに拡張機能を追加できるようになります。これは、それがもたらす重要なメリットです。
  2. はい。インスタンスを操作するよりもツールは、スキーマがどのように見えるかを気にせず、それはそれらが見るインスタンスドキュメントです。彼らにとって、あなたが使うかどうかは本当に問題ではありませ<xsd:any>ん。
  3. バインディングツールは、一般的<xsd:any>にあまりエレガントに処理されません。何が含まれるかについての情報がないため、これは理解できます。したがって、通常、型指定されていないプレースホルダーが提供されます。実行時にそれを処理するのはアプリケーションコード次第です。JAXBは特別です（少なくともRIは）それを少しこぶしにしますが、それは実行可能です。
  4. はい。これは完全に優れたXMLスキーマの実践であり、すべての有効なXMLスキーマはWS-Iによってサポートされています。
  5. <xsd:any>バインディングの型指定されていない性質のために、プログラマーの生活は少し難しくなりますが、任意の拡張ポイントをサポートする必要がある場合は、これがその方法です。ただし、拡張機能が明確に定義されていて、変更されていない場合は、刺激要因の価値がない可能性があります。
于 2011-02-03T19:50:50.443 に答える
1

ポイント3について

バインディングツールは、一般的にあまりエレガントに処理されません。何が含まれるかについての情報がないため、これは理解できます。したがって、通常、型指定されていないプレースホルダーが提供されます。実行時にそれを処理するのはアプリケーションコード次第です。JAXBは特別です（少なくともRIは）それを少しこぶしにしますが、それは実行可能です。

これは、JAXBの@XmlAnyElementアノテーションに対応します。動作は次のとおりです。

@XmlAnyElement-すべてをDOMノードとして保持

プロパティにこの注釈を付けると、XMLドキュメントの対応する部分がDOMノードとして保持されます。

@XMLAnyElement（lax = true）-既知の要素をドメインオブジェクトに変換する

lax = trueを設定することにより、JAXBがそのQNameに対応するルートタイプを持っている場合、そのチャンクをドメインオブジェクトに変換します。

于 2011-02-03T21:36:42.150 に答える