DTD

DTD расшифровывается как Document Type Definition. В IT-глоссарии этот термин чаще всего встречается рядом с XML, интеграциями, обменом данными и старыми корпоративными системами. Простыми словами, DTD задает правила, по которым можно понять, правильно ли устроен XML-документ: какие теги в нем разрешены, в каком порядке они могут идти, какие атрибуты допустимы и какие части документа обязательны.

Если XML представить как документ с данными, то DTD будет похож на инструкцию для проверки формы. Например, в заказе должны быть номер, дата, клиент и список товаров. У товара должны быть название, количество и цена. Если система получает XML без номера заказа или с неправильным названием тега, DTD помогает обнаружить ошибку до того, как данные попадут в учетную систему, CRM, ERP или сервис аналитики.

Что такое DTD простыми словами

DTD — это формальное описание структуры XML-документа. Оно не хранит сами бизнес-данные, а описывает, как эти данные должны быть организованы. Такой подход нужен, когда разные приложения обмениваются XML-файлами и должны одинаково понимать их формат.

Например, компания передает партнеру XML с прайс-листом. В одном файле цена может называться price, в другом cost, в третьем сумма может быть вложена в другой раздел. Без общего правила системы начинают ошибаться, а разработчикам приходится писать дополнительные проверки. DTD фиксирует ожидаемую структуру и делает обмен более предсказуемым.

DTD отвечает на вопрос: соответствует ли XML заранее описанному формату.

Зачем DTD нужен бизнесу

Для бизнеса DTD важен не сам по себе, а как инструмент снижения ошибок при обмене данными. В проектах интеграции часто участвуют разные системы: сайт, склад, биллинг, электронный документооборот, каталог товаров, платежный шлюз, сервис доставки. Если каждая система трактует XML по-своему, появляются сбои, ручные исправления и задержки.

DTD помогает договориться о формате обмена. Его можно приложить к техническому заданию, использовать в тестировании, встроить в процесс приема файлов или применить при миграции данных. Это особенно полезно там, где XML уже давно используется и менять формат дорого: в банковских шлюзах, издательских системах, телеком-платформах, государственных и отраслевых интеграциях.

Как работает DTD

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

DTD может быть размещен внутри XML-документа или подключаться как внешний файл. Внутренний вариант удобен для небольших примеров и автономных документов. Внешний вариант практичнее в компаниях: одну схему можно хранить отдельно и использовать для множества XML-файлов.

Пример простого XML и DTD

