私の目標は、いくつかの比較的複雑な DTD を解析して、要素の階層を明らかにすることです。DTD 間の唯一の違いはバージョンですが、各バージョンは下位互換性を維持しようとはしていません。そのため、各 DTD で定義される要素の構造を視覚化して、データを均一に格納するのに適したデータベース モデルを設計できるようにするつもりです。
私が Python で調査したほとんどのソリューションは外部 DTD に対してのみ検証されるため、最初から取り組みを開始することにしました。Pythonxml.parsers.expatは XML ファイルのみを解析し、非常に基本的な DTD コールバックを実装しているため、C で記述され、XML 1.0 仕様に完全に準拠していると主張する元のバージョンを確認することにしました。ただし、このアプローチについて次のような質問があります。
- expat (in C) は DTD ファイル内の外部エンティティ参照を解析し、それらの参照に従い、それらの要素を解析し、それらの要素を階層に追加しますか?
- expat は SGML を一般化して処理できますか? それとも、無効な DTD で有効な SGML ファイルに遭遇した後に失敗しますか?
私の要件は、expat が不適切であるという結論につながる可能性があります。その場合は、XML 1.0 DTD 用のレクサー/パーサーを作成することを検討しています。他に考慮すべきオプションはありますか？
以下は、私の意図をより簡潔に示しています。
入力 DTD の抜粋
<!--A concise summary of the disclosure.-->
<!ELEMENT abstract (doc-page+ | (abst-problem , abst-solution) | p+)>
DTD の抜粋から作成されたオブジェクト (疑似コード)
class abstract:
member doc_page_array[]
member abst_problem
member abst_solution
member paragraph_array[]
member description = "A concise summary of the disclosure."
難しい側面の 1 つは、<!ELEMENT>タグの上に表示されるコメントをタグに関連付けることです。したがって、expat を使用してこれを達成できない場合は、自家製のパーサーが必要になる場合があります。
もう 1 つの問題は、一部のパーサーが #xFFFF より大きい Unicode 文字を使用する DTD の処理に問題があることです。
lexer/parser ルートが私のタスクにより適していることが判明した場合、これらの EBNF 式を解析可能なものに変換する良い方法を知っている人はいますか? 「最良の」アプローチは、正規表現を使用することだと思います。
とにかく、これらは私の問題に関して私が持っていた考えです。上記の質問に対する回答または代替アプローチに関する提案をいただければ幸いです。