WikiDer > Определение типа документа

А определение типа документа (DTD) представляет собой набор объявления разметки которые определяют тип документа для SGML-семья язык разметки (GML, SGML, XML, HTML).

DTD определяет допустимые строительные блоки XML-документа. Он определяет структуру документа со списком проверенных элементов и атрибутов. DTD может быть объявлен встроенным внутри XML-документа или как внешняя ссылка.^[1]

XML использует подмножество SGML DTD.

По состоянию на 2009 год^{[Обновить]}, новее Пространство имен XML-осведомленный языки схемы (Такие как Схема W3C XML и ISO RELAX NG) в значительной степени вытеснили DTD. Версия DTD с поддержкой пространств имен разрабатывается как часть 9 ISO. DSDL. DTD сохраняются в приложениях, которым требуются специальные символы публикации, такие как Ссылки на символы XML и HTML, которые происходят из более крупных наборов, определенных как часть Стандарт ISO SGML усилие.

Связывание DTD с документами

DTD связывается с документом XML или SGML с помощью объявление типа документа (DOCTYPE). DOCTYPE появляется в синтаксическом фрагменте doctypedecl рядом с началом XML-документа.^[2] Объявление устанавливает, что документ является экземпляром типа, определенного указанным DTD.

DOCTYPE декларируют два типа:

• необязательный внешнее подмножество
• необязательный внутреннее подмножество.

Объявления во внутреннем подмножестве образуют часть DOCTYPE в самом документе. Объявления во внешнем подмножестве находятся в отдельном текстовом файле. На внешнее подмножество можно ссылаться через публичный идентификатор и / или системный идентификатор. Программы для чтения документов могут не потребоваться для чтения внешнего подмножества.

Любой действительный документ SGML или XML, который ссылается на внешнее подмножество в своем DTD или тело которого содержит ссылки на проанализированные внешние объекты заявлено в его DTD (включая те, которые заявлены в его внутреннее подмножество), может быть только частично проанализирован, но не может быть полностью подтвержден подтверждение Парсеры SGML или XML в их автономный mode (это означает, что эти проверяющие синтаксические анализаторы не пытаются получить эти внешние сущности, и их текст замены недоступен).

Однако такие документы по-прежнему можно полностью анализировать в не-стандартный режим проверки парсеров, который сигнализирует об ошибке, если он не может найти эти внешние объекты с их указанными публичный идентификатор (FPI) или же системный идентификатор (URI) или недоступны. (Обозначения, объявленные в DTD, также ссылаются на внешние сущности, но эти неанализируемые сущности не нужны для проверки документов в автономный режим этих синтаксических анализаторов: проверка всех внешних объектов, на которые ссылаются нотации, предоставляется приложению с использованием синтаксического анализатора SGML или XML). Непроверяющие парсеры май в конечном итоге попытаться найти эти внешние объекты в не-стандартный режим (путем частичной интерпретации DTD только для разрешения объявленных анализируемых сущностей), но не проверять модель содержимого этих документов.

Примеры

Следующий пример DOCTYPE содержит как общедоступные, так и системные идентификаторы:

 html ОБЩЕСТВЕННЫЙ "- // W3C // DTD XHTML 1.0 Transitional // EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Все документы HTML 4.01 соответствуют одному из трех DTD SGML. Публичные идентификаторы этих DTD являются постоянными и следующие:

• - // W3C // DTD HTML 4.01 // EN
• - // W3C // DTD HTML 4.01 Transitional // EN
• - // W3C // DTD HTML 4.01 Frameset // EN

Системные идентификаторы этих DTD, если они присутствуют в DOCTYPE, являются Ссылки URI. Системный идентификатор обычно указывает на определенный набор объявлений в разрешаемом месте. SGML позволяет отображать общедоступные идентификаторы в системные идентификаторы в каталоги которые необязательно доступны для преобразователей URI, используемых документом разбор программного обеспечения.

Этот DOCTYPE может отображаться только после необязательный Объявление XMLи перед телом документа, если синтаксис документа соответствует XML. Это включает в себя XHTML документы:

<?xml version="1.0" encoding="utf-8"?>"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><!-- the XHTML document body starts here--> xmlns ="http://www.w3.org/1999/xhtml"> ...</html>

Дополнительное внутреннее подмножество также может быть предоставлено после внешнего подмножества:

<?xml version="1.0" encoding="utf-8"?>"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" [  <!-- an internal subset can be embedded here -->]><!-- the XHTML document body starts here--> xmlns ="http://www.w3.org/1999/xhtml"> ...</html>

В качестве альтернативы может быть предоставлено только внутреннее подмножество:

