2

javax.xml.*大きなXMLファイルを丸呑みし、カスタムDTDに対して検証しようとするボグ標準のパーサーがあります。DTDはローカルに保存されており、数年前からこの投稿のようなトランスフォーマーを使用して検証しています。

そのすべてが機能します。私たちが今目にしている問題は、このタイプのファイルのXML形式が悪魔によって書かれていることです。冗談じゃないよ; 仕様は750ページを超え、「愛、悪魔」と署名されています。

具体的には、XMLの一部は次のようになります。

<KnownTag>
    <ArbitraryTag> ... text ... </ArbitraryTag>
    <Whatever>     ... text ... </Whatever>
    <fj9e8jer23tj> ... text ... </fj9e8jer23tj>
    ....
</KnownTag>

内部タグはバランスが取れており、生の構文はこの時点で整形式のXMLであることがわかっていますが、要素名自体は完全に任意であり、予測できません。（はい、それはその悪です。この仕様を最初に公開した会社は、製品の信頼性が低いことで悪名高いため、長い間廃業してきました。図を見てください。）

カスタムDTDで指定できます<!ELEMENT KnownTag ANY>が、コンテンツに適合しています。明らかに、検証パーサーは、最初のユーザー指定の要素名に達するとすぐにエラーを出します（要素タイプ "ArbitraryTag"を宣言する必要があります）。明らかに、純粋な解析コンテキストからそのブロック内の何かを本当に「検証」することはできません。XMLのそのセクションだけのエラーを抑制する方法を見つけたいと思っています。

  • パーサーのエラーハンドラーインターフェイスであるErrorHandlerは、3つのコールバックを指定します。この場合はerror()と呼ばれます。ブロック内にあるということで渡された実際の例外から理解できればKnownTag、エラーを安全に無視して続行できます。これは、Java SEの実装で安全に実行できますか？

  • XMLパーサー自体がこの時点ですでにDOMドキュメントを作成しているため、後で任意の要素にアクセスすることは問題にはなりません。

  • APIは、解析の途中で切り替えることを許可しjavax.xml.parsers.DocumentBuilder[Factory]てjavax.xml.transform.Transformerいないようです。DocumentBuilderFactory#setValidating()もしそうなら、それは驚くべきことではありませんが、私はちょうど何かを逃したことを望んでいます。誰？

4

1 に答える 1

1

DTDには、整形式XMLの特定のサブツリーでの検証をスキップするメカニズムがありません。これは、DTDと、XSDやRelax NGなどの後のスキーマ言語との違いの1つです。ワイルドカードを導入すると、「KnownTag要素には任意のXMLを含めることができます」（または、特定の名前空間にない任意の要素、または名前空間の特定のセットの、または...）。

パーサーに特定のサブツリーでエラー報告をオフにする機能があるかどうかは、完全にパーサー固有です。多くのJavaベースのXMLパーサーのどれを使用しているかを説明する必要があります。チャンスはわずかです。パーサーがそのような機能を持つことは不可能ではありませんが、最初の説明では、仕様に準拠した動作のようには聞こえません。（これは、DTDベースのバリデーターが持っていると聞いたことのある機能でもありませんが、実際にはあまり証明されていません。）

于 2013-01-03T16:48:16.110 に答える