XMLスキーマのバージョン管理のベストプラクティスは何ですか？
多くの場合、さまざまなXMLベースのインポートルーチンのXMLスキーマを設計する必要があります。 XMLスキーマは時間とともに進化するか、修正されるバグが含まれる可能性があることは明らかです。そのため、スキーマのバージョンをキャプチャし、特定のバージョンに対してバインドするメカニズムを用意することが重要です。
現在、2つのシナリオがあります。
バグはスキーマ内で見つかり、すべてのスキーマインスタンスは修正バージョンに準拠する必要があります。
アップグレードされたスキーマは望ましいものと見なされるべきですが、古いスキーマもサポートされる必要があります。
最後に、スキーマの名前空間内にバージョン情報を保存することを思いつきました。
targetNamespace="http://schemas.company.com/Geodesy/2010/River.xsd"
バグを修正するとき、同じネームスペースで修正しますが、スキーマをアップグレードしようとする場合、新しいネームスペースを作成する必要がありますが、アップグレード月を追加します。
targetNamespace="http://schemas.company.com/Geodesy/2010/01/River.xsd"
また、1か月に複数のアップグレードがある場合は、1日も追加します。
targetNamespace="http://schemas.company.com/Geodesy/2010/01/17/River.xsd"
より良いアプローチを知っていますか？
これは非常に難しいテーマであり、面白くさえありません。また、私は長年にわたってコンサルティングサポートを提供してきました。
多くの ベストプラクティス がありますが、それらのほとんどはすべての状況で機能するわけではありません。たとえば、多くの人は「xsd：any」を使用して拡張を許可することを提唱しています。これは、開発者がスキーマを維持し、それをダンプに変える場合の災害のレシピにすぎません。
開始する場合のヒントを次に示します。
- notマイナーバージョン番号、マイクロバージョン番号、日付、またはその他のものを名前空間に入れてください。名前空間を変更するたびに、すべての処理アプリケーションが中断されます。
- DoXMLインスタンスドキュメントに「バージョン」属性を設定します。これにより、処理中のアプリケーションまたはバージョンアダプターサービスが処理対象を把握できるようになります。
- Do後方互換性のある変更を構成するポリシーを指定します。たとえば、オプションの要素を追加しても送信者は中断せず、使用しても受信者は中断しません知らない要素を無視するポリシー（JAXBとXMLBeansはこのように構成できます）
運が悪い！
http://www.xml.com/pub/a/2004/07/21/design.html は優れたガイドラインを提供し、XML Schema 1.1は条件付きインクルードによる「バージョン管理」を可能にします（ http ：//www.w3.org/TR/xmlschema11-1/#cip ）。