私が解決しなければならない問題は次のとおりです。
XSD (または理想的には NVDL) スキーマを使用して「ほぼ検証」する XML ファイルが与えられた場合、プログラムでファイルを「修正」するにはどうすればよいですか?
(「ほとんど検証する」とは、一部の要素が持つことを許可されていない属性を持つことを意味します。他の検証エラーがないことが保証されます。「修正」とは、単に問題のある属性を削除することを意味します。)
Woodstox の検証ライターを使用してみましたが、何らかの理由で XSD を有効として受け入れませんでした (確かに、複数のインポートと抽象型ではかなり複雑ですが、有効です)。
代替手段は、出力を生成する XML 検証ライブラリです。このライブラリを解析/処理して、削除する必要がある属性を特定するために使用できます。
同じ最終製品を生成する他のアプローチも歓迎します。
「remove this attribute」タイプのコマンド オブジェクトで検出された「extra attribute」エラーをキャプチャするエラー ハンドラを使用して、XML を解析します。
次に、これらのオブジェクトを「SAX を読み取る」パーサーと「SAX を使用して書き込む」シンクの間に挿入するか、DOM ツリーを XML に書き換える前に DOM ツリーで実行するかは、実装の問題です。
エラー ハンドラーはエラーを処理する必要があり、エラーにするつもりがない場合は、エラー ハンドラーが解析を終了するべきではありません。これにより、ドキュメント内の属性の位置を取得するためのコードを作成するという犠牲を払ってのみ（そして後でそれを使用して何かを行う）、きめ細かい制御が可能になります。
The XML specによると、妥当性制約は、エラー ハンドラがゲームを停止しない限り、継続的な処理への扉を開く「エラー」にすぎません。これが回復不可能なエラーであってはならないことを示す詳細については、セクション 1.2 を参照してください。
属性を「強制」するだけの場合は、XSLT Identity 変換を使用して、不要な属性をフィルタリングするか、欠落している属性を追加できます。これは決して問題に対する広範な解決策ではありませんが、属性の問題に対する非常に優れた修正です。
ただし、属性の順序は XML の必須プロパティではないため、XSLT 変換後に属性の順序が変わる可能性があることに注意してください。
これは「他のアプローチ」への対応です。XSDを変更して、他の属性を受け入れるようにします。XSLTを使用したすべての配管は言うまでもなく、実行時のオーバーヘッドが少なくなります。
その音から、あなたはXSDを知っていて、どういうわけか理解/制御しています-あなたは「他の検証エラーを保証しない」と自信を持って言うように聞こえます...したがって、私の提案。
問題は、XSDが「外部」である場合にXSDを変更する方法である可能性があります。XSDが処理のためにどのように供給されるかについてさらに詳しく説明できる場合は、より良い提案が出てくるかもしれません...
たぶん、あなたはまだXSLTがXSDからXSDへの変換を行うことになります。XMLごとに1回ではなく、すべてのXMLに対して1回実行する必要があるため、パフォーマンス重視の環境ではさらに優れています。