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

DTD Определение типа документа ( , ) — это файл спецификации, который содержит набор объявлений разметки определяющих тип документа для SGML семейства языка разметки ( GML , SGML , XML , HTML ). Файл спецификации DTD можно использовать для проверки документов.

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

Версия DTD с поддержкой пространства имен разрабатывается как Часть 9 ISO DSDL . DTD сохраняются в приложениях, которым требуются специальные публикуемые символы, такие как ссылки на символьные сущности XML и HTML , которые происходят из более крупных наборов, определенных как часть стандарта ISO SGML . XML использует подмножество SGML DTD.

По состоянию на 2009 год ^[update], новые пространство имен XML , учитывающие языки схем (такие как W3C XML Schema и ISO RELAX NG ), в значительной степени вытеснили DTD как лучший способ проверки структуры XML.

Связывание DTD с документами [ править ]

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

DOCTYPE делают два типа объявлений:

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

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

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

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

Примеры [ править ]

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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

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

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

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

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

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

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

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

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

Объявления разметки [ править ]

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

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

Объявления типов элементов [ править ]

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

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

EMPTY для указания того, что определенный элемент не допускает содержания, т. е. у него не может быть никаких дочерних элементов, даже текстовых элементов (если есть пробелы, они игнорируются);
ANY для указания того, что определенный элемент допускает любое содержимое без ограничений, т.е. что он может иметь любое количество (в том числе отсутствие) и тип дочерних элементов (включая текстовые элементы);
или выражение, определяющее единственные элементы, разрешенные в качестве прямых дочерних элементов в содержимом определенного элемента; этот контент может быть:
- смешанный контент , что означает, что контент может включать в себя как минимум один текстовый элемент и ноль или более именованных элементов, но их порядок и количество вхождений не могут быть ограничены; это может быть:
  - ( #PCDATA ): исторически означает анализируемые символьные данные . Это означает, что в содержимом разрешен только один текстовый элемент (квантор не допускается);
  - ( #PCDATA | ''element name'' | ... )*: ограниченный выбор (в эксклюзивном списке в круглых скобках и через " |" символы вертикальной черты и завершаются требуемым " *Квантор ") двух или более дочерних элементов (включая только текстовые элементы или указанные именованные элементы) может использоваться в любом порядке и количестве вхождений в контенте.
- элемент content , что означает, что в дочерних элементах содержимого не должно быть текстовых элементов (все пробелы, закодированные между дочерними элементами, игнорируются, как и комментарии). Содержимое такого элемента указывается как частица содержимого в варианте формы Бэкуса-Наура без терминальных символов и имен элементов как нетерминальных символов. Содержимое элемента состоит из:
  - частицей контента может быть либо имя элемента, объявленное в DTD, либо список последовательностей или список выбора . За ним может следовать необязательный квантификатор .
    - список последовательностей означает упорядоченный список (указанный в круглых скобках и разделенный знаком "). ,«символ запятой) одной или нескольких частиц контента : все частицы контента должны последовательно появляться как прямые дочерние элементы в содержимом определенного элемента, в указанной позиции и относительном порядке;
    - список выбора означает взаимоисключающий список (указанный в круглых скобках и разделенный знаком " |«символ трубы) из двух или более частиц контента : только одна из этих частиц контента может появляться в содержимом определенного элемента в одной и той же позиции.
  - Квантор — это одиночный символ , который следует сразу за указанным элементом, к которому он применяется, чтобы ограничить количество последовательных вхождений этих элементов в указанную позицию в содержимом элемента; это может быть либо:
    - + для указания того, что должно быть одно или несколько вхождений элемента — фактическое содержание каждого вхождения может быть разным;
    - * для указания того, что разрешено любое количество (ноль или более) вхождений — элемент не является обязательным, и фактическое содержание каждого вхождения может быть разным;
    - ? для указания того, что вхождений должно быть не более одного — пункт не является обязательным;
    - Если квантор отсутствует, указанный элемент должен встретиться ровно один раз в указанной позиции в содержимом элемента.

Например:

<!ELEMENT html (head, body)>
<!ELEMENT p (#PCDATA | p | ul | dl | table | h1|h2|h3)*>

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

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

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

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

Например:

<!ATTLIST img
   src    CDATA          #REQUIRED
   id     ID             #IMPLIED
   sort   CDATA          #FIXED "true"
   print  (yes | no) "yes"
>

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

CDATA: этот тип означает символьные данные и указывает, что эффективным значением атрибута может быть любое текстовое значение, если только атрибут не указан как фиксированный (комментарии в DTD могут дополнительно документировать значения, которые эффективно принимаются, но синтаксис DTD не допускает такого точная спецификация);
ID: эффективное значение атрибута должно быть допустимым идентификатором, и оно используется для определения и привязки к текущему элементу цели ссылок, использующих этот определенный идентификатор (включая идентификаторы фрагментов документа , которые могут быть указаны в конце URI после " #" знак); если разные элементы в одном документе определяют один и тот же идентификатор, это ошибка; ограничение уникальности также подразумевает, что сам идентификатор не несет никакой другой семантики и что идентификаторы должны рассматриваться в приложениях как непрозрачные; XML также предопределяет стандартный псевдоатрибут " xml:id" с этим типом, без необходимости какого-либо объявления в DTD, поэтому ограничение уникальности также применяется к этим определенным идентификаторам, когда они указаны где-либо в XML-документе.
IDREF или IDREFS: эффективное значение атрибута может быть только допустимым идентификатором (или списком таких идентификаторов, разделенных пробелами) и должно ссылаться на уникальный элемент, определенный в документе с атрибутом, объявленным с типом ID в DTD (или уникальном элементе, определенном в XML-документе с псевдоатрибутом " xml:id") и чьим эффективным значением является тот же идентификатор;
NMTOKEN или NMTOKENS: эффективным значением атрибута может быть только действительный токен имени (или список таких токенов имени, разделенный пробелами), но оно не ограничивается уникальным идентификатором в документе; это имя может нести дополнительную и зависящую от приложения семантику и может требовать дополнительных ограничений именования, но это выходит за рамки DTD;
ENTITY или ENTITIES: эффективным значением атрибута может быть только имя неанализируемой внешней сущности (или список таких имен, разделенных пробелами), которое также должно быть объявлено в объявлении типа документа; этот тип не поддерживается в анализаторах HTML, но допустим в SGML и XML 1.0 или 1.1 (включая XHTML и SVG);
(value1|...): эффективное значение атрибута может быть только одним из нумерованного списка (указанного в круглых скобках и разделенного знаком "). |"символ вертикальной черты) текстовых значений, где каждое значение в перечислении может быть указано между 'одинокий ' или "двойной " кавычки, если это не простой токен имени;
NOTATION (notation1|...): эффективным значением атрибута может быть только любое из нумерованного списка (указанного в круглых скобках и разделенного знаком "). |"символ вертикальной черты) имен нотаций, где каждое имя нотации в перечислении также должно быть объявлено в объявлении типа документа; этот тип не поддерживается в анализаторах HTML, но действителен в SGML и XML 1.0 или 1.1 (включая XHTML и SVG) .

Значение по умолчанию может определять, должен ли атрибут присутствовать ( #REQUIRED) или нет ( #IMPLIED), или имеет ли оно фиксированное значение ( #FIXED) или какое значение следует использовать в качестве значения по умолчанию («…») в случае, если данный атрибут не указан в теге XML.

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

Объявления сущностей [ править ]

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

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

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

<!DOCTYPE sgml [
  <!ELEMENT sgml ANY>
  <!ENTITY % std       "standard SGML">
  <!ENTITY % signature " &#x2014; &author;.">
  <!ENTITY % question  "Why couldn&#x2019;t I publish my books directly in %std;?">
  <!ENTITY % author    "William Shakespeare">
]>

<sgml>&question;&signature;</sgml>

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

<!DOCTYPE sgml [
  <!ELEMENT sgml ANY>
  <!ENTITY % std       "standard SGML">
  <!ENTITY % signature " — &author;.">
  <!ENTITY % question  "Why couldn’t I publish my books directly in standard SGML?">
  <!ENTITY % author    "William Shakespeare">
]>

<sgml>Why couldn’t I publish my books directly in standard SGML? — William Shakespeare.</sgml>

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

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

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

Объявления обозначений [ править ]

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

<!NOTATION type-image-svg SYSTEM "image/svg">

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

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

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

<!DOCTYPE sgml [
  <!ELEMENT sgml (img)*>

  <!ELEMENT img EMPTY>
  <!ATTLIST img
     data ENTITY #IMPLIED>

  <!ENTITY   example1SVG     SYSTEM "example1.svg" NDATA example1SVG-rdf>
  <!NOTATION example1SVG-rdf SYSTEM "example1.svg.rdf">
]>

<sgml>
  <img data="example1SVG" />
</sgml>

В теле документа SGML эти внешние объекты, на которые имеются ссылки (имя которых указано между «&» и «;»), не заменяются, как обычные именованные объекты (определяемые значением CDATA), а остаются как отдельные неанализируемые токены, которые могут использоваться либо как значение атрибута элемента (как указано выше), либо внутри содержимого элемента, при условии, что либо DTD допускает использование таких внешних объектов в объявленном типе содержимого элементов, либо в объявленном типе атрибутов (здесь ENTITY тип для data атрибут), или анализатор SGML не проверяет содержимое.

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

<!DOCTYPE sgml [
  <!ELEMENT sgml (img)*>
   <!--
     the optional "type" attribute value can only be set to this notation.
   -->
  <!ATTLIST sgml
    type  NOTATION (
      type-vendor-specific ) #IMPLIED>

  <!ELEMENT img ANY> <!-- optional content can be only parsable SGML or XML data -->
   <!--
     The optional "title" attribute value must be parsable as text.
     The optional "data" attribute value is set to an unparsed external entity.
     The optional "type" attribute value can only be one of the two notations.
   -->
  <!ATTLIST img
    title CDATA              #IMPLIED
    data  ENTITY             #IMPLIED
    type  NOTATION (
      type-image-svg |
      type-image-gif )       #IMPLIED>

  <!--
    Notations are referencing external entities and may be set in the "type" attributes above,
    or must be referenced by any defined external entities that cannot be parsed.
  -->
  <!NOTATION type-image-svg       PUBLIC "-//W3C//DTD SVG 1.1//EN"
     "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
  <!NOTATION type-image-gif       PUBLIC "image/gif">
  <!NOTATION type-vendor-specific PUBLIC "application/VND.specific+sgml">

  <!ENTITY example1SVGTitle "Title of example1.svg"> <!-- parsed internal entity -->
  <!ENTITY example1SVG      SYSTEM "example1.svg"> <!-- parsed external entity -->
  <!ENTITY example1GIFTitle "Title of example1.gif"> <!-- parsed internal entity -->
  <!ENTITY example1GIF      SYSTEM "example1.gif" NDATA type-image-gif> <!-- unparsed external entity -->
]>

<sgml type="type-vendor-specific">
  <!-- an SVG image is parsable as valid SGML or XML text -->
  <img title="&example1SVGTitle;" type="type-image-svg">&example1SVG;</img>

  <!-- it can also be referenced as an unparsed external entity -->
  <img title="&example1SVGTitle;" data="example1SVG" />

  <!-- a GIF image is not parsable and can only be referenced as an external entity -->
  <img title="&example1GIFTitle;" data="example1GIF" />
</sgml>

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

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

Содержимое элемента «img» ссылается на другой внешний объект «example1SVG», объявление которого также не определяет нотацию, поэтому оно также анализируется проверяющими анализаторами, а текст замены объекта находится по его определенному СИСТЕМНОМУ идентификатору «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:''name''" значение стандартного атрибута CDATA, везде можно указать URI. Однако такое поведение зависит от приложения и требует, чтобы приложение поддерживало каталог известных URN для преобразования их в нотации, которые были проанализированы стандартным анализатором SGML или XML. Такое использование позволяет определять нотации только в DTD, хранящемся как внешний объект и на которое ссылаются только как на внешнее подмножество документов, а также позволяет этим документам оставаться совместимыми с проверяющими анализаторами XML или SGML, которые не имеют прямой поддержки нотаций.

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

На все внешние объекты, используемые этими стандартными типами документов, ссылаются простые атрибуты, объявленные с типом CDATA в их стандартном DTD (например, атрибут «href» привязки элемента «a» или атрибут «src» изображения «). img», значения которого интерпретируются как URI, без необходимости какого-либо каталога общедоступных идентификаторов, т. е. известного FPI)
На все внешние объекты для дополнительных метаданных ссылаются либо:
- Дополнительные атрибуты (например , type , который указывает тип MIME внешнего объекта, или атрибут charset , который указывает его кодировку)
- Дополнительные элементы (например, ссылка или мета в 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-документы с помощью непроверяющих анализаторов XML (если единственной целью внешнего подмножества DTD было определение схемы). Кроме того, документы для этих языков схемы XML должны анализироваться отдельно, поэтому проверка схемы документов XML в чисто автономном режиме на этих языках на самом деле невозможна: объявление типа документа остается необходимым, по крайней мере, для идентификации (с помощью каталога XML ) схема, используемая в анализируемом XML-документе и проверенная на другом языке.

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

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

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

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

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

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

Пример схемы XML DTD [ править ]

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

<!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 элементы. * означает, что может быть 0 или более person элементы внутри people_list элемент.
person является допустимым именем элемента, и экземпляр такого элемента содержит один элемент с именем name, за которым следует один с именем birthdate (необязательно), затем gender (также необязательно) и socialsecuritynumber (также по желанию). ? указывает, что элемент является необязательным. Ссылка на name имя элемента не имеет ?, так что person элемент должен содержать name элемент.
name — допустимое имя элемента, и экземпляр такого элемента содержит «проанализированные символьные данные» (#PCDATA).
birthdate — допустимое имя элемента, и экземпляр такого элемента содержит проанализированные символьные данные.
gender — допустимое имя элемента, и экземпляр такого элемента содержит проанализированные символьные данные.
socialsecuritynumber — допустимое имя элемента, и экземпляр такого элемента содержит проанализированные символьные данные.

Ниже приведен пример 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>Fred Bloggs</name>
    <birthdate>2008-11-27</birthdate>
    <gender>Male</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"?>
<!DOCTYPE people_list [
  <!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>Fred Bloggs</name>
    <birthdate>2008-11-27</birthdate>
    <gender>Male</gender>
  </person>
</people_list>

Альтернативы [ править ]

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

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

Безопасность [ править ]

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

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

См. также [ править ]

JATS (набор тегов для статей в журнале)
Семантическая сеть
XML-схема (W3C)
Сравнение языков XML-схем – сравнение с другими языками XML-схем.

Ссылки [ править ]

^ «Введение в DTD» .
^ "доктайпдекл" . Расширяемый язык разметки (XML) 1.1 . W3C.
^ Ватт, Эндрю Х. (2002). Сэмс выучит XML за 10 минут . Издательство Самс. ISBN 9780672324710 .
^ Объявление списка атрибутов , Спецификации расширяемого языка разметки (XML) 1.1, W3C.
^ «Субъекты DTD» . Учебное пособие по DTD . W3Школы.
^ Объявления нотаций , Спецификации расширяемого языка разметки (XML) 1.0, W3C.
^ Объявления нотаций , Спецификации расширяемого языка разметки (XML) 1.1, W3C.
^ «XML-схема, часть 1: Структуры (второе издание)» . W3C. 2004 . Проверено 02 января 2022 г.
^ «ISO/IEC 19757-2:2008. Информационные технологии. Язык определения схемы документа (DSDL). Часть 2. Проверка на основе регулярной грамматики. RELAX NG» . ИСО . Проверено 17 мая 2011 г.
↑ Перейти обратно: Перейти обратно: ^а ^б Брайан Салливан (ноябрь 2009 г.). «Атаки и защита от отказа в обслуживании XML» . Журнал MSDN . Проверено 21 октября 2013 г.

Внешние ссылки [ править ]

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

[1] «Введение в DTD» .

[W3C,_doctypedecl-2] "доктайпдекл" . Расширяемый язык разметки (XML) 1.1 . W3C.

[3] Ватт, Эндрю Х. (2002). Сэмс выучит XML за 10 минут . Издательство Самс. ISBN 9780672324710 .

[4] Объявление списка атрибутов , Спецификации расширяемого языка разметки (XML) 1.1, W3C.

[5] «Субъекты DTD» . Учебное пособие по DTD . W3Школы.

[6] Объявления нотаций , Спецификации расширяемого языка разметки (XML) 1.0, W3C.

[7] Объявления нотаций , Спецификации расширяемого языка разметки (XML) 1.1, W3C.

[8] «XML-схема, часть 1: Структуры (второе издание)» . W3C. 2004 . Проверено 02 января 2022 г.

[9] «ISO/IEC 19757-2:2008. Информационные технологии. Язык определения схемы документа (DSDL). Часть 2. Проверка на основе регулярной грамматики. RELAX NG» . ИСО . Проверено 17 мая 2011 г.

[XMLDenial-10] Перейти обратно: Перейти обратно: ^а ^б Брайан Салливан (ноябрь 2009 г.). «Атаки и защита от отказа в обслуживании XML» . Журнал MSDN . Проверено 21 октября 2013 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]