Проблемы определений DTD
У определений DTD имеется ряд недостатков, которые выявляются при углубленной работе с XML:
- Их сложно писать и понимать.
Синтаксис определений DTD отличается от языка XML. Он является расширенной формой Бэкуса-Науэра (Extended Backus Naur Form, EBNF), и многие находят его трудным для чтения и использования. Предлагаемые схемы XML фактически, используют язык XML для описания определяемых ими языков, что устраняет необходимость изучения языка EBNF для их чтения и записи.
- Программная обработка их метаданных затруднена.
Использование языка EBNF, кроме того, затрудняет автоматизированную обработку метаданных в определениях DTD. Разумеется, для DTD существуют специальные анализаторы. Он должен загрузить и прочитать DTD, после чего сможет проверить соответствующий документ на допустимость. К сожалению, не предусмотрена возможность обратиться к DTD из программы, использующей модель DOM. Объектная модель не позволяет получить доступ к метаданным словаря, написанным на языке EBNF. Анализатор прочитает DTD и сохранит его информацию для себя. Безусловно, было бы удобно, если бы DTD было написано на языке XML, так что мы могли бы исследовать их так же легко, как мы исследуем документы, написанные в соответствии с содержащимися в них правилами. Такая возможность позволила бы при помощи DOM изучить структуру обнаруженных нами словарей и даже модифицировать их правила проверки допустимости в соответствии с теми или иными условиями программы.
- Они не являются расширяемыми и не поддерживают пространства имен.
Определения DTD представляют собой фиксированную сущность. В них должны существовать все правила словаря. Все, что вам может понадобиться, вы размещаете в вашем словаре. Не создавая внешних объектов, вы не сможете использовать имена из других источников.
Создание и обслуживание ваших собственных подмножеств деклараций разметки станет значительно более удобным в результате использовании ссылки на существующее определение. Вы не можете позволить авторам документа включать в него что-нибудь интересное впоследствии, если соответствующее определение отсутствует в DTD.
Конечно, не всегда надо предоставлять авторам документов такую свободу, но было бы хорошо использовать части существующей схемы при проектировании нового словаря.
Поскольку все правила словаря должны находиться в DTD, вы не можете смешивать пространства имен. Хотя при помощи пространства имен можно ввести в документ тип элемента, нельзя ссылаться на декларацию элемента в DTD. При его использовании все его элементы должны быть объявлены в DTD.
- Они не поддерживают типов данных.
Одним из существенных преимуществ языка XML является то, что все документы полностью пишутся при помощи общего типа данных - текста. Задачи программирования, однако, требуют использовать и другие типы. Определения DTD предлагают не много других типов данных, что является серьезным недостатком, когда XML применяют в приложениях определенного типа
- Они не поддерживают наследование.
Итак, определения DTD прекрасно позволяют определять структуры документов. Если учесть, что язык XML произошел от SGML, который также использует DTD, можно легко понять выбор этих определений в спецификации XML 1.0. Однако при использовании XML не только для разметки текста, но и в ситуациях, требующих программирования, описанные ранее ограничения становятся чрезвычайно важными.