<?xml version="1.0" encoding="utf-8"?>  <!-- an internal subset can be embedded here -->]><!-- the XHTML document body starts here--> xmlns ="http://www.w3.org/1999/xhtml"> ...</html>

Наконец, определение типа документа может вообще не включать подмножество; в этом случае он просто указывает, что документ имеет один элемент верхнего уровня (это неявное требование для всех допустимых документов XML и HTML, но не для фрагментов документа или всех документов SGML, чьи элементы верхнего уровня могут отличаться от подразумеваемого корневого элемента), и он указывает имя типа корневого элемента:

<?xml version="1.0" encoding="utf-8"?><!DOCTYPE html><!-- the XHTML document body starts here--> xmlns ="http://www.w3.org/1999/xhtml"> ...</html>

Объявления разметки

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

Объявления разметки DTD объявляют, какие типы элементов, списки атрибутов, сущности, и обозначения разрешены в структуре соответствующего класса XML-документов.^[3]

Объявления типа элемента

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

Различные ключевые слова и символы определяют содержимое элемента:

• ПУСТОЙ для указания того, что определенный элемент не допускает никакого содержимого, т. е. не может иметь дочерних элементов, даже текстовых элементов (если есть пробелы, они игнорируются);
• ЛЮБОЙ для указания того, что определенный элемент допускает любой контент без ограничений, т.е. что он может иметь любое количество (включая отсутствие) и тип дочерних элементов (включая текстовые элементы);
• или выражение, определяющее только элементы, разрешенные как прямые дочерние элементы в содержимом определенного элемента; это содержимое может быть либо:
  • а смешанное содержание, что означает, что контент может включать по крайней мере один текстовый элемент и ноль или более именованных элементов, но их порядок и количество вхождений не могут быть ограничены; это может быть:
    • ( #PCDATA ): историческое значение проанализированные символьные данные, это означает, что в содержимом разрешен только один текстовый элемент (квантификатор не допускается);
    • ( #PCDATA | ''элемент имя'' | ... )*: ограниченный выбор (в исключительном списке в круглых скобках и через "|"символы вертикальной черты и заканчиваются обязательным"*«квантификатор») двух или более дочерних элементов (включая только текстовые элементы или указанные именованные элементы) могут использоваться в любом порядке и количестве вхождений в контент.
  • ан содержание элемента, что означает, что в дочерних элементах содержимого не должно быть текстовых элементов (все пробелы, закодированные между дочерними элементами, игнорируются, как и комментарии). Такое содержимое элемента указывается как частица содержимого в варианте Форма Бэкуса – Наура без терминальных символов и имен элементов как нетерминальных символов. Содержание элемента состоит из:
    • а частица содержимого может быть либо именем элемента, объявленного в DTD, либо список последовательностей или же список выбора. За ним может следовать необязательный квантификатор.
      • а список последовательностей означает упорядоченный список (указанный в скобках и разделенный знаком ","запятая") одного или нескольких частицы содержимого: все частицы содержимого должны последовательно появляться как прямые дочерние элементы в содержимом определенного элемента в указанной позиции и относительном порядке;
      • а список выбора означает взаимоисключающий список (указанный в скобках и разделенный знаком "|"вертикальная черта") двух или более частицы содержимого: только один из них частицы содержимого может появляться в содержимом определенного элемента в той же позиции.
    • А квантификатор представляет собой одиночный символ, который следует непосредственно за указанным элементом, к которому он применяется, чтобы ограничить количество последовательных вхождений этих элементов в указанную позицию в содержимом элемента; это может быть либо:
      • + для указания того, что должно быть одно или несколько вхождений элемента - эффективное содержание каждого вхождения может быть разным;
      • * для указания того, что разрешено любое количество (ноль или более) вхождений - элемент является необязательным, и эффективное содержание каждого вхождения может быть различным;
      • ? для указания, что должно быть не более одного вхождения - элемент не является обязательным;
      • Если квантификатор отсутствует, указанный элемент должен появиться ровно один раз в указанной позиции в содержимом элемента.

Например:

 html (голова, тело)> п (#PCDATA | п | ул | дл | стол | h1|h2|h3)*>

Объявления типа элемента игнорируются непроверяющий Анализаторы SGML и XML (в этих случаях любые элементы принимаются в любом порядке и в любом количестве экземпляров в анализируемом документе), но эти объявления по-прежнему проверяются на предмет формы и действительности.

Объявления списка атрибутов

Список атрибутов определяет для данного типа элемента список всех возможных атрибутов, связанных с этим типом. Для каждого возможного атрибута он содержит:

• объявленное имя атрибута,
• его тип данных (или перечисление его возможных значений),
• и его значение по умолчанию.^[4]

Например:

 img   src    CDATA          #ТРЕБУЕТСЯ   я бы     Я БЫ             # ПРЕДПОЛАГАЕТСЯ   Сортировать   CDATA          #ФИКСИРОВАННЫЙ "истинный"   Распечатать  (да | нет) "да">

Вот некоторые типы атрибутов, поддерживаемые как SGML, так и XML:

CDATA

этот тип означает данные символов и указывает, что действующим значением атрибута может быть любое текстовое значение, если атрибут не указан как фиксированный (комментарии в DTD могут дополнительно документировать значения, которые фактически принимаются, но синтаксис DTD не допускает такой точной спецификации);

Я БЫ

Действующее значение атрибута должно быть действительным идентификатором, и оно используется для определения и привязки к текущему элементу цели ссылок с использованием этого определенного идентификатора (в том числе как документ идентификаторы фрагментов который может быть указан в конце URI после знака "#"); это ошибка, если разные элементы в одном документе определяют один и тот же идентификатор; ограничение уникальности также подразумевает, что сам идентификатор не несет никакой другой семантики и что идентификаторы должны обрабатываться в приложениях как непрозрачные; XML также предопределяет стандартный псевдоатрибут "xml: id"с этим типом без необходимости какого-либо объявления в DTD, поэтому ограничение уникальности также применяется к этим определенным идентификаторам, когда они указаны где-нибудь в документе XML.

IDREF или же IDREFS

эффективное значение атрибута может быть только действительным идентификатором (или списком таких идентификаторов, разделенных пробелами) и должно ссылаться на уникальный элемент, определенный в документе, с атрибутом, объявленным с типом Я БЫ в DTD (или уникальный элемент, определенный в документе XML с псевдоатрибутом "xml: id") и эффективное значение которого совпадает с идентификатором;

NMTOKEN или же НМТОКЕНЫ

эффективное значение атрибута может быть только действительным токеном имени (или списком таких токенов, разделенных пробелами), но не ограничивается уникальным идентификатором в документе; это имя может нести дополнительную и зависящую от приложения семантику и может требовать дополнительных ограничений именования, но это выходит за рамки DTD;

ЮРИДИЧЕСКОЕ ЛИЦО или же ЛИЦА

эффективное значение атрибута может быть только именем неанализируемой внешней сущности (или списком таких имен, разделенных пробелами), которое также должно быть объявлено в объявлении типа документа; этот тип не поддерживается в синтаксических анализаторах HTML, но допустим в SGML и XML 1.0 или 1.1 (включая XHTML и SVG);

(''значение1''|...)

эффективное значение атрибута может быть только одним из перечислимого списка (указан в скобках и разделен знаком "|"вертикальная черта") текстовых значений, где каждое значение в перечислении, возможно, указывается между 'Один' или же "двойной" кавычки, если это не простой токен имени;

ОБОЗНАЧЕНИЕ (''обозначение1''|...)

эффективное значение атрибута может быть только одним из перечисленных списков (указано в скобках и разделено знаком "|"вертикальная черта") имен нотаций, где каждое имя нотации в перечислении также должно быть объявлено в объявлении типа документа; этот тип не поддерживается в парсерах HTML, но допустим в SGML и XML 1.0 или 1.1 (включая XHTML и SVG) .

Значение по умолчанию может определять, должен ли атрибут встречаться (#ТРЕБУЕТСЯ) или нет (# ПРЕДПОЛАГАЕТСЯ), или имеет ли оно фиксированное значение (#ФИКСИРОВАННЫЙ), или какое значение следует использовать в качестве значения по умолчанию («…») в случае, если данный атрибут не указан в теге XML.

Объявления списка атрибутов игнорируются непроверяющий Анализаторы SGML и XML (в этих случаях любой атрибут принимается во всех элементах анализируемого документа), но эти объявления по-прежнему проверяются на правильность и достоверность.

Объявления сущностей

Сущность похожа на макрос. Объявление объекта присваивает ему значение, которое сохраняется во всем документе. Обычно используется для того, чтобы имя было более узнаваемым, чем числовая ссылка на незнакомый символ.^[5] Сущности помогают улучшить читаемость текста XML. В общем, бывают двух типов: внутренние и внешние.

• Внутренние (проанализированные) сущности связывают имя с любым произвольным текстовым содержимым, определенным в их объявлении (которое может быть в внутреннее подмножество или в внешнее подмножество DTD, заявленного в документе). Когда указанная ссылка на объект затем встречается в остальной части документа (включая остальную часть DTD), и если это имя объекта было эффективно определено как проанализированный объект, сама ссылка немедленно заменяется текстовым содержимым, определенным в проанализированный объект, и синтаксический анализ продолжается в этом тексте замены.
  • Предопределенные именованные сущности символов похожи на внутренние сущности: 5 из них, однако, обрабатываются особым образом во всех синтаксических анализаторах SGML, HTML и XML. Эти сущности немного отличаются от обычных анализируемых сущностей, потому что, когда в документе встречается именованная символьная ссылка на сущность, эта ссылка также немедленно заменяется символьным содержимым, определенным в сущности, но разбор продолжается. после текст замены, который немедленно вставляется буквально в текущий анализируемый токен (если такой символ разрешен в текстовом значении этого токена). Это позволяет некоторым символам, которые необходимы для основного синтаксиса HTML или XML, экранировать их особую синтаксическую роль (в частности, «&», который зарезервирован для ссылок на начальные объекты, «<» или «>», которые ограничивают теги разметки, и «двойные» или «одинарные» кавычки, которые ограничивают значения атрибутов и определений сущностей). Предопределенные символьные сущности также включают числовые символьные ссылки, которые обрабатываются таким же образом и могут также использоваться для экранирования символов, которые они представляют, или для обхода ограничений в репертуаре символов, поддерживаемых кодировкой документа.
  • В базовых профилях для SGML или в HTML-документах объявление внутренних объектов невозможно (поскольку внешние подмножества DTD не извлекаются, а внутренние подмножества DTD не поддерживаются в этих базовых профилях).
  • Вместо этого стандарты HTML предопределяют большой набор из нескольких сотен именованных символьных сущностей, которые по-прежнему могут обрабатываться как стандартные анализируемые сущности, определенные в DTD, используемом анализатором.
• Внешние объекты относятся к объектам внешнего хранилища. Они просто объявлены уникальным именем в документе и определены с помощью общедоступного идентификатора (FPI) и / или системного идентификатора (интерпретируемого как URI) с указанием источника их содержания. Фактически они существуют в двух вариантах:
  • проанализированные внешние объекты (чаще всего определяется идентификатором SYSTEM, указывающим URI их содержимого), которые нет связаны в своем определении с именованной аннотацией, и в этом случае проверяющие синтаксические анализаторы XML или SGML извлекают их содержимое и анализируют их, как если бы они были объявлены как внутренние объекты (внешний объект, содержащий их эффективный замещающий текст);
  • неанализируемые внешние объекты которые определены и связаны с именем аннотации, и в этом случае они обрабатываются как непрозрачные ссылки и сообщаются как таковые приложению с помощью синтаксического анализатора SGML или XML: их интерпретация, поиск и синтаксический анализ предоставляются приложению в соответствии с типами аннотации, которые он поддерживает (см. следующий раздел об аннотациях и примерах неанализируемых внешних сущностей).
  • Внешние сущности не поддерживаются в базовых профилях для SGML или в документах HTML, но действительны в полных реализациях SGML и в XML 1.0 или 1.1 (включая XHTML и SVG, даже если они не являются строго необходимыми в этих типах документов).

Пример декларации внутренней сущности (здесь во внутреннем подмножестве DTD документа SGML):

 sgml [   sgml ЛЮБОЙ>   % стандартное       "стандартный SGML">   % подпись "& # x2014; & author ;.">   % вопрос  "Почему я не могу опубликовать свои книги прямо в% std ;?">   % автор    "Уильям Шекспир">]>

<sgml>& вопрос; & подпись;</sgml>

Внутренние сущности могут быть определены в любом порядке, если на них нет ссылок и они не анализируются в DTD или в теле документа, в порядке их анализа: допустимо включать ссылку на еще не определенную сущность в контент. анализируемого объекта, но недопустимо включать где-либо еще какую-либо ссылку на именованный объект до того, как этот объект будет полностью определен, включая все другие внутренние объекты, на которые есть ссылки в его определенном содержимом (это также предотвращает циклические или рекурсивные определения внутренних объектов). Этот документ анализируется так, как если бы он был:

 sgml [   sgml ЛЮБОЙ>   % стандартное       "стандартный SGML">   % подпись "- & автор;">   % вопрос  "Почему я не мог опубликовать свои книги непосредственно в стандартном SGML?">   % автор    "Уильям Шекспир">]>

<sgml>Почему я не мог опубликовать свои книги непосредственно в стандартном SGML? - Уильям Шекспир.</sgml>

Ссылка на внутреннюю сущность «автор» не заменяется в тексте замены внутренней сущности «подпись». Вместо этого он заменяется только тогда, когда ссылка на сущность «подпись» анализируется в содержимом элемента «sgml», но только путем проверки парсеров (непроверяющие парсеры не заменяют ссылки на сущности, встречающиеся в содержимом элемента или в значениях атрибутов, в теле документа.

Это возможно, потому что замещающий текст, указанный в определениях внутренней сущности, позволяет различать параметр ссылки на сущности (которые представлены символом "%" и замена которых применяется к проанализированному содержимому DTD) и Общее ссылки на сущности (которые вводятся символом «&» и замена которых откладывается до тех пор, пока они не будут эффективно проанализированы и проверены). Символ «%» для введения ссылок на сущности параметров в DTD теряет свою особую роль вне DTD и становится буквальным символом.

Однако ссылки на предопределенные числовые символьные сущности заменяются везде, где они встречаются, без необходимости проверяющего синтаксического анализатора (они вводятся только символом «&»).

Декларации обозначений

Обозначения используются в SGML или XML. Они предоставляют полную ссылку на неанализируемые внешние сущности, интерпретация которых предоставляется приложению (которое интерпретирует их напрямую или извлекает сам внешний объект), присваивая им простое имя, которое можно использовать в теле документа. Например, нотации могут использоваться для ссылки на данные, не относящиеся к XML, в документе XML 1.1. Например, чтобы аннотировать изображения SVG, чтобы связать их с определенным средством визуализации:

 тип-изображение-svg СИСТЕМА "изображение / SVG">

Это заявляет Тип MIME внешних изображений с этим типом и связывает его с именем записи "type-image-svg". Однако имена нотаций обычно следуют соглашению об именах, которое характерно для приложения, генерирующего или использующего нотацию: нотации интерпретируются как дополнительные метаданные, эффективное содержание которых является внешней сущностью и либо ОБЩЕСТВЕННЫМ FPI, зарегистрированным в каталогах, используемых XML или Анализаторы SGML или SYSTEM URI, интерпретация которых зависит от приложения (здесь тип MIME, интерпретируемый как относительный URI, но это может быть абсолютный URI для определенного средства визуализации, или URN, указывающий идентификатор объекта, зависящий от ОС, например UUID).

Объявленное имя нотации должно быть уникальным во всем объявлении типа документа, то есть во внешнем подмножестве, а также во внутреннем подмножестве, по крайней мере, для соответствия XML.^[6][7]

Обозначения могут быть связаны с неанализируемыми внешними объектами, включенными в тело документа SGML или XML. В ОБЩЕСТВЕННЫЙ или же СИСТЕМА параметр этих внешних сущностей определяет FPI и / или URI, где расположены неанализируемые данные внешнего объекта, а также дополнительные NDATA Параметр этих определенных сущностей указывает дополнительную нотацию (то есть фактически тип MIME здесь). Например:

 sgml [   sgml (img)*>   img ПУСТОЙ>   img     данные ЮРИДИЧЕСКОЕ ЛИЦО # ПРЕДПОЛАГАЕТСЯ>     example1SVG     СИСТЕМА "example1.svg" NDATA example1SVG-rdf>   example1SVG-rdf СИСТЕМА "example1.svg.rdf">]>

<sgml>   данные ="example1SVG" /></sgml>

В теле документа SGML эти внешние объекты, на которые имеются ссылки (имя которых указывается между "&" и ";"), являются нет заменяются как обычные именованные сущности (определенные с помощью значения CDATA), но остаются как отдельные неанализируемые токены, которые могут использоваться либо как значение атрибута элемента (как указано выше), либо внутри содержимого элемента, при условии, что либо DTD допускает такие внешние сущности в объявленном типе содержимого элементов или в объявленном типе атрибутов (здесь ЮРИДИЧЕСКОЕ ЛИЦО тип для данные атрибут), или парсер SGML не проверяет содержимое.

Обозначения также могут быть напрямую связаны с элементами как дополнительные метаданные, без привязки их к другому внешнему объекту, путем предоставления их имен в качестве возможных значений некоторых дополнительных атрибутов (также объявленных в DTD внутри ...> объявление элемента). Например:

 sgml [   sgml (img)*>   <!--     необязательное значение атрибута «type» может быть установлено только в этой нотации.   -->   sgml    тип  ОБОЗНАЧЕНИЕ (      зависящий от типа поставщика ) # ПРЕДПОЛАГАЕТСЯ>   img ЛЮБОЙ> <!-- optional content can be only parsable SGML or XML data -->   <!--     Необязательное значение атрибута title должно обрабатываться как текст.     Необязательное значение атрибута «данные» устанавливается на неанализируемую внешнюю сущность.     Необязательное значение атрибута type может быть только одним из двух обозначений.   -->   img    заглавие CDATA              # ПРЕДПОЛАГАЕТСЯ    данные  ЮРИДИЧЕСКОЕ ЛИЦО             # ПРЕДПОЛАГАЕТСЯ    тип  ОБОЗНАЧЕНИЕ (      тип-изображение-svg |      тип-изображение-gif )       # ПРЕДПОЛАГАЕТСЯ>  <!--    Обозначения относятся к внешним объектам и могут быть установлены в атрибутах "type" выше,    или на них должны ссылаться любые определенные внешние объекты, которые не могут быть проанализированы.  -->   тип-изображение-svg       ОБЩЕСТВЕННЫЙ "- // W3C // DTD SVG 1.1 // EN"     "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">   тип-изображение-gif       ОБЩЕСТВЕННЫЙ "изображение / gif">   зависящий от типа поставщика ОБЩЕСТВЕННЫЙ "application / VND.specific + sgml">   example1SVGTitle "Название example1.svg"> <!-- parsed internal entity -->   example1SVG      СИСТЕМА "example1.svg"> <!-- parsed external entity -->   example1GIFTitle "Название example1.gif"> <!-- parsed internal entity -->   example1GIF      СИСТЕМА "example1.gif" NDATA тип-изображение-gif> <!-- unparsed external entity -->]>

 type ="зависит от типа и поставщика">  <!-- an SVG image is parsable as valid SGML or XML text -->   title ="& example1SVGTitle;" type ="тип-изображение-svg">& example1SVG;</img>  <!-- it can also be referenced as an unparsed external entity -->   title ="& example1SVGTitle;" данные ="example1SVG" />  <!-- a GIF image is not parsable and can only be referenced as an external entity -->   title ="& example1GIFTitle;" данные ="example1GIF" /></sgml>

В приведенном выше примере показана нотация с именем "type-image-svg", которая ссылается на стандартный общедоступный FPI и системный идентификатор (стандартный URI) документа SVG 1.1, вместо указания только системного идентификатора, как в первом примере (который был относительный URI, интерпретируемый локально как тип MIME). На эту аннотацию имеется прямая ссылка в неанализируемом атрибуте «type» элемента «img», но ее содержимое не извлекается. Он также объявляет другую нотацию для приложения, зависящего от поставщика, для аннотации корневого элемента «sgml» в документе. В обоих случаях объявленная нотация named используется непосредственно в объявленном атрибуте «type», содержание которого указано в DTD с типом атрибута «NOTATION» (этот атрибут «type» также объявлен для элемента «sgml» что касается элемента "img").

Однако атрибут «title» элемента «img» указывает внутреннюю сущность «example1SVGTitle», объявление которой не определяет аннотацию, поэтому она анализируется проверяющими синтаксическими анализаторами, а текст замены сущности - «Title of example1.svg».

Содержимое элемента «img» ссылается на другой внешний объект «example1SVG», объявление которого также не определяет нотацию, поэтому оно также анализируется проверяющими синтаксическими анализаторами, а текст замены объекта находится по его определенному идентификатору SYSTEM «example1.svg» ( также интерпретируется как относительный URI). Эффективное содержание элемента «img» должно быть содержанием этого второго внешнего ресурса. Разница с изображением GIF заключается в том, что изображение SVG анализируется в документе SGML в соответствии с декларациями в DTD, где изображение GIF упоминается как непрозрачный внешний объект (который не может быть проанализирован с помощью SGML) через его " data »(чей тип значения - непрозрачный ENTITY).

В значении атрибутов ENTITY можно указать только одно имя нотации (в SGML, XML 1.0 или XML 1.1 нет поддержки для нескольких имен нотации в одном объявленном внешнем ENTITY, поэтому необходимы отдельные атрибуты). Однако на несколько внешних объектов можно ссылаться (в списке имен, разделенных пробелами) в атрибутах, объявленных с типом ENTITIES, и где каждый именованный внешний объект также объявлен с собственной нотацией).

Нотации также полностью непрозрачны для синтаксических анализаторов XML и SGML, поэтому они не различаются по типу внешнего объекта, на который они могут ссылаться (для этих синтаксических анализаторов они просто имеют уникальное имя, связанное с общедоступным идентификатором (FPI) и / или системный идентификатор (URI)).

Некоторые приложения (но не сами анализаторы XML или SGML) также позволяют косвенно ссылаться на нотации, называя их в "URN: '' имя ''" значение стандартного атрибута CDATA, везде может быть указан URI. Однако это поведение зависит от приложения и требует, чтобы приложение поддерживало каталог известных URN, чтобы преобразовать их в нотации, которые были проанализированы в стандартном синтаксическом анализаторе SGML или XML. Такое использование позволяет определять нотации только в DTD, хранящемся как внешний объект и на который ссылаются только как на внешнее подмножество документов, и позволяет этим документам оставаться совместимыми с проверяющими синтаксическими анализаторами XML или SGML, которые не имеют прямой поддержки нотаций.

Обозначения не используются в HTML или в базовых профилях для XHTML и SVG, потому что:

• На все внешние объекты, используемые этими стандартными типами документов, ссылаются простые атрибуты, объявленные с типом CDATA в их стандартном DTD (например, атрибут "href" элемента привязки "a" или атрибут "src" изображения " img "элемент, значения которого интерпретируются как URI, без необходимости в каком-либо каталоге общедоступных идентификаторов, т. е. известных FPI)
• На все внешние сущности для дополнительных метаданных ссылаются:
  • Дополнительные атрибуты (например, тип, который указывает MIME-тип внешней сущности или кодировка атрибут, указывающий его кодировку)
  • Дополнительные элементы (например, связь или же мета в HTML и XHTML) с собственными атрибутами
  • Стандартные псевдоатрибуты в XML и XHTML (например, xml: lang, или же xmlns и xmlns: * для объявлений пространств имен).

Даже при проверке парсеров SGML, XML 1.0 или XML 1.1 внешние объекты, на которые ссылается FPI и / или URI в объявленных нотациях, не извлекаются автоматически самими анализаторами. Вместо этого эти синтаксические анализаторы просто предоставляют приложению проанализированные FPI и / или URI, связанные с нотациями, найденными в проанализированном документе SGML или XML, и с возможностью для словаря, содержащего все имена нотаций, объявленные в DTD; эти проверяющие синтаксические анализаторы также проверяют уникальность объявлений имен нотаций и сообщают об ошибке валидации, если некоторые имена нотаций используются где-то в DTD или в теле документа, но не объявлены:

• Если приложение не может использовать какую-либо нотацию (или если их FPI и / или URI неизвестны или не поддерживаются в их локальном каталоге), эти нотации могут либо игнорироваться приложением без уведомления, либо приложение может сигнализировать об ошибке.
• В противном случае приложения сами решают, как их интерпретировать, а затем, если внешние объекты должны быть извлечены, а затем проанализированы отдельно.
• Затем приложения могут сигнализировать об ошибке, если такая интерпретация, извлечение или отдельный анализ не удается.
• Нераспознанные нотации, которые могут привести к тому, что приложение сигнализирует об ошибке, не должны блокировать интерпретацию проверенного документа с их помощью.

XML DTD и проверка схемы

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

Большинство языков схем XML являются только заменой объявлений элементов и списков атрибутов таким образом, что становится возможным анализировать документы XML с помощью непроверяющий Анализаторы XML (если единственной целью внешнего подмножества DTD было определение схемы). Кроме того, документы для этих языков схемы XML должны анализироваться отдельно, поэтому проверка схемы документов XML в чистом автономном режиме на этих языках невозможна: объявление типа документа остается необходимым, по крайней мере, для идентификации (с Каталог XML) схема, используемая в проанализированном XML-документе и проверенная на другом языке.

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

А непроверяющий синтаксический анализатор может, однако, решить не читать анализируемый внешние организации (в том числе внешнее подмножество) и не должен соблюдать ограничения модели содержимого, определенные в объявлениях элементов и в объявлениях списка атрибутов.

Если XML-документ зависит от анализируемых внешних сущностей (включая указанные внешнее подмножество, или анализируемые внешние объекты, объявленные в внутреннее подмножество), он должен утверждать standalone = "нет" в его Объявление XML. Подтверждающий DTD может быть идентифицирован с помощью Каталоги XML получить его указанный внешнее подмножество.

В приведенном ниже примере XML-документ объявлен с standalone = "нет" потому что он имеет внешнее подмножество в объявлении типа документа:

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE people_list SYSTEM "example.dtd"> />

Если объявление типа XML-документа включает какой-либо идентификатор SYSTEM для внешнего подмножества, его нельзя безопасно обрабатывать как автономное: должен быть получен URI, в противном случае могут быть неизвестные именованные символьные сущности, определение которых может потребоваться для правильного анализа эффективного XML. синтаксис во внутреннем подмножестве или в теле документа (обычно выполняется синтаксический анализ XML после замена всех именованных сущностей, за исключением пяти сущностей, которые предопределены в XML и неявно заменяются после парсинг XML-документа на лексические токены). Если он просто включает какой-либо ПУБЛИЧНЫЙ идентификатор, он май обрабатываться как автономный, если процессор XML знает этот PUBLIC идентификатор в своем локальном каталоге, откуда он может извлечь связанный объект DTD.

Пример схемы XML DTD

Пример очень простого внешнего XML DTD для описания схемы списка лиц может состоять из:

 people_list (человек)*> человек (имя, Дата рождения?, Пол?, ИНН?)> имя (#PCDATA)> Дата рождения (#PCDATA)> Пол (#PCDATA)> ИНН (#PCDATA)>

Взяв эту строку за строкой:

1. people_list - допустимое имя элемента, и экземпляр такого элемента содержит любое количество человек элементы. В * означает, что может быть 0 или более человек элементы внутри people_list элемент.
2. человек - допустимое имя элемента, и экземпляр такого элемента содержит один элемент с именем имя, за которым следует один с именем Дата рождения (необязательно), затем Пол (также необязательно) и ИНН (также необязательно). В ? указывает, что элемент является необязательным. Ссылка на имя имя элемента не имеет ?, так что человек элемент должен содержать имя элемент.
3. имя - допустимое имя элемента, и экземпляр такого элемента содержит «проанализированные символьные данные» (#PCDATA).
4. Дата рождения - допустимое имя элемента, и экземпляр такого элемента содержит проанализированные символьные данные.
5. Пол - допустимое имя элемента, и экземпляр такого элемента содержит проанализированные символьные данные.
6. ИНН - допустимое имя элемента, и экземпляр такого элемента содержит проанализированные символьные данные.

Ниже приводится пример XML-файла, который использует это DTD и соответствует ему. Здесь DTD упоминается как внешнее подмножество через спецификатор SYSTEM и URI. Предполагается, что мы можем идентифицировать DTD с помощью относительной ссылки URI "example.dtd"; "people_list" после "! DOCTYPE" сообщает нам, что корневые теги или первый элемент, определенный в DTD, называется "people_list":

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE people_list SYSTEM "example.dtd"><people_list>  <person>    <name>Фред Блоггс</name>    <birthdate>2008-11-27</birthdate>    <gender>Мужской</gender>  </person></people_list>

Это можно отобразить в формате с поддержкой XML браузер (Такие как Internet Explorer или же Mozilla Firefox), вставив и сохранив компонент DTD выше в текстовый файл с именем example.dtd и XML-файл в текстовый файл с другим именем и открытие XML-файла в браузере. Оба файла должны быть сохранены в одном каталоге. Однако многие браузеры не проверяют, соответствует ли XML-документ правилам в DTD; они необходимы только для проверки синтаксической правильности DTD. По соображениям безопасности они также могут не читать внешнее DTD.

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

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>  <!ELEMENT people_list (person*)>  <!ELEMENT person (name, birthdate?, gender?, socialsecuritynumber?)>  <!ELEMENT name (#PCDATA)>  <!ELEMENT birthdate (#PCDATA)>  <!ELEMENT gender (#PCDATA)>  <!ELEMENT socialsecuritynumber (#PCDATA)>]><people_list>  <person>    <name>Фред Блоггс</name>    <birthdate>2008-11-27</birthdate>    <gender>Мужской</gender>  </person></people_list>

Доступны альтернативы DTD (для указания схем):

• Схема XML, также называемое определением схемы XML (XSD), получил статус рекомендации в W3C,^[8] и популярен для «ориентированного на данные» (то есть транзакционного, не публикующего) использования XML из-за его более строгой типизации и более простого перехода к объявлениям Java.^{[нужна цитата]} Большая часть издательского мира обнаружила, что дополнительная сложность XSD не принесет им особых преимуществ,^{[нужна цитата]} так что DTD там по-прежнему намного популярнее. Определение схемы XML само по себе является XML-документом, а DTD - нет.
• РЕЛАКС НГ, который также является частью DSDL, является международным стандартом ISO.^[9] Он более выразительный, чем XSD,^{[нужна цитата]} обеспечивая более простой синтаксис,^{[нужна цитата]} но коммерческая поддержка программного обеспечения идет медленно.

Безопасность

XML DTD может использоваться для создания атаки типа «отказ в обслуживании» (DoS) путем определения вложенных сущностей, которые расширяются экспоненциально, или путем отправки синтаксического анализатора XML на внешний ресурс, который никогда не возвращается.^[10]

По этой причине .NET Framework предоставляет свойство, которое позволяет запрещать или пропускать анализ DTD,^[10] а последние версии приложений Microsoft Office (Microsoft Office 2010 и выше) отказываются открывать файлы XML, содержащие объявления DTD.

Смотрите также

• Семантическая сеть
• Сравнение языков схемы XML - Сравнение с другими языками схем XML.
• Схема XML (W3C)

Рекомендации

внешняя ссылка

• Определение объявления типа XML-документа из Extensible Markup Language (XML) 1.0 (четвертое издание) на W3.org

Эта статья требует дополнительных или более конкретных категории. Пожалуйста помочь к добавление категорий к нему, чтобы его можно было перечислить с аналогичными статьями. (Июнь 2020 г.)