4

このチュートリアルに従って、733 行のスキーマを 16 個の個別のファイルまたはサブスキーマにリファクタリングし、それぞれが独自の名前空間を持ちます。現在、最上位のスキーマはわずか 77 行です。これらのサブスキーマを使用して、他のトップレベルのスキーマを構築する計画です。

問題は、ほとんどの最上位スキーマが非常に似ており、いくつかの下位レベルの詳細のみが異なることです。たとえば、ある最上位スキーマはすべてPaymentMethodTypeの をサポートしていますが (チュートリアルを参照)、別の最上位スキーマは VISA と MasterCard のみをサポートしている場合があります。現在、トップレベルのスキーマを作成する私の方法には、かなりの重複が含まれています。たとえば、VISA と MasterCard のみがサポートされる最上位のスキーマを作成する現在の方法では、 と を複製Main.xsdしOrderType.xsd、 をカスタマイズCommonTypes.xsdして再利用しCustomerTypes.xsdます。(私の実際のスキーマははるかに長いため、より多くの重複が含まれます。)

この重複は、主にメンテナンスの課題が発生するため、受け入れられません。つまり、異なる名前を持つ同一のサブスキーマをいくつでも維持する必要があります。

私が知りたいのは、サブスキーマの重複を避けるために、何らかの構成ファイル (XSLT など) を使用せずにスキーマを自動的に生成する方法があるかどうかです。

また、この場合、すべてのサブスキーマで同じターゲット名前空間を宣言することをお勧めします (xml スキーマの名前空間xsと同様ですが、カスタム サブスキーマで別の名前空間を宣言しますか?

4

2 に答える 2

0

なぜあなたは複製Main.xsdしOrderType.xsdて、あなたのようにそれらを再利用するのではなくCustomerTypes.xsd? それらが文字通り同一である場合（「重複」が意味するように）、それらをインポートしないのはなぜですか？質問から何かを省略している可能性があると思います...

また、「via なしでスキーマを生成する」という言葉が欠けているようです。

  1. サブスキーマごとに異なる名前空間を持つことは機能します。別のアプローチは「カメレオン スキーマ」です。これは、サブスキーマ自体が名前空間を持たない場所ですが、トップレベル スキーマの名前空間を引き継ぎます。マルチスキーマ プロジェクト: 0、1、または多数の名前空間? . ただし、この手法は少しトリッキーであり、すべてのツールがこの手法をサポートしているわけではないため、回避することを推奨する人もいます。しかし、あなたの場合、おそらくそれは価値があります.確かに、これらのリンクを読むことで、あなたの状況に対処する方法についてのアイデアが得られます.

  2. 別のスキーマの特定の部分を再定義できます (そのスキーマの残りの部分は変更されません)。定義の下の例を見てください。これはまさにあなたの問題の解決策のようです。再定義された部分は、スキーマの他の部分 (または他のインポートされたスキーマ) によって使用される低レベルにすることができます。ただし、上記の (1) と同様に、これは仕様のトリッキーな部分であり、一部のツールではサポートされていない可能性があります。

だから...あなたのツールが仕様のこれらの機能を実装することを願っています（そしてそれらを使用する必要がある他の人のツール）。上記のリンクの例でテストできます (xmllint で動作することを確認しました)。

そうでない場合は、XSLT (または他の XML/テキスト処理ツール) を使用してサブスキーマを組み立てるというアイデアが機能します。XSLT に関する特定のヘルプが必要な場合は、最初に使用したスキーマのサンプルと、必要な結果のスキーマを含めることをお勧めします。

于 2012-11-23T09:05:41.807 に答える
-1

XSLT ベースのアプローチについて説明するつもりはありません。なぜなら、私は良いアプローチを知らないからです。

私は 2004 年に試しました。私は XML スキーマ リファクタリングに使用する言語として XSLT を放棄しました。スキーマ オブジェクト モデル API (SOM/XSOM) (特に XSD の分析と作成用に設計された API) の方が、XSD をはるかに生産的に使用できるという意見があるからです。時間 (これを読んでいる XSLT 評論家のために、私は自分の声明を修飾しました)。

必要なものが実際には単純であるという可能性は常にあります。そのため、独自の XSLT またはその他の方法で (経済的または知的に) 実行可能です。問題のより具体的なパラメーターを共有すると、より良い回答が得られる場合があります。それでも、これを専門的に行うことを考えている場合、つまり、入力と出力の XSD がどのように見えるかについて最小限の仮定を置いて考えている場合は、少し手間がかかります。

私が最終的に行ったのは、XML スキーマ リファクタリング用のドメイン固有言語を設計することでした。QTAssistant XSR モジュールの一部として利用できます。グラフィカルに、これは QTAssistant で「733 行のスキーマを 16 の個別のファイルまたはサブスキーマに分割」したものです。

ここに画像の説明を入力

そのリファクタリング機能により、単一のソース セットから説明した多くのことが可能になります。必要な機能を備えた「ビュー」を構成するだけです (たとえば、どの XSD ファイルに何を入れるか、必要な依存関係を自動的に取り込む、ターゲット名前空間を変更する、型の名前をリファクタリングする、要素、基本型を置き換える、不要なパーティクルを削除する、など)。カーディナリティを変更するためにシーケンス ラッパーを導入するなど) ボタンを押すだけで、有効な XSD ファイルが保証されます。また、自動ビルド システムと統合するためのコマンド ライン インターフェイスも付属しています。

どちらかといえば、XSLT テンプレートがどのように設計されるかについてインスピレーションを得るためだけであれば、.NET のSchemaパッケージなどの API を検討することを検討します...

于 2012-11-22T16:22:34.153 に答える