<!DOCTYPE order [
<!ELEMENT order (number, customer, items)>
<!ELEMENT number (#PCDATA)>
<!ELEMENT customer (#PCDATA)>
<!ELEMENT items (item+)>
<!ELEMENT item (name, quantity)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT quantity (#PCDATA)>
]>


<order>
<number>A-1024</number>
<customer>Company One</customer>
<items>
<item>
<name>Keyboard</name>
<quantity>10</quantity>
</item>
</items>
</order>

В этом примере DTD говорит, что корневой элемент order должен содержать number, customer и items. Раздел items должен содержать один или несколько элементов item. Каждый item включает name и quantity. Если в XML будет отсутствовать customer или порядок элементов нарушится, документ не пройдет проверку.

Основные элементы DTD

DTD состоит из деклараций. Каждая декларация описывает отдельную часть XML-документа. На практике чаще всего используются правила для элементов, атрибутов, текстового содержимого и сущностей.

Элементы

Элементы описывают, какие теги могут быть в XML. Например, заказ может включать номер, клиента и позиции. DTD позволяет задать обязательность и порядок этих тегов. Это удобно, когда получатель данных не должен угадывать, что именно ему прислали.

Атрибуты

Атрибуты добавляют к элементам дополнительные свойства. Например, у товара может быть код, у клиента — идентификатор, у валюты — буквенное обозначение. DTD может указать, является ли атрибут обязательным, какие значения он может принимать и какое значение использовать по умолчанию.

<!ELEMENT product (name, price)>
<!ATTLIST product id ID #REQUIRED>
<!ATTLIST product status (active|archived) 'active'>

Здесь у product есть обязательный атрибут id и атрибут status, который может принимать только active или archived. Если status не указан, используется значение active.

Внутренний и внешний DTD

DTD может быть внутренним или внешним. Внутренний DTD находится прямо в XML-файле. Это удобно для учебных примеров, небольших документов и ситуаций, когда файл должен быть полностью самодостаточным. Но в крупных проектах такой подход неудобен: при изменении правил приходится обновлять много файлов.

Внешний DTD хранится отдельно, обычно в файле с расширением dtd. XML-документы подключают его по ссылке. Это позволяет централизованно поддерживать формат и использовать один набор правил во множестве обменов.

Где DTD применяется на практике

DTD чаще встречается в проектах, где XML используется давно или где формат обмена был задан исторически. Новые проекты нередко выбирают XML Schema, JSON Schema или OpenAPI, но DTD все еще остается важным для поддержки существующих систем.

• Интеграция между корпоративными системами, где XML передается между ERP, CRM, складом и биллингом.
• Проверка файлов перед загрузкой в учетную систему или базу данных.
• Обмен каталогами товаров, заказами, отчетами и справочниками.
• Издательские процессы, где XML описывает структуру документов, статей или технической документации.
• Поддержка старых протоколов и отраслевых форматов, которые уже завязаны на DTD.

DTD в интеграционных проектах

В интеграционном проекте DTD может быть частью контракта между системами. Команда, которая отдает данные, обязуется формировать XML по правилам. Команда, которая принимает данные, использует DTD для автоматической проверки. Если файл не соответствует формату, его можно отклонить с понятным сообщением об ошибке.

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

Плюсы DTD

Главное преимущество DTD — простота. Его легче прочитать, чем более сложные схемы. Для базовой проверки структуры XML часто достаточно нескольких деклараций. Это удобно в проектах, где важны совместимость, легкость поддержки и минимальные требования к инструментам.

• Позволяет быстро задать правила структуры XML.
• Поддерживается многими XML-парсерами и инструментами.
• Подходит для простых и стабильных форматов обмена.
• Может использоваться как техническая документация по структуре файла.
• Помогает выявлять ошибки до обработки данных бизнес-системой.

Ограничения DTD

DTD появился рано и решает не все задачи современной валидации данных. Он хорошо описывает структуру, но слабо работает с типами данных. Например, DTD может сказать, что внутри price должен быть текст, но не может удобно проверить, что это именно десятичное число больше нуля. Для таких задач лучше подходят XML Schema или прикладные проверки в коде.

• Слабая поддержка типов данных по сравнению с XML Schema.
• Нет удобного способа описывать сложные числовые, датовые и бизнес-ограничения.
• Синтаксис DTD отличается от XML, поэтому его сложнее обрабатывать как обычный XML-документ.
• При небезопасной настройке парсера внешние сущности могут создавать риски безопасности.
• Не всегда подходит для новых API и современных веб-сервисов.

Ошибки и риски при использовании DTD

Самая частая ошибка — считать DTD полноценной бизнес-валидацией. DTD может проверить структуру, но не всегда проверит смысл данных. Например, документ может быть валидным по DTD, но содержать отрицательное количество товара, устаревший код клиента или дату из будущего. Поэтому DTD лучше использовать как первый уровень контроля, а бизнес-правила проверять отдельно.

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

DTD и XML Schema: в чем разница

DTD и XML Schema похожи тем, что оба инструмента описывают правила для XML. Но XML Schema более современна и выразительна. Она позволяет задавать типы данных, ограничения длины, форматы дат, числовые диапазоны и более сложные структуры. DTD проще, но менее строгий.

Выбор зависит от проекта. Если формат уже использует DTD и его достаточно для проверки структуры, нет смысла менять его без причины. Если создается новая интеграция со сложными требованиями к типам данных, чаще стоит рассмотреть XML Schema или другой современный контракт данных.

Когда стоит использовать DTD

DTD уместен, когда нужно быстро и понятно описать структуру XML, а требования к типам данных минимальны. Он также полезен, когда система уже работает с DTD и важно сохранить совместимость. В таких случаях DTD может быть надежным и недорогим инструментом контроля формата.

1. Формат XML простой и стабильный.
2. Основная задача — проверить наличие и порядок элементов.
3. Инструменты заказчика или партнера уже поддерживают DTD.
4. Нужно поддерживать исторический формат без серьезной модернизации.
5. Данные дополнительно проверяются на уровне приложения.

Когда DTD лучше не выбирать

Для новых API и сложных интеграций DTD часто оказывается недостаточным. Если нужно строго проверять даты, числа, справочники, диапазоны, составные типы и разные версии формата, лучше рассмотреть другие инструменты. В JSON-проектах обычно используют JSON Schema, а для XML с развитой типизацией — XML Schema.

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

Практический сценарий

Представим интернет-магазин, который каждый вечер отправляет поставщику XML с заказами. Поставщик ожидает, что в каждом заказе будут номер, дата, клиент и позиции. Если магазин случайно отправит поле clientName вместо customer или забудет блок items, загрузка на стороне поставщика может завершиться ошибкой.

Чтобы избежать ручных разборов, стороны согласуют DTD. Магазин проверяет XML перед отправкой, а поставщик — при получении. Ошибочный файл не попадает в обработку, а команда поддержки видит конкретную причину: отсутствует элемент, нарушен порядок или указан недопустимый атрибут. Это ускоряет диагностику и снижает стоимость интеграционных ошибок.

Как внедрять DTD в проект

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

1. Описать бизнес-сценарий обмена данными.
2. Согласовать корневой элемент и основные разделы XML.
3. Определить обязательные и необязательные элементы.
4. Задать атрибуты и допустимые перечисления, если они нужны.
5. Настроить автоматическую проверку XML в тестовом контуре.
6. Добавить версионирование DTD и понятные сообщения об ошибках.

Связанные термины

• XML — язык разметки, для которого DTD часто описывает структуру документа.
• XML Schema — более мощный способ описывать и валидировать XML-документы.
• Валидация данных — проверка соответствия документа заданным правилам.
• Парсер — программа или библиотека, которая читает XML и разбирает его структуру.
• Интеграция систем — обмен данными между приложениями, сервисами и платформами.
• Контракт данных — согласованное описание формата, по которому системы обмениваются информацией.

Краткий итог

DTD — это способ описать правила структуры XML-документа. Он помогает проверить, что документ содержит нужные элементы, атрибуты и вложенность. В бизнес-контексте DTD полезен для интеграций, обмена файлами, поддержки старых систем и снижения ошибок на границе между приложениями. При этом DTD не заменяет полноценную бизнес-валидацию и требует внимательной настройки безопасности XML-парсеров.