さまざまな XML ベースのインポート ルーチン用に XML スキーマを設計しなければならないことがよくあります。XML スキーマは時間の経過とともに進化したり、修正すべきバグが含まれる可能性があることは明らかです。そのため、スキーマのバージョンを取得し、特定のバージョンにバインドするためのメカニズムを用意することが重要です。
現在、2 つのシナリオがあります。
バグはスキーマ内で発見され、すべてのスキーマ インスタンスは修正されたバージョンに準拠する必要があります。
スキーマはアップグレードされており、望ましいものと見なされるべきですが、古いものもサポートされる必要があります。
最終的に、スキーマの名前空間内にバージョン情報を保存する方法を思いつきました。
targetNamespace="http://schemas.company.com/Geodesy/2010/River.xsd"
バグを修正するときは同じ名前空間で修正しますが、スキーマをアップグレードする場合は、アップグレード月を追加した新しい名前空間を作成する必要があります。
targetNamespace="http://schemas.company.com/Geodesy/2010/01/River.xsd"
1 か月に複数のアップグレードがある場合は、日も追加します。
targetNamespace="http://schemas.company.com/Geodesy/2010/01/17/River.xsd"
もっと良い方法をご存知ですか?
ベストアンサー1
これは笑い事ではないほど難しいテーマであり、私が長年にわたりコンサルティングサポートを提供してきたテーマでもあります。
沢山ありますベストプラクティスいくつかありますが、そのほとんどはあらゆる状況で機能するわけではありません。たとえば、拡張機能を許可するには「xsd:any」の使用を推奨する人が多くいますが、開発者がスキーマの保守を担当し、スキーマをダンプに変えてしまうと、これは災難を招くだけです。
これから始める方のために、いくつかのヒントをご紹介します。
- するないマイナー バージョン番号、マイクロ バージョン番号、日付、またはその他類似のものを名前空間に入力します。名前空間を変更するたびに、すべての処理アプリケーションが壊れます。
- するXML インスタンス ドキュメントに「バージョン」属性を追加します。これにより、処理アプリケーションまたはバージョン アダプタ サービスが、何を処理しているかを把握できるようになります。
- する下位互換性のある変更を構成するポリシーを指定します。たとえば、オプションの要素を追加しても送信側は影響を受けません。また、不明な要素を無視するポリシーを使用している場合は、受信側も影響を受けません (JAXB と XMLBeans はこのように構成できます)。
幸運を祈ります！