Разбор DTD для выявления иерархии элементов

Question

Моя цель - проанализировать несколько относительно сложных DTD, чтобы выявить иерархию элементов. Единственное различие между DTD - это версия, но каждая версия не делала попыток оставаться обратно совместимыми - это было бы слишком просто! Таким образом, я намереваюсь визуализировать структуру элементов, определенных каждым DTD, чтобы я мог спроектировать модель базы данных, подходящую для равномерного хранения данных.

Поскольку большинство решений, которые я исследовал в Python, будут проверяться только на наличие внешних DTD, я решил начать свои усилия с самого начала. Питона xml.parsers.expatанализирует только XML-файлы и реализует очень простые обратные вызовы DTD, поэтому я решил проверить оригинальную версию, написанную на C, и заявляет, что полностью совместим со спецификациями XML 1.0. Однако у меня есть следующие вопросы об этом подходе:

1. Будет ли expat (в C) анализировать ссылки на внешние объекты в файле DTD и следовать этим ссылкам, анализировать их элементы и добавлять эти элементы в иерархию?
2. Может ли expat обобщать и обрабатывать SGML, или он потерпит неудачу после обнаружения недопустимого DTD, но все же действительного файла SGML?

Мои требования могут привести к выводу, что экспат не подходит. Если это так, я подумываю написать лексер / парсер для DTD XML 1.0. Есть ли другие варианты, которые я должен рассмотреть?

Следующее более кратко иллюстрирует мое намерение:

Отрывок ввода 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."

Одним из сложных аспектов является приписывание <!ELEMENT> пометьте комментарий над ним. Следовательно, доморощенный парсер может быть необходим, если я не могу использовать expat для этого.

Другая проблема заключается в том, что некоторые анализаторы имеют проблемы с обработкой DTD, которые используют символы Юникода больше, чем #xFFFF, так что это может быть еще одним фактором, способствующим созданию моего собственного.

Если окажется, что маршрут лексера / парсера лучше подходит для моей задачи, знает ли кто-нибудь о хорошем способе преобразования этих выражений EBNF во что-то, что может быть проанализировано? Я полагаю, что "лучшим" подходом может быть использование регулярных выражений.

Во всяком случае, это только те мысли, которые у меня были по поводу моей проблемы. Будем благодарны за любые ответы на вышеуказанные вопросы или предложения по альтернативным подходам.

Answer 1

Существует несколько существующих инструментов, которые могут соответствовать вашим потребностям, включая DTDParse, OpenSP, Matra и DTD Parser. Также есть статьи по созданию пользовательского парсера.