Язык xml documents type definitions (dtd)


Содержание

Язык XML — практическое введение

. Documents Type Definitions (DTD)

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

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

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

Внутри же документа DTD- декларации включаются следующим образом:

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

Определение элемента

Элемент в DTD определяется с помощью дескриптора ! ELEMENT , в котором указывается название элемента и структура его содержимого.

Например, для элемента можно определить следующее правило:

Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML. Внутри этой инструкции задается название элемента(flower) и тип его содержимого.

В определении элемента мы указываем сначала название элемента(flower), а затем его модель содержимого — определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA( что означает parseable character data — любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY,ANY. Первая указывает на то, что элемент должен быть пустым(например, ), вторая — на то, что содержимое элемента специально не описывается.

Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ? :

В этом примере указывается, что внутри элемента должны быть определены элементы title, author и table-of-contents, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа «|» :

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

Если в определении элемента указывается «смешанное» содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA, а затем разделенный символом «|» список элементов.

Пример корректного XML- документа:

Определение атрибутов

Списки атрибутов элемента определяются с помощью ключевого слова ! ATTLIST . Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента могут быть определены следующие атрибуты:

В данном примере для элемента article определяются три атрибута: id, about и type , которые имеют типы ID(идентификатор), CDATA и список возможных значений соответственно. Всего существует шесть возможных типов значений атрибута:

CDATA — содержимым документа могут быть любые символьные данные

ID — определяет уникальный идентификатор элемента в документе

IDREF( IDREFS )- указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента

ENTITY( ENTITIES) — значение атрибута должно быть названием(или списком названий, если используется ENTITIES) компонента (макроопределения), определенного в документе

NMTOKEN (NMTOKENS) — содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA)

Список допустимых значений — определяется список значений, которые может иметь данный атрибут.

Также в определении атрибута можно использовать следующие параметры:

#REQUIRED — определяет обязательный атрибут, который должен быть задан во всех элементах данного типа

#IMPLIED — атрибут не является обязательным

#FIXED «значение» — указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору

Значение — задает значение атрибута по умолчанию

Определение компонентов(макроопределений)

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

Программа-анализатор, просматривая в первую очередь содержимое области DTD- определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD- компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello; , которое будет заменено на строчку «Мы рады приветствовать Вас»

В общем случае, внутри DTD можно задать три типа макроопределений:

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

В XML существует пять предустановленных внутренних символьных констант:

» — символ двойной кавычки «»»

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

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

Например, для следующего фрагмента документа:

можно использовать более короткую форму записи:

Макроопределения часто используются для описания параметров в правилах атрибутов. В этом случае появляется возможность использовать одинаковые определения атрибутов для различных элементов:

Типизация данных

Довольно часто при создании XML- элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент 10.10.98 , то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL- запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL-запрос.

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

Задав атрибуту значение по умолчанию LONG и определив его как FIXED, мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD- определении .

Вот пример XML- документа, в котором определяются и используются несколько элементов с различными типами данных:

Как видно из примера, механизм создания элементов документа при этом нисколько не изменился. Все необходимая для проверки типов данных информация заложена в определения элементов внутри блока DTD.

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

Назад | Содержание | Вперед

5. Схемы данных

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

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

В настоящее время в W3 консорциуме идет работа над первой спецификацией схем данных, рабочий ее вариант сейчас доступен на сервере [ 36 ]. В этом разделе мы рассмотрим основные возможности схем данных, попытаемся использовать их для проверки корректности ранее описываемых XML- документов.

Как это выглядит

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

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

, а некорректным этот:

Все конструкции языка схем описываются правилами «XML DTD for XML-Data-Schema». Этот документ вы можете найти среди другой официальной документации, доступной на сервере W3 — консорциума. В этой статье мы коснемся лишь основных приемов для работы со схемами данных. Ссылки на более подробные источники приведены в конце.

Область схемы данных

Создавая схемы данных, мы определяем в документе специальный элемент, ;, внутри которого содержатся описания правил:

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

Описание элементов

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

Элемент содержит информацию об очередном выпуске журнала

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

Как видно из примера, при определении класса элемента, можно также использовать комментарии к нему, которые заключаются в тэги descript>

Атрибуты элемента

Для того, чтобы в описании элемента определить его атрибуты и описать свойства этих атрибутов мы должны использовать элемент attribute :

В данном примере элементу

определяется атрибут src , значением которого может быть любая последовательность разрешенных символов:

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

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

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

Для приведенных примеров корректным будет являться следующий фрагмент XML-документа:

Модель содержимого элемента

Под моделью содержимого в схеме данных понимают описание всех допустимых объектов XML- документа, использование которых внутри данного элемента является корректным. Модель содержимого определяется инструкциями, расположенными внутри блока .

Для этого правила корректным будет являться следующий фрагмент документа:

Психи и маньяки в Интернет

Вложенные элементы описываются при помощи инструкции element , в которой параметром type указывается класс объекта — ссылка на его определение:

Если требуется указать режим использования вложенного элемента, то надо определить параметр occurs :

Возможные значения этого параметра таковы:

REQUIRED — элемент должен быть обязательно определен

OPTIONAL — использование элемента не является обязательным

ZEROORMORE — вложенный элемент может встречаться несколько раз или ни разу

ONEORMORE — элемент должен встречаться хотя бы один раз

Примеры правильных XML-документа, использующих приведенную выше схему:

Зачем он нужен, XML?

нужен ли он нам

Зачем он нужен, XML?

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

— указывает на то, что содержимым элемента является только свободная текстовая информация(секция PCDATA) :

Язык xml documents type definitions (dtd)

В спецификация XML 1.0 указывается, что логическую структуру XML-документа (подробности об XML см. в Кратком введении в XML) можно описать с помощью языка Определений Типов Документов — Document Type Definition (DTD) http://www.w3.org/TR/REC-xml#dt-doctype. В DTD используется формальная грамматика, позволяющая определить как структуру документа, так и допустимые значения. При обработке документов, если с ними будут ассоциированы правила, оформленные на языке DTD, анализаторы могут проверять данные на их соответствие с описаниями, тем самым сигнализировать о наличие структурных ошибок в данных XML-документов.

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

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

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

Ассоциирование DTD с XML-документом.

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

Декларация DOCTYPE представляет из себя тег следующей структуры:

  • Name — имя элемента документа (element document), т.е. единственный элемента, подчинённые элементы которого, включают прикладные данные XML-документа (см. Тело документа во Введении в XML).
  • ExternalID — если присутствует, то указывает на внешний источник, содержащий DTD-определения. В этих случаях говорят, что документ имеет внешние определения. ExternalID может быть в двух формах:
    • ‘SYSTEM’ SystemLiteral — здесь SystemLiteral представляет из себя универсальный идентификатор ресурса (Uniform Resource Identifier [URI]), причём реально содержащий DTD-определения по этому адресу. Например: .
    • ‘PUBLIC’ PubidLiteralSystemLiteral — здесь PubidLiteral представляет из себя «хорошо известный» универсальный идентификатор ресурса. и в этом случае анализатор может найти соответствующие DTD-определения любым, наиболее приемлемым для анализатора способом. Таким образом, PubidLiteral — это просто уникальный идентификатор, обычно обозначающий хорошо известный стандарт, и не обязана реально содержать DTD-определений. Если в определении присутствует SystemLiteral, то этот URI обязан содержать реальный файл с DTD-определенеиями (по существу тоже что и SystemLiteral в ‘SYSTEM’, описанным выше). Если по указанному URI файл определений не будет найден, то приложение запросит именованный файл с Web-сервера. Например:

    управление же тем: будут ли реально внешние DTD-определения обработаны в XML-документе, осуществляется XML-декларацией standalone (см. XML-декларации во Введении в XML). И её значение «no» предписывает анализатору использовать внешние DTD-определения при обработке XML-документа, в то время как «yes» указывает на обработку документа без учёта внешних DTD-определий.

  • MarkupDecl — если присутствует, то имеет формат: [ markupdecl ] и сдержит DTD-определения или DTD-деклорации. В этих случаях говорят, что документ содержит внутренние определения.

Декларации в DTD.

Допустимое в XML-содержание определяется следующими декларациями в DTD:

Конструкция в DTD Назначение
ELEMENT — декларации типа элемента XML
ATTLIST — декларации атрибутов, могут быть назначены конкретным элементам, а также определить разрешённые значения атрибутов
ENTITY — декларации повторно используемого содержания
NOTATION — декларации определяют внешнее содержание

ELEMENT.

Элемент является основным объектом языка XML, в DTD элемент объявляется с помощью тега ELEMENT и имеет следующую структуру:

Name — имя типа элемента. На имя типа элемента накладываются следующие ограничения, всегда применяемые к именам в XML (см. также Имена во Введении в XML): имена могут содержать буквы, цифры, двоеточия (‘:’), символ нижнего подчёркивания (‘_’), дефис (тире или знак минуса) (‘-‘) и точку (‘.’), но не могут начинаться с цифры. Они должны начинаться только с буквы, знака подчёркивания или двоеточия.

contentspec — определяет содержание элемента и может быть:

  • EMPTY — в случае когда содержание элемента обязано быть всегда пустым, в т.ч. не включать в себя порождённые элементы, однако такой элемент может иметь атрибуты.
  • ANY — когда в качестве содержания элемента может быть всё что угодно.
  • содержание элемента определяется формальным правилом, т.н. моделью содержания(content model)

В последнем случае различают две модели содержания:

  • только порождённые элементы (Children) — содержанием элемента является набор порождённых элементов, но не текст.
  • смешанное содержание (Mixed) — означает, что в качестве содержания могут быть: порождённые элементы, анализируемые символьные данные (#PCDATA) и текст.

Формальные правила, с помощью которых определяют содержание элемента, очень похожи на те, которые используются в расширенных формах Бэкуса-Наура (Extended Backus-Naur Form — EBNF) при определении синтаксиса в языках программирования.

Определение порядка и выбор элементов

В таблице ниже представлены символы-разделители между элементами:

Символ Назначение
, — определяет последовательность
| — указывает на выбор одного из

При помощи первого (символ запятая ‘,’), элементы можно объединить в последовательность, создав список элементов. Например:

Повторяемость элементов.

Повторяемость элемента или группы элементов (определитель множественности или кардинальность), задаётся следующими символами:

Символ Назначение
? — не обязательный, может отсутствовать
* — ноли или больше
+ — один или больше

Отсутствие символа повторяемости указывает, что элемент должен присутствовать, причём только один раз. Символ повторяемость ставится сразу за названием элемента или сразу за закрывающей круглой скобкой группы элементов. Вот пример с использованием символов повторяемости:

и эта группа модели содержания означает, что наша корзина может содержать один или несколько элементов Cherry, после которых следует ноль или больше экземпляров выбора между элементами Apple и Orange. Обратите внимание, что элементы Cherry должны быть расположены вместе. Ниже пример данных, удовлетворяющий такой декларации:

Вот ещё несколько примеров определений элементов:

здесь определено, что элемент foo может содержать от одного до четырёх порождённых элементов, в зависимости от сделанного выбора, причём первым может быть A, B или D (элемент A не обязателен), затем появляется B и C, или D, в завершении E (элемент E не обязателен).

здесь за элементом A следует ноль или больше пар B и C, а в конце по крайней мере один элемент D.

Для того, чтобы указать на смешанное содержание, в модель содержания введено ключевое слово #PCDATA. В этом случае элементы модели содержания следует разделять символом | и у группы в целом объявить множественность «ноли или больше»:

Ниже пример данных, удовлетворяющий такому описанию:

Нужно также иметь ввиду, что один и тот же элемент не может быть объявлен более чем один раз.

ATTLIST.

Атрибуты, подобны свойствам в ООП у классов, и информационно дополняют XML-элементы (см. также раздел Атрибут во Введении в XML). Объявления атрибутов DTD имеют следующую структуру:

где ElementName — имя элемента, для которого объявляются атрибуты, а AttDef имеет следующую структуру:

здесь AttName — имя атрибута, AttType — тип атрибута, а DefaultDecl — значение атрибута. На имя атрибута наложены такие же ограничения, что и имя XML-элемента (см. в разделе ELEMENT данного документа, а также раздел Имена во Введении в XML).

Типы атрибутов.


Тип атрибута (AttType) может быть одним из следующих:

Тип Назначение
CDATA — символьные данные
ID — уникальный идентификатор
IDREF — ссылка на уникальный идентификатор
IDREFS — набор ссылок на уникальные идентификаторы
ENTITY — сущность (или замещаемое содержание)
ENTITIES — набор сущностей
NMTOKEN — именной токен
NMTOKENS — набор именных токенов
NOTATION — один из типов нотаций
[явное перечисление] — перечисление возможных значений атрибутов

Следует сделать несколько пояснений к типам атрибутов:

  • Символьные данные — в качестве значения атрибута может использоваться строка произвольной длины с символьными данными, допустимыми в XML (см. раздел Символьные данные во Введении в XML).
  • Уникальный идентификатор — атрибуты типа ID обязаны содержать уникальные значения в рамках документа, таким образом, являются аналогами Primary ключей в реляционных базах данных, однозначно идентифицируя каждый конкретный элемент. Тип ID может быть использован для создания кросс-ссылок между элементами, если информационные связи между элементами выходят за рамки нормальной древовидной структуры документа. В этом случае, уникальные значения в атрибуте типа ID могут быть использованы в атрибутах типа IDREF и/или IDREFS. Также, в языке XPath есть функция id [node-set id(object)], возвращающая множество узлов документа, у которых значение атрибута типа ID совпадает со значением, переданным в качестве параметра. И для использования этой функции, необходимо предварительно определить атрибут(ы) типа ID с применением языка DTD для XML-документа.
  • Сущность (или замещаемое содержание) — применяется для повторного использования некоторых конструкций, предварительно объявив их как сущности, или для ссылок на не анализируемых в рамках XML данные, например файлы изображений (см. также раздел ENTITY данного документа).
  • Именной токен — при необходимости использовать в качестве значений атрибутов некоторый фиксированный набор значений, обычно используют «явное перечисление». Однако, если полный список такого перечисления не может быть известен заранее, — применяют тип NMTOKEN. И в этом случае, в качестве значения атрибута, можно использовать произвольные имена, допустимые в рамках XML (см. раздел Имена во Введении в XML), правда для такого типа отсутствуют ограничения на первый символ.
  • Один из типов нотаций — средствами определений нотаций (см. раздел NOTATION данного документа) могут быть определены приложения для обработки содержимого элементов, у которых атрибут подобного типа использован.

Значения атрибутов.

DefaultDecl — определяет: как и какие значения должны быть присвоены атрибуту. В качестве значений могут быть:

Значение Назначение
#REQUIRED — атрибут должен всегда присутствовать в каждом элементе и иметь значение
#IMPLIED — атрибут является не обязательным и может отсутствовать в элементе
#FIXED + значение — определяет атрибут, всегда имеющий одно и тоже значение
значение — значение, заключённое в кавычки, определяет значение по умолчанию

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

определяет для элемента product следующие атрибуты:

Атрибут Требования к значению
title — обязательный атрибут, содержащий символьные данные
id — необязательный атрибут, который может содержать уникальный идентификатор элемента внутри документа
type — обязательный атрибут, значение которого произвольно, но обязано удовлетворять правилам имён в XML для типа NMTOKEN (например type=»сыпучий»)
quantity — определяет атрибут, который может и не присутствовать в элементе, в этом случае подразумевается, что его значение равно «1»
value — определяет атрибут, который всегда должен иметь значение «дорого»
color — определяет атрибут, имеющий одно из значений: «серый» или «белый», причём по умолчанию — «серый»

ENTITY.

Часто используемы конструкции языка или внешние данные, могут быть предварительно объявлены как сущности, а затем использованы в документе. Имеется два вида сущностей: внутренние и внешние.

Внутренняя сущность.

Внутренняя сущность используется (в том числе и в значениях атрибутов) для повторного использования одних и тех же конструкций. Так, если одна и та же конструкция используется несколько раз, то можно объявить представляющую её сущность, а затем ссылаться на последнюю везде, где возникает необходимость в конструкции (см. также раздел Ссылки во Введении в XML). Близким аналогом таких сущностей являются макроподстановки в некоторых языках программирования. Например, объявление сущности animal:

позволяет в дальнейшем её использовать (в том числе и в атрибутах) подобно:

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

после предварительного объявления сущности coords:

может быть записано следующим образом:

в то время как использование параметризованных сущностей в атрибутах аналогично показанному выше.

Внешняя сущность.

Объявление внешней сущности имеет вид:

External PubidLiteral SystemLiteral
NDataDecl ::= ‘NDATA’ Name

  • SystemLiteral — URL, т.е. определяет ссылку на реально существующий внешний файл.
  • PubidLiteral — URI, т.е. представляет из себя «хорошо известный» идентификатор ресурса, не обязательно реально существующий.
  • NDataDecl — если присутствует, означает внешнюю не разбираемую сущность.

Следует также отметить, что:

  • для PUBLIC наличие второго параметра (SystemLiteral) не обязательно, однако если он присутствует, то должен указывать на реально существующий ресурс.
  • присутствие NDataDecl означает также, что должно быть определено приложение-обработчик для не разбираемой сущности. В DTD это делается с помощью определения нотаций (см. также раздел NOTATION данного документа).

Рассмотрим несколько примеров, поясняющих использование внешних сущностей.

В данном случае определена внешняя разбираемая сущность (содержимое файла animal.ent с указанным относительным его расположением) и использование ссылки на сущность &animal; в любом месте XML документа будет приводить к замене ссылки сущности на содержимое указанного файла.

Это также определение внешней разбираемой сущности, однако теперь, специализированный анализатор для зоологических XML-файлов, встретив публичную и известную ему ссылку «-//ZOO//Elephant/Description», может и не загружать определение, находящееся по адресу http://enimalhost.com/animal.ent непосредственно с сервера. Как именно в данном случае определить сущность animal — ложится на плечи анализатора. Однако в любом случае, она (сущность animal) при использовании данного объявления должна быть корректно определена.

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

NOTATION.

XML-анализаторы не имеют средств по обработке двоичных файлов непосредственно. Что же делать, если мы в документе желаем использовать данные в формате двоичных файлов? Чтобы обойти эту проблему в XML используются объявления нотаций, которые позволяют связать названия форматов с внешними приложениями-обработчиками (helper application) для файлов этих форматов. Формально определение нотаций имеет вид:

здесь ExternalID по своей структуре полностью аналогичен тому, что и во Внешней сущности у ENTITY, т.е.:

External PubidLiteral SystemLiteral

и определяет приложение-обработчик двоичных файлов для типа TypeName. Если в XML-документе использованы несколько различных форматов двоичных файлов (т.е. определёны как внешние сущности с применением NDATA у ENTITY), то при помощью этого определения необходимо указать соответствующие приложения-обработчики каждому из типов.

Применяя NOTATION, имеется две возможности обработки двоичных файлов в XML.

В первом вариант требуется:

  • объявления для всех двоичных файлов как не разбираемых сущностей ENTITY, с указанием типов (используя NDATA)
  • определения каждому из типов (использованных в NDATA у ENTITY) соответствующие приложения-обработчики (применяя NOTATION)

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

Зачем нужно DTD.

Создавая XML документ разработчик сам решает: как назвать теги, в каком порядке они будут следовать, какие данные будут записаны в том или ином элементе, будут ли у элемента атрибуты или нет и многое другое. Без формального описания структуры документа этим самым документом может воспользоваться только его разработчик. В случае если разработанный XML документ предназначен для передачи во внешний мир, например партнерам по бизнесу, и если к тому же планируется получать в ответ документы, написанные в том же самом формате без определения типов документов ( Document Type Definition , DTD ) не обойтись. Это связано с тем, что для того, что бы обе стороны могли понимать полученную информацию элементы и атрибуты в документах должны употребляться всеми сторонами одинаково. Определения типа документа вносят строгость и точность в правила написания правильно оформленных документов XML . Хранимые в начале файла XML или внешним образом в виде файла *.DTD , определения типов документов описывают информационную структуру документа. В DTD перечисляются возможные имена элементов, определяются имеющиеся атрибуты для каждого типа элементов и описывается вложенность элементов.

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

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

Написание определений DTD: общие принципы.

Ассоциирование DTD с документом XML

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

Декларация DOCTYPE содержит ключевое слово DOCTYPE , за которым следует имя корневого элемента документа, а затем конструкция с декларациями содержания. Перед разъяснением этого утверждения рассмотрим пример расположения декларации DOCTYPE в экземпляре документа. Ниже приводятся первые три строчки документа XML:

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

Декларации XML могут содержать атрибут standalone, принимающий только значения «yes» и «nо». Если значение атрибута равно yes, то внешние для экземпляра документа декларации не влияют на информацию, передаваемую документом использующему его приложению. Значение no показывает, что существуют внешние декларации со значениями, необходимыми для правильного описания содержания документа — например конкретные значения по умолчанию. На практике необязательный атрибут standalone используется редко. Наличие этого атрибута со значением, yes не гарантирует отсутствия внешних зависимостей любого типа. Просто внешние зависимости в этом случае не приведут к ошибке в документе, если не будут включены в обработку. Таким образом, в основном этот атрибут представляет собой знак для анализаторов и других приложений, показывающий, нужно ли им использовать какое-либо внешнее содержание.

Блок внутренней декларации разметки тега DOCTYPE состоит из левой квадратной скобки, списка деклараций и правой квадратной скобки:

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

Внешние DTD в некоторых отношениях более гибкие. В данном случае декларация DOCTYPE состоит из обычного ключевого слова и имени корневого элемента, за которым следует еще одно ключевое слово SYSTEM либо PUBLIC , обозначающее источник внешнего определения DTD , а за ним — локализация этого определения. Если ключевое слово SYSTEM , DTD обязано непосредственно и явным образом находится по указанному URL адресу.

Если внешние DTD переписываются очень часто, они начинают терять свое значение, а это признак плохого первоначального проекта.

Ключевое слова PUBLIC предназначено для хорошо известных словарей. Приложение, анализирующее документ из этого словаря, должно использовать некоторую стратегию по поиску соответствующего DTD .

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

Основные декларации разметки

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

Конструкция DTD Значение
ELEMENT Декларация типа элемента XML
ATTLIST Декларация атрибутов, которые могут быть назначены конкретным типам элементов, а также разрешенных значений этих атрибутов
ENTITY Декларация повторно используемого содержания
NOTATION Декларация форматирования для внешнего содержания, которое не должно быть проанализировано (например, двоичные данные), а также для внешних приложений, обрабатывающих содержание

Первые два типа связаны с информацией, которую мы рассчитываем найти в документе XML, — элементами и атрибутами.

Последние два типа используются для поддержки. Особенно облегчают жизнь разработчика словаря XML сущности. Как правило, они состоят из содержания, которое настолько часто используется в DTD или документе, что оправдывает создание специальной декларации. Применение этой декларации напоминает оператор include в языках C/C++ , когда в качестве замены для содержания используется имя.

Нотации описывают содержание, разработанное не на языке XML. Используются они для того, чтобы объявить конкретный класс данных и связать его с внешней программой. Эта внешняя программа становится обработчиком объявленного класса данных. Например, связав с документом изображение в формате JPEG, разработчик желает, чтобы программа приняла и визуализировала двоичные данные в этом формате. Конечно, в таком случае документ зависит от того, какой обработчик имеется в системе, получающей документ. В интересах портативности и переносимости некоторые авторы не приводят ссылки на обработчики. В таком случае нотация превращается просто в механизм набора текста.

Объявление элементов.

Каждый элемент документа XML должен быть описан. Объявление элемента начинается с символов , после которых через пробел идет имя элемента и его содержимое. Заканчивается объявление символом «больше». По своему содержанию элементы делятся на четыре группы.

  1. Пустой элемент — может иметь атрибуты, но не содержит текст или порожденные элементы. Объявляется следующим образом: после имени элемента указывается ключевое слово EMPTY .

Иногда из нескольких вложенных элементов или списков (список элементов указанных в скобках) может встретиться только один. В таком случае их имена перечисляются через вертикальную черту( | ). Например:

Элементы появляются именно в таком порядке.

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

? — элемент или список может встретиться нуль или один раз;

* — элемент или список может встретиться нуль или несколько раз;

+ — элемент или список может встретиться один или несколько раз.

Мой секрет

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

В настоящее время идет отказ от использования DTD в пользу XSD (XML Schema Definition ), по ряду причин:

  • DTD использует отличный от XML синтаксис.
  • Отсутствует типизация узлов.
  • Отсутствует поддержка пространств имён.

Тем не менее этот способ ещё широко применяется поскольку является более простым и удобным для описания несложных схем документов.

КОНСТРУКЦИИ DTD

Описание схемы состоит из объявлений разметки (markup declaration ), начинающихся с пары символов “ ”

ОБЪЯВЛЕНИЕ ТИПА ЭЛЕМЕНТА

(должен быть описан каждый элемент документа)

  • EMPTY – пустой (например
    )
  • ANY – любое содержимое (встречается редко)
  • (#PCDATA)– только символьные данные
  • (список имен вложенных элементов ч.з. запятую) – вложенные элементы должны следовать в документе в том порядке, в котором они перечислены в объявлении. Объявляется только один уровень вложенности. Элементы можно группировать скобками.
    Использование разделителя | между элементами указывает, что встречается один из разделенных элементов.
    После элементов или скобок:
    • ? – встречается 0 или 1 раз
    • * – 0 или несколько раз
    • + – 1 или несколько раз

ОБЪЯВЛЕНИЕ АТРИБУТОВ

Атрибуты объявляются после объявления самого элемента. Все атрибуты одного элемента объявляются сразу, одним списком.

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

Типы атрибутов:
  • CDATA – (Character set of data) строка символов
  • Список значений атрибута в скобках, перечисл чз “|”
  • ID – уникальный идентификатор
  • IDREF – идентификатор, содержащий одно из значений атрибута ID, исп в качестве ссылки на др элементы
  • IDREFS – идентификатор, содержащий набор значений атрибута типа ID, перечисленных через пробел, так же исп в качестве ссылки сразу на несколько элементов.
  • ENTITY – имя не проверяемой анализатором сущности (объявленные в том же описанииDTD)
  • ENTITIES – имена не проверяемых анализатором сущностей.
  • NMTOKEN – слово, содержащее только символы, применяемые в именах (имена др элементов или атрибутов, например чтобы ссылаться на них )
  • NMTOKENS – слова, перечисленные через пробелы
  • NOTATION – обозначение (обозначения, расшифрованные в описанииDTD )
  • NOTATIONS – список нотаций
признак обязательности:
  • Значение атрибута по умолчанию – указывается в кавычках и обозначает что атрибут необязателен.
  • #REQUIRED – атрибут надо обязательно записывать в элементе.
  • #IMPLIED – атрибут необязателен, у него нет значения по умолчанию.
  • #FIXED – у атрибута есть только одно значение, кот записывается тут же через пробел.

При исп пространства имен надо всегда указывать уточненное (QName ), а не локальное имя.

Атрибуты не входят в пространство имен по умолчанию.

Атрибуты “xml:lang ” и “xml:space ” так же дол быть объявлены в DTD в случае их применения

ОБЪЯВЛЕНИЕ СУЩНОСТЕЙ

Внутренние сущности – задаются при объявлении сущности.

— можно применять дальше в самом DTD ниже объявления.

Внешние сущности – содержатся в отдельном файле или встроены в программу-анализатор.

Параметризованные сущности – исп только внутри описания DTD

Сущности делятся на разбираемые(parsed ) и не разбираемые (unparsed ). Разбираемые предст собой фрагмент документа XML или целый документ и подлежат обработке программой-анализатором после подстановки. После подстановки разборки сущность становится частью XML документа.

Двоичный программный код, чертеж, изображение и др. не надо обрабатывать средствами XML , для этого сущность надо объявить не разбираемой. Для этого в конце объявления сущности делается пометка “NDATA ” и указывается обозначение (notation ) вставляемого объекта.

ПРЕДОПРЕДЕЛЕННЫЕ СУЩНОСТИ В XML

ОБЪЯВЛЕНИЕ ОБОЗНАЧЕНИЯ ( NOTATION)

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

SYSTEM | PUBLIC — в данном случае равнозначны т.к. в public не обязательно общеизвестная ссылка.

РАЗМЕЩЕНИЕ DTD

Либо в отдельном файле “*.dtd ” указав его имя в кавычках во второй части пролога DOCTYPE , либо включить описание непосредственно во вторую часть пролога, заключив его в квадратные скобки.

Используйте для определения структуры XML-документов XML-схемы вместо DTD

XML-схема обладает более мощными возможностями, чем DTD. Для иллюстрации преимуществ использования механизма XML-схем в первых трех листингах сравниваются различные способы представления элементов. В представлена выдержка из XML-документа. В показаны два элемента, объявленные в синтаксисе DTD, а в представлен синтаксис, соответствующий XML-схеме. Обратите внимание, что синтаксис в Листинге 3 подобен синтаксису XML. При использовании схемы, валидирующий парсер может выполнить проверку, является ли элемент InvoiceNo положительным целым числом, и состоит ли ProductID из заданного набора символов (шести цифр и одной буквы от A до Z). Парсер, обрабатывающий DTD-определение, может лишь подтвердить, что данные элементы представляют собой строки.

Листинг 1: Фрагмент XML-документа
Листинг 2: Фрагмент DTD, описывающий элементы из Листинга 1
Листинг 3: Фрагмент XML-схемы, описывающий элементы из Листинга 1

Использование пространств имен в XML-схеме

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

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

Согласно DTD элемент может быть представлен одним из трех способов:

  • Текстовая строка
  • Текстовая строка, смешанная с другим дочерним элементом
  • Набор дочерних элементов


DTD не обладает синтаксисом XML и предлагает лишь ограниченную поддержку для типов и пространств имен.

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

Такая XML-схема определяет набор новых имен, таких как имена элементов, типов, атрибутов, групп атрибутов, чьи определения и объявления описаны в схеме. В имена определяются как InvoiceNo , ProductID и ProductCode .

Имена, определенные в схеме принадлежат так называемому целевому пространству имен . Само по себе пространство имен является фиксированным, произвольным именем, которое должно соответствовать синтаксису URL. К примеру, пространство имен для схемы, представленной в , можно задать следующим образом: http://www.SampleStore.com/Account .

Синтаксис объявления пространства имен иногда может сбить с толку. Объявление начинается с http:// , однако оно не ссылается на файл с описанием схемы. На самом деле, ссылка http://www.SampleStore.com/Account вообще не ведет ни на один файл, а только на назначенное имя.

Определения и объявления в схеме могут ссылаться на имена, которые могут принадлежать другим пространствам имен. В данной статье мы ссылаемся на такие пространства имен как на исходные пространства имен . В каждой схеме может быть определено одно целевое пространство имен и возможно множество исходных пространств имен. Вообще, каждое имя в заданной схеме принадлежит некоему пространству имен. Имена пространства имен могут быть довольно длинными, однако их можно сократить при помощи синтаксиса объявления xmlns в документе XML-схемы. Все эти концепции проиллюстрированы в .

Листинг 4: Целевое и исходное пространства имен

В XML-схеме, представленной с , пространством имен targetNamespace является http://www.SampleStore.com/Account , оно содержит имена InvoiceNo , ProductID и ProductCode . Имена schema , element , simpleType , pattern , string и positive-integer принадлежат исходному пространству имен http://www.w3.org/1999/XMLSchema , которое сокращается как xsd путем объявления xmlns . В псевдониме xsd нет ничего особенного, можно выбрать и другое имя. Для удобства и простоты в оставшейся части статьи мы будем использовать префикс xsd для ссылки на пространство имен http://www.w3.org/1999/XMLSchema , пропуская уточнение xsd в некоторых частях кода. В нашем примере targetNamespace является также одним из исходных пространств имен, так как имя ProductCode используется в определении других имен.

Рисунок 1: Пространства имен для Листинга 4
Листинг 5: Множество исходных пространств имен, импорт пространства имен

Определение элементов

Определением элемента заключается в определении его имени и модели контента. В XML-схеме модель контента элемента определяется его типом. Следовательно, элементы в XML-документе могут иметь только значения, которые подходят типам, определенным в его схеме.

Простые типы

Спецификация XML-схемы определяет несколько простых типов для значений, как показано в Таблице 2 -предопределенные простые типы значений.

Тип элемента может быть простым или комплексным (сложным). Элемент простого типа не может содержать другие элементы или атрибуты. Комплексный тип может создавать эффект встраивания элементов в другие элементы или может ассоциировать атрибуты с элементом. До этого момента мы использовали только примеры с простыми типами, определенными пользователем (см. ProductCode). В спецификацию XML-схемы также включены предопределенные простые типы (см. вставку ). Предопределенный простой тип ограничивает значения по их базовому типу. К примеру, значением предопределенного простого типа ProductCode является подмножество значений базового типа string .

Простые, не вложенные элементы имеют простой тип

Элемент, который не содержит атрибутов или других элементов может быть отнесен к простому типу, предопределенному или определенному пользователем, такому как string , integer , decimal , time , ProductCode и т.п.

Листинг 7: Некоторые простые типы элементов

Элементы с атрибутами должны иметь комплексный тип

Теперь попробуем добавить к простому элементу price из атрибут currency . Вы не сможете этого сделать, так как элемент простого типа не может иметь атрибутов. Если вы хотите добавить атрибут, вам необходимо определить price как элемент комплексного типа. В примере из , мы определяем, так называемый анонимный тип , в котором комплексному типу не дается явного имени. Другими словами, атрибут name элемента complexType не определен.

Листинг 8: Элемент комплексного типа

Элементы, содержащие вложенные элементы должны иметь комплексный тип

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

Таблица 1: Сравнение комплексных типов данных в DTD и XML-схеме

XML-документ
XML-схема
Листинг 10: Скрытие BookType как локального типа

Выражение сложных ограничений для элементов

XML-схема предлагает большую гибкость, чем DTD при выражении ограничений для модели контента элементов. На простейшем уровне, таком как в DTD, вы можете ассоциировать с элементом атрибуты, а также указать, что в нем может появляться последовательность из только одного (1), нуля или более (*), или одного или более (+) элементов из заданного набора элементов. В XML-схеме можно выразить дополнительные ограничения, используя для этой цели, к примеру, атрибуты minOccurs и maxOccurs для элемента element и элементы choice , group и all .

Листинг 11: Выражение ограничений для типов элементов

В тег Title является опциональным по отношению к тегу Book (такое же правило можно задать и в DTD). Однако здесь также говорится, что в элементе Book должен быть хотя бы один и не более двух элементов Author . Значением атрибутов minOccurs и maxOccurs тега element по умолчанию является 1. Элемент choice указывает на то, что может появиться только один из указанных дочерних элементов. Другой элемент all определяет, что все дочерние элементы могут появляться только один раз, вместе и в любом порядке, или не появляться совсем. В объявляется, что оба тега Title и Author должны появляться в Book в любом порядке, или не появляться вообще. Подобные ограничения сложно выразить при помощи DTD.

Листинг 12: Указатель того, что у элемента должны быть определены все типы

Подведение итогов

В данном документе мы раскрыли при помощи простых примеров наиболее фундаментальные концепции, необходимые для определения структуры элементов при помощи XML-схемы. Доступно также множество других мощных механизмов:

  • XML-схема содержит всестороннюю поддержку для наследования типов, позволяя повторно использовать определенные ранее структуры. Такое использование называют аспектами . Вы можете вывести новые типы, представляющие меньшее подмножество значений других типов, к примеру, для определения подмножества по перечислению, диапазону или по совпадению с шаблоном. В одном из примеров данной статьи тип ProductCode был определен с использованием аспекта pattern . В подтипе также можно добавить для базового типа новые элементы и атрибуты.
  • Несколько механизмов, позволяющих контролировать общее определение подтипа или заменять его в определенном документе. К примеру, можно указать, что тип InvoiceType (тип номера инвойса) не может содержать подтипы, то есть никто не сможет определить новую версию InvoiceType . Можно также задать, что в отдельном контексте для типа ProductCode не может быть замещения подтипов.
  • Кроме использования подтипов, можно определять эквивалентные типы, то есть значение одного типа может быть замещено значением другого.
  • XML-схема обеспечивает механизм для замещения элемента или типа путем объявления их как абстрактных.
  • Для большего удобства можно обозначить и задать имена группам атрибутов или элементов. Это позволяет повторно использовать их при последующих обращениях.
  • XML-схема предоставляет три элемента – appInfo , documentation и annotation – для использования комментариев, как людьми (documentation) так и приложениями (appInfo)
  • Вы можете выразить уникальные ограничения, основывающиеся на определенных атрибутах дочерних элементов.

Дополнительную информацию по XML-схемам можно получить из документаций на сайтах W3C (См. ) и dW XML zone. Теперь, когда спецификация XML-схемы получила подтверждение в качестве кандидата на рекомендацию W3C, вы без сомнения можете использовать ее в полной мере.

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

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

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

Внутри же документа DTD- декларации включаются следующим образом:

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

Определение элемента

Элемент в DTD определяется с помощью дескриптора!ELEMENT , в котором указывается название элемента и структура его содержимого.

Например, для элемента можно определить следующее правило:

Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML . Внутри этой инструкции задается название элемента (flower) и тип его содержимого.

В определении элемента мы указываем сначала название элемента(flower) , а затем его модель содержимого — определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA (что означает parseable character data — любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY ,ANY . Первая указывает на то, что элемент должен быть пустым(например, ), вторая — на то, что содержимое элемента специально не описывается.

Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ? :

В этом примере указывается, что внутри элемента должны быть определены элементы title , author и table-of-contents , причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа «|» :

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

Если в определении элемента указывается «смешанное» содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA , а затем разделенный символом «|» список элементов.

Пример корректного XML — документа:

Определение атрибутов

Списки атрибутов элемента определяются с помощью ключевого слова!ATTLIST . Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента могут быть определены следующие атрибуты:

В данном примере для элемента article определяются три атрибута: id, about и type ,которые имеют типы ID (идентификатор), CDATA и список возможных значений соответственно. Всего существует шесть возможных типов значений атрибута:

  • CDATA — содержимым документа могут быть любые символьные данные
  • ID — определяет уникальный идентификатор элемента в документе
  • IDREF (IDREFS )- указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента
  • ENTITY (ENTITIES ) — значение атрибута должно быть названием(или списком названий, если используется ENTITIES ) компонента (макроопределения), определенного в документе
  • NMTOKEN (NMTOKENS ) — содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA )
  • Список допустимых значений — определяется список значений, которые может иметь данный атрибут.

Также в определении атрибута можно использовать следующие параметры:

  • #REQUIRED — определяет обязательный атрибут, который должен быть задан во всех элементах данного типа
  • #IMPLIED — атрибут не является обязательным
  • #FIXED «значение» — указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору
  • Значение — задает значение атрибута по умолчанию

Определение компонентов(макроопределений)

Компонент (entity) представляет собой определения, содержимое которых может быть повторно использовано в документе. В других языках программирования подобные элементы называются макроопределениями. Создаются DTD — компоненты при помощи инструкции !ENTITY :

Программа-анализатор, просматривая в первую очередь содержимое области DTD — определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD — компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello ; , которое будет заменено на строчку « Мы рады приветствовать Вас»

В общем случае, внутри DTD можно задать три типа макроопределений:

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

В XML существует пять предустановленных внутренних символьных констант:

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

Макроопределения правил — макроопределения параметров могут использоваться только внутри области DTD и обозначаются специальным символом % , вставляемым перед названием макроса. При этом содержимое компонента будет помещено непосредственно в текст DTD — правила

Например, для следующего фрагмента документа:

можно использовать более короткую форму записи:

Макроопределения часто используются для описания параметров в правилах атрибутов. В этом случае появляется возможность использовать одинаковые определения атрибутов для различных элементов:

Типизация данных

Довольно часто при создании XML — элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент 10.10.98 , то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL — запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL -запрос.

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

Задав атрибуту значение по умолчанию LONG и определив его как FIXED , мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD — определении.

Вот пример XML — документа, в котором определяются и используются несколько элементов с различными типами данных:

. 5 2
32.5 true 18346

Как видно из примера, механизм создания элементов документа при этом нисколько не изменился. Все необходимая для проверки типов данных информация заложена в определения элементов внутри блока DTD .

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

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

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

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

Атрибут имя_корневого_элемента соответствует имени корневого элемента в тегах, содержащих весь документ XML. В секции «прочих объявлений» находятся определения элементов, атрибутов и т. д.

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

Как и в случае с внутренним объявлением DTD, имя_корневого_элемента должно соответствовать имени корневого элемента в тегах, содержащих весь документ XML. Атрибут SYSTEM указывает на то, что some_dtd.dtd находится на локальном сервере. Впрочем, на файл some_dtd.dtd также можно сослаться по его абсолютному URL. Наконец, в кавычках указывается URL внешнего DTD, расположенного на локальном или на удаленном сервере.

Как же создать DTD для листинга 14.1? Во-первых, мы собираемся создать в документе XML ссылку на внешний DTD. Как упоминалось в предыдущем разделе, ссылка на DTD выглядит так:

Возвращаясь к листингу 14.1, мы видим, что cookbook является именем корневого элемента, a cookbook.dtd — именем DTD-файла. Содержимое DTD показано в листинге 14.2, а ниже приведены подробные описания всех строк.

Листинг 14.2. DTD для листинга 14.1(cookbook.dtd)

Что же означает этот загадочный документ? Несмотря на внешнюю сложность, в действительности он довольно прост. Давайте переберем все содержимое листинга 14.2:

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

Третья строка описывает элемент XML, в данном случае — корневой элемент cookbook. После него следует слово recipe, заключенное в круглые скобки. Это означает, что в теги cookbook заключается вложенный тег с именем recipe. Знак + говорит о том, что в родительских тегах cookbook находится одна или несколько пар тегов recipe.

Четвертая строка описывает тег recipe. В ней сообщается, что в тег recipe входят четыре вложенных тега: title, description, ingredients и process. Поскольку после имен тегов не указываются признаки повторения(см. следующий раздел), внутри тегов recipe должна быть заключена ровно одна пара каждого из перечисленных тегов.

Перед нами первое определение тега, который не содержит вложенных тегов. В соответствии с определением он содержит #PCDATA, то есть произвольные символьные данные, не считающиеся частью разметки.

В соответствии с определением элемент ingredients содержит один или несколько тегов с именем ingredient. Обратитесь к листингу 14.1, и вы все поймете.

Поскольку элемент ingredient соответствует отдельному ингредиенту, вполне логично, что этот элемент содержит простые символьные данные.

Элемент process содержит один или несколько экземпляров элемента step.

Элемент step, как и элемент ingredient, соответствует отдельному пункту в списке более высокого уровня. Следовательно, он должен содержать символьные данные.

Обратите внимание: элемент recipe в листинге 14.1 содержит атрибут. Этот атрибут, category, определяет общую категорию, к которой относится рецепт — в приведенном примере это категория «итальянская кухня»(Italian). В определении ATTLIST указывается как имя элемента, так и имя атрибута. Кроме того, отнесение каждого рецепта к определенной категории упрощает классификацию, поэтому атрибут объявляется обязательным(#REQUIRED).

Последняя строка просто завершает определение DTD. Определение всегда должно быть должным образом завершено, иначе произойдет ошибка.

В завершение этого раздела я приведу сводку основных компонентов типичного DTD-файла:

  • объявления типов элементов;
  • объявления атрибутов;
  • ID, IDREF и IDREFS;
  • объявления сущностей.

Некоторые из этих компонентов уже встречались нам в описании листинга 14.2. Далее каждый компонент будет описан более подробно.

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

Все элементы, используемые в документе XML, должны быть определены в DTD, прилагаемом к документу. Мы уже встречались с двумя распространенными разновидностями определений: для элемента, содержащего другие элементы, и элемента, содержащего символьные данные. Данное определение свидетельствует, что элемент содержит только символьные данные:

Следующее определение элемента process говорит о том, что он содержит ровно один вложенный элемент с именем step:

Впрочем, процессы(process) из одного шага(step) встречаются довольно редко — скорее всего, шагов будет несколько. Чтобы указать, что элемент содержит один или несколько экземпляров вложенного элемента step, следует воспользоваться признаком повторения:

Количество вложенных элементов можно задать несколькими способами. Полный список операторов элементов приведен в табл. 14.1.

Таблица 14.1. Операторы элементов

Если элемент будет содержать несколько вложенных элементов, их следует перечислить через запятую в определении родительского элемента:

Поскольку признаки повторения не указаны, каждый тег должен встречаться ровно один раз.

Определение элемента уточняется при помощи логических операторов. Предположим, вы работаете с рецептами, в которые всегда входят макароны(pasta) с одним или несколькими типами сыра(cheese) или мяса(meat). В этом случае элемент ingredient определяется следующим образом:

Поскольку элемент pasta обязательно должен присутствовать в элементе ingredient, он указывается с признаком повторения +. Затем следует либо элемент cheese, либо элемент meat; мы разделяем альтернативы вертикальной чертой и заключаем их в круглые скобки со знаком +, поскольку в рецепт всегда входит либо одно, либо другое.

Существуют и другие разновидности определений элементов. Мы рассмотрели лишь простейшие случаи. Тем не менее, приведенного материала вполне достаточно для понимания примеров, приведенных в оставшейся части этой главы.

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

Атрибуты элементов описывают значения, связываемые с элементами. Элементы XML, как и элементы HTML, могут иметь ноль, один или несколько атрибутов. Общий синтаксис объявления атрибутов выглядит следующим образом:

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

Форматировать объявления подобным образом необязательно; тем не менее, многострочные объявления нагляднее однострочных. Кроме того, поскольку оба атрибута являются обязательными, тег reci ре не может ограничиться каким-нибудь одним атрибутом, он должен включать в себя оба атрибута сразу. Например, следующий тег будет считаться неверным:

Почему? Потому что в нем отсутствует атрибут category. Правильный тег должен содержать оба атрибута:

Особые условия обработки атрибута описываются тремя флагами, перечисленными в табл. 14.2.

Таблица 14.2. Флаги атрибутов

Типы атрибутов

Атрибут элемента может объявляться с определенным типом. Типы атрибутов описаны далее.

Атрибуты CDATA

Очень часто атрибуты содержат общие символьные данные. Такие атрибуты называются атрибутами CDATA. Следующий пример уже встречался в начале этого раздела:

Атрибуты ID, IDREF и IDREFS

Идея однозначного представления данных(например, информации о пользователе или товаре, хранящейся в базе данных) посредством идентификаторов неоднократно встречалась в предыдущих главах книги. Идентификаторы также часто используются в XML, поскольку перекрестные ссылки между документами применяются не только в общих задачах обработки данных, но и в World Wide Web(гиперссылки).

Идентификаторы элементов присваиваются атрибуту ID. Допустим, вы хотите связать с каждым рецептом уникальный идентификатор. Соответствующий фрагмент DTD может выглядеть так:

После этого объявление элемента recipe в документе может выглядеть так:

Spaghetti alla Carbonara

Рецепт однозначно определяется идентификатором ital003. Следует помнить, что атрибут redpe-id относится к типу ID, поэтому ital003 не может использоваться в качестве значения атрибута recipe-id другого элемента, в противном случае документ будет считаться синтаксически неверным. Теперь допустим, что позднее вы захотели сослаться на этот рецепт из другого документа — скажем, из списка любимых рецептов пользователя. Именно здесь в игру вступают перекрестные ссылки и атрибут IDREF. Атрибуту IDREF присваивается идентификатор, используемый для ссылок на элемент, — по аналогии с тем, как URL используется для идентификации страницы в гиперссылке. Рассмотрим следующий фрагмент кода XML:

В процессе обработки документа XML элемент заменяется более наглядной ссылкой на рецепт с указанным идентификатором(например, названием рецепта). Вероятно, он будет отформатирован в виде гиперссылки, чтобы упростить переход к указанному рецепту.

Перечисляемые атрибуты

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

Если атрибут category не задан явно, по умолчанию ему присваивается значение Italian.

Атрибуты ENTITY и ENTITIES

Данные в документах XML не всегда являются текстовыми — документ может содержать и двоичную информацию(например, графику). На такие данные можно ссылаться при помощи атрибута entity. Например, в описании элемента description можно указать атрибут recipePicture с графическим изображением:


Также можно объявить сразу несколько сущностей, заменив ENTITY на ENTITIES. Значения разделяются пробелами.

Атрибуты NMTOKEN и NMTOKENS

Атрибуты NMTOKEN представляют собой строки из символов, входящих в ограниченный набор. Объявление атрибута с типом NMTOKEN предполагает, что значение атрибута соответствует установленным ограничениям. Как правило, значение атрибута NMTOKEN состоит из одного слова:

Можно объявить сразу несколько атрибутов, заменив NMTOKEN на NMTOKENS. Значения разделяются пробелами.

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

Объявление сущности напоминает команду define в некоторых языках программирования, включая РНР. Ссылки на сущности кратко упоминались в предыдущем разделе «Знакомство с синтаксисом XML». На всякий случай напомню, что ссылка на сущность используется в качестве замены для другого фрагмента содержания. В процессе обработки документа XML все вхождения сущности заменяются содержанием, которое она представляет. Существует два вида сущностей: внутренние и внешние.

Внутренние сущности

Внутренние сущности напоминают строковые переменные, связывающие имя с фрагментом текста. Например, если вы хотите определить имя для ссылки на информацию об авторских правах, можно объявить сущность следующего вида:

В процессе обработки документа все экземпляры &Соруright заменяются текстом «Copyright 2000 YourCompanyName. All Rights Reserved». Весь код XML в заменяющем тексте обрабатывается так, словно он присутствовал в исходном документе.

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

Внешние сущности

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

При последующей обработке документа XML все ссылки &Соруright заменяются содержимым документа copyright.xml. Весь код XML в заменяющем тексте обрабатывается так, словно он присутствовал в исходном документе.

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

Ресурсы, посвященные XML

Хотя приведенного выше материала вполне достаточно для понимания базовой структуры документов XML, данное описание не является полным. Ниже приведены ссылки на ресурсы Интернета, содержащие более подробную информацию:

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

Но стоит познакомиться с базовой стратегией работы с XML в РНР, и все оказывается на удивление просто.

Главный писатель по вопросам технологий

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

До того, как вы сможете открыть файл DTD, вам необходимо выяснить, к какому виду файла относится расширения файла DTD.

Tip: Incorrect DTD file association errors can be a symptom of other underlying issues within your Windows operating system. These invalid entries can also produce associated symptoms such as slow Windows startups, computer freezes, and other PC performance issues. Therefore, it highly recommended that you scan your Windows registry for invalid file associations and other issues related to a fragmented registry.

Ответ:

Файлы DTD имеют Файлы данных, который преимущественно ассоциирован с DesignTools 2D Design (TechSoft UK Limited).

Файлы DTD также ассоциированы с ArcView UNIX Hyperhelp Supporting File (ESRI), SGML Document Definition File и FileViewPro.

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

Как открыть ваш файл DTD:

Самый быстрый и легкий способ открыть свой файл DTD — это два раза щелкнуть по нему мышью. В данном случае система Windows сама выберет необходимую программу для открытия вашего файла DTD.

В случае, если ваш файл DTD не открывается, весьма вероятно, что на вашем ПК не установлена необходимая прикладная программа для просмотра или редактирования файлов с расширениями DTD.

Если ваш ПК открывает файл DTD, но в неверной программе, вам потребуется изменить настройки ассоциации файлов в вашем реестре Windows. Другими словами, Windows ассоциирует расширения файлов DTD с неверной программой.

Установить необязательные продукты — FileViewPro (Solvusoft) | | | |

DTD Multipurpose Internet Mail Extensions (MIME):

  • mime text/xml

DTD Инструмент анализа файлов™

Вы не уверены, какой тип у файла DTD? Хотите получить точную информацию о файле, его создателе и как его можно открыть?

Теперь можно мгновенно получить всю необходимую информацию о файле DTD!

Революционный DTD Инструмент анализа файлов™ сканирует, анализирует и сообщает подробную информацию о файле DTD. Наш алгоритм (ожидается выдача патента) быстро проанализирует файл и через несколько секунд предоставит подробную информацию в наглядном и легко читаемом формате.†

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

Чтобы начать бесплатный анализ файла, просто перетащите ваш файл DTD внутрь пунктирной линии ниже или нажмите «Просмотреть мой компьютер» и выберите файл. Отчет об анализе файла DTD будет показан внизу, прямо в окне браузера.

Перетащите файл DTD сюда для начала анализа

Просмотреть мой компьютер »

Пожалуйста, также проверьте мой файл на вирусы

Ваш файл анализируется. пожалуйста подождите.

Язык XML — Documents Type Definitions (DTD). Подключение DTD для валидации XML-документов

Наиболее известными языками описания схем являются следующие:

  • DTD (Document Type Definition) — язык определения типа документов, который первоначально использовался в качестве язык описания структуры SGML-документа.
  • XDR (XML Data Reduced) – диалект схемы XML, разработанный Microsoft, который поддерживался в Internet Explorer 4 и 5 версий.
  • XML Schema или просто XSD (язык определения схем XML) – рекомендация консорциума W3C с 2001 года.

Рассмотрим подробнее первые два из них. Третий язык описания схем рассматривается в лабораторной работе 11.

DTD схема

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

В рамках DTD модель содержимого XML документа можно описать следующим образом:

Каждый элемент документа может иметь один из типов:

Содержание Синтаксис Комментарий
Данные Содержит только текстовые данные
Другие элементы Содержит только дочерние элементы
Смешанное Содержит комбинацию текстовых данных и дочерних элементов
EMPTY Ничего не содержит
ANY Может содержать текстовые данные или дочерние элементы

Атрибуты, находящиеся внутри тэгов документа, описываются отдельно с помощью синтаксиса:

При этом атрибут в DTD может иметь один из трех типов:

  • Строка
  • Маркированные атрибут
  • Атрибута с перечислением

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

Рассмотрим в качестве примера описание атрибутов строкового типа для элемента, описывающего некоторое сообщение:

Если этот элемент содержит атрибуты с перечислением , то их описание может выглядеть, например, следующим образом:

Маркированных атрибуты элемента могут быть четырех типов:

И, наконец, в DTD можно использовать следующие индикаторы вхождения последовательностей:

Символ Пример Описание
, (a, b, c) Последовательное использование элементов списка
| (a | b | c) Используется один из членов списка
date Используется один и только один элемент
? subject ? Необязательное использование (0 или 1 раз)
+ paragraph+ Используется один или несколько раз
* brother* Используется ноль или несколько раз

В качестве примера приведем DTD схему, описывающую структуру электронного почтового ящика:

Главный писатель по вопросам технологий

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

До того, как вы сможете открыть файл DTD, вам необходимо выяснить, к какому виду файла относится расширения файла DTD.

Tip: Incorrect DTD file association errors can be a symptom of other underlying issues within your Windows operating system. These invalid entries can also produce associated symptoms such as slow Windows startups, computer freezes, and other PC performance issues. Therefore, it highly recommended that you scan your Windows registry for invalid file associations and other issues related to a fragmented registry.

Ответ:

Файлы DTD имеют Файлы данных, который преимущественно ассоциирован с DesignTools 2D Design (TechSoft UK Limited).

Файлы DTD также ассоциированы с ArcView UNIX Hyperhelp Supporting File (ESRI), SGML Document Definition File и FileViewPro.

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

Как открыть ваш файл DTD:

Самый быстрый и легкий способ открыть свой файл DTD — это два раза щелкнуть по нему мышью. В данном случае система Windows сама выберет необходимую программу для открытия вашего файла DTD.

В случае, если ваш файл DTD не открывается, весьма вероятно, что на вашем ПК не установлена необходимая прикладная программа для просмотра или редактирования файлов с расширениями DTD.

Если ваш ПК открывает файл DTD, но в неверной программе, вам потребуется изменить настройки ассоциации файлов в вашем реестре Windows. Другими словами, Windows ассоциирует расширения файлов DTD с неверной программой.

Установить необязательные продукты — FileViewPro (Solvusoft) | | | |

DTD Multipurpose Internet Mail Extensions (MIME):

  • mime text/xml

DTD Инструмент анализа файлов™

Вы не уверены, какой тип у файла DTD? Хотите получить точную информацию о файле, его создателе и как его можно открыть?

Теперь можно мгновенно получить всю необходимую информацию о файле DTD!

Революционный DTD Инструмент анализа файлов™ сканирует, анализирует и сообщает подробную информацию о файле DTD. Наш алгоритм (ожидается выдача патента) быстро проанализирует файл и через несколько секунд предоставит подробную информацию в наглядном и легко читаемом формате.†

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

Чтобы начать бесплатный анализ файла, просто перетащите ваш файл DTD внутрь пунктирной линии ниже или нажмите «Просмотреть мой компьютер» и выберите файл. Отчет об анализе файла DTD будет показан внизу, прямо в окне браузера.

Перетащите файл DTD сюда для начала анализа

Просмотреть мой компьютер »

Пожалуйста, также проверьте мой файл на вирусы

Ваш файл анализируется. пожалуйста подождите.

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

В настоящее время идет отказ от использования DTD в пользу XSD (XML Schema Definition ), по ряду причин:

  • DTD использует отличный от XML синтаксис.
  • Отсутствует типизация узлов.
  • Отсутствует поддержка пространств имён.

Тем не менее этот способ ещё широко применяется поскольку является более простым и удобным для описания несложных схем документов.

КОНСТРУКЦИИ DTD

Описание схемы состоит из объявлений разметки (markup declaration ), начинающихся с пары символов “ ”

ОБЪЯВЛЕНИЕ ТИПА ЭЛЕМЕНТА

(должен быть описан каждый элемент документа)

  • EMPTY – пустой (например
    )
  • ANY – любое содержимое (встречается редко)
  • (#PCDATA)– только символьные данные
  • (список имен вложенных элементов ч.з. запятую) – вложенные элементы должны следовать в документе в том порядке, в котором они перечислены в объявлении. Объявляется только один уровень вложенности. Элементы можно группировать скобками.
    Использование разделителя | между элементами указывает, что встречается один из разделенных элементов.
    После элементов или скобок:
    • ? – встречается 0 или 1 раз
    • * – 0 или несколько раз
    • + – 1 или несколько раз

ОБЪЯВЛЕНИЕ АТРИБУТОВ

Атрибуты объявляются после объявления самого элемента. Все атрибуты одного элемента объявляются сразу, одним списком.

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

Типы атрибутов:
  • CDATA – (Character set of data) строка символов
  • Список значений атрибута в скобках, перечисл чз “|”
  • ID – уникальный идентификатор
  • IDREF – идентификатор, содержащий одно из значений атрибута ID, исп в качестве ссылки на др элементы
  • IDREFS – идентификатор, содержащий набор значений атрибута типа ID, перечисленных через пробел, так же исп в качестве ссылки сразу на несколько элементов.
  • ENTITY – имя не проверяемой анализатором сущности (объявленные в том же описанииDTD)
  • ENTITIES – имена не проверяемых анализатором сущностей.
  • NMTOKEN – слово, содержащее только символы, применяемые в именах (имена др элементов или атрибутов, например чтобы ссылаться на них )
  • NMTOKENS – слова, перечисленные через пробелы
  • NOTATION – обозначение (обозначения, расшифрованные в описанииDTD )
  • NOTATIONS – список нотаций
признак обязательности:
  • Значение атрибута по умолчанию – указывается в кавычках и обозначает что атрибут необязателен.
  • #REQUIRED – атрибут надо обязательно записывать в элементе.
  • #IMPLIED – атрибут необязателен, у него нет значения по умолчанию.
  • #FIXED – у атрибута есть только одно значение, кот записывается тут же через пробел.

При исп пространства имен надо всегда указывать уточненное (QName ), а не локальное имя.

Атрибуты не входят в пространство имен по умолчанию.

Атрибуты “xml:lang ” и “xml:space ” так же дол быть объявлены в DTD в случае их применения

ОБЪЯВЛЕНИЕ СУЩНОСТЕЙ

Внутренние сущности – задаются при объявлении сущности.

— можно применять дальше в самом DTD ниже объявления.

Внешние сущности – содержатся в отдельном файле или встроены в программу-анализатор.

Параметризованные сущности – исп только внутри описания DTD

Сущности делятся на разбираемые(parsed ) и не разбираемые (unparsed ). Разбираемые предст собой фрагмент документа XML или целый документ и подлежат обработке программой-анализатором после подстановки. После подстановки разборки сущность становится частью XML документа.


Двоичный программный код, чертеж, изображение и др. не надо обрабатывать средствами XML , для этого сущность надо объявить не разбираемой. Для этого в конце объявления сущности делается пометка “NDATA ” и указывается обозначение (notation ) вставляемого объекта.

ПРЕДОПРЕДЕЛЕННЫЕ СУЩНОСТИ В XML

ОБЪЯВЛЕНИЕ ОБОЗНАЧЕНИЯ ( NOTATION)

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

SYSTEM | PUBLIC — в данном случае равнозначны т.к. в public не обязательно общеизвестная ссылка.

РАЗМЕЩЕНИЕ DTD

Либо в отдельном файле “*.dtd ” указав его имя в кавычках во второй части пролога DOCTYPE , либо включить описание непосредственно во вторую часть пролога, заключив его в квадратные скобки.

Определение типов документа (DTD) декларирует допустимые строительные блоки XML документа. Оно задает структуру документа со списком допустимых элементов и атрибутов.

DTD может декларироваться как в коде самого XML документа, так и во внешнем файле с подключением его к XML документу.

Внутренняя декларация DTD

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

Пример XML документа с внутренним DTD:

]> Tove Jani Напоминание Не забудь обо мне в эти выходные

Описание структуры XML документа средствами DTD – Document Type Definition. Язык XML — Documents Type Definitions (DTD)

Описание схемы документа

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

Объявление объектов-параметров

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

Объект-параметр fontstyle содержит в себе группу тегов TT | I | B | BIG | SMALL .

«#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;» >

Объект-параметр inline содержит в себе текстовые данные и ещё четыре объекта-параметра fontstyle , phrase , special и formctrl .

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

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

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

  • EMPTY — пустое содержимое
  • ANY — любое содержимое
  • , — указывает порядок
  • | — разделение альтернатив
  • () — группировка
  • * — любое количество элементов (ноль и более)
  • + — по крайней мере один элемент (один и более)
  • ? — необязательное наличие элемента (ноль или один)
  • Если нет *, + или? — элемент должен быть только один

Элемент DL должен содержать один и более элементов DT или DD в произвольном порядке.

Элемент FORM должен содержать в себе один или более элементов с объектом-параметром block или элементы SCRIPT в произвольном порядке, однако исключена возможность содержать ещё один элемент FORM .

Определение атрибутов

С каждым элементом DTD-документа можно сопоставить список атрибутов. Для этого используется директива!ATTLIST , в которой указываются имя элемента, с которым может быть сопоставлен список атрибутов и параметры каждого атрибута: его имя, тип и свойства по умолчанию.

name CDATA #REQUIRED>

В этом примере определен атрибут name для элемента MAP . Он является обязательным.

Существуют такие типы атрибутов:

  • CDATA (Character set of data) — значением атрибута могут быть любые символьные данные
  • ID — значением атрибута должен быть уникальный идентификатор элемента
  • IDREF — значением элемента является ссылка на элемент по его ID
  • IDREFS — тоже что и IDREF , но с возможностью ссылок не по одному идентификатору, а по нескольким
  • NMTOKEN — значением атрибута может быть последовательность символов, в чём-то схожая с именем (отсюда и названием — name token). Это строка, которая содержит любую комбинацию тех символов, которые разрешено использовать для имен XML.
  • NMTOKENS — значением атрибута является список значений
  • ENTITY — значение используется для ссылки на внешнюю сущность.
  • ENTITIES — позволяет задать список внешних сущностей, разделённых пробелами.
  • NOTATION — значением атрибута может быть одна из ранее определённых нотаций
  • NOTATIONS — позволяет задать список нотаций.
  • Listings и NOTATION-listings
  • ENUMERATION — задаёт список возможных альтернатив значений.

Существуют такие свойства по умолчанию:

  1. IMPLIED — значение атрибута указывать не обязательно;
  2. REQUIRED — значение атрибута обязательно должно быть указано;
  3. FIXED — значение этого атрибута задано как константа в DTD и в документе не может быть изменено;
  4. некоторое конкретное значение, которое используется по умолчанию.

Связь документа с определённым DTD

Чтобы связать документ с определённым DTD, необходимо в начале текста документа указать элемент Объявление Типа Документа.

В зависимости от места расположения DTD, Объявление Типа Документа может быть двух видов:

Набор объявлений DTD содержится в самом тексте документа. Например:

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

Пример

Пример очень простого XML DTD, описывающего список людей:

(person*) > (name, birthdate?, gender?, socialsecuritynumber?) > (#PCDATA) > (#PCDATA) > (#PCDATA) >

Начиная с первой строки:

Содержит любое число элементов

Знак означает что возможно 0, 1 или более элементов

Содержит элементы , , и . Знак означает что элемент необязателен. Элемент не содержит , что означает что элемент

обязательно должен содержать элемент .

  • Элемент содержит данные.
  • Элемент содержит данные.
  • Элемент содержит данные.
  • Элемент содержит данные.
  • Пример XML-документа, использующего этот DTD:

    > > Fred Bloggs > > 27/11/2008 > > Male > > 1234567890 >

    См. также

    Wikimedia Foundation . 2010 .

    Смотреть что такое «DTD» в других словарях:

    DTD — , die in einer ASCII Datei (ASCII) abgelegte Beschreibung der Struktur von Dokumenten, welche alle vom selben Typ sind. Eine DTD wird nach den Regeln der international anerkannten… … Universal-Lexikon

    DTD — may stand for: Contents 1 Media 2 Music 3 Sports 4 Technologies 4.1 Computing … Wikipedia

    DTD — steht für: Inhaltsverzeichnis 1 Medien 2 Music 3 Technologien 3.1 Computer 3.1.1 Spiele … Deutsch Wikipedia

    Dtd — steht für: Darwin Digital Television, eine australische Fernsehstation Delta Tau Delta, eine US amerikanische Studentenorganisation Document Type Definition, siehe Dokumenttypdefinition … Deutsch Wikipedia

    DTD — (dē tē dēʹ) n. A set of rules for marking up a document in SGML. * * * … Universalium

    DTD — (document type definition) specification written in the Standard Generalized Markup Language and containing information about the format of a particular document (Computers) … English contemporary dictionary

    Главный писатель по вопросам технологий

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

    До того, как вы сможете открыть файл DTD, вам необходимо выяснить, к какому виду файла относится расширения файла DTD.

    Tip: Incorrect DTD file association errors can be a symptom of other underlying issues within your Windows operating system. These invalid entries can also produce associated symptoms such as slow Windows startups, computer freezes, and other PC performance issues. Therefore, it highly recommended that you scan your Windows registry for invalid file associations and other issues related to a fragmented registry.

    Ответ:

    Файлы DTD имеют Файлы данных, который преимущественно ассоциирован с DesignTools 2D Design (TechSoft UK Limited).

    Файлы DTD также ассоциированы с ArcView UNIX Hyperhelp Supporting File (ESRI), SGML Document Definition File и FileViewPro.

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

    Как открыть ваш файл DTD:

    Самый быстрый и легкий способ открыть свой файл DTD — это два раза щелкнуть по нему мышью. В данном случае система Windows сама выберет необходимую программу для открытия вашего файла DTD.

    В случае, если ваш файл DTD не открывается, весьма вероятно, что на вашем ПК не установлена необходимая прикладная программа для просмотра или редактирования файлов с расширениями DTD.

    Если ваш ПК открывает файл DTD, но в неверной программе, вам потребуется изменить настройки ассоциации файлов в вашем реестре Windows. Другими словами, Windows ассоциирует расширения файлов DTD с неверной программой.

    Установить необязательные продукты — FileViewPro (Solvusoft) | | | |

    DTD Multipurpose Internet Mail Extensions (MIME):

    • mime text/xml

    DTD Инструмент анализа файлов™

    Вы не уверены, какой тип у файла DTD? Хотите получить точную информацию о файле, его создателе и как его можно открыть?

    Теперь можно мгновенно получить всю необходимую информацию о файле DTD!

    Революционный DTD Инструмент анализа файлов™ сканирует, анализирует и сообщает подробную информацию о файле DTD. Наш алгоритм (ожидается выдача патента) быстро проанализирует файл и через несколько секунд предоставит подробную информацию в наглядном и легко читаемом формате.†

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

    Чтобы начать бесплатный анализ файла, просто перетащите ваш файл DTD внутрь пунктирной линии ниже или нажмите «Просмотреть мой компьютер» и выберите файл. Отчет об анализе файла DTD будет показан внизу, прямо в окне браузера.

    Перетащите файл DTD сюда для начала анализа

    Просмотреть мой компьютер »

    Пожалуйста, также проверьте мой файл на вирусы

    Ваш файл анализируется. пожалуйста подождите.

    Как раз таковыми и являются. Причём XML сам по себе предусматривает расширяемость. Документы созданные с помощью этих языков могут быть «корректными (well-formed)» и «допустимыми (valid)».

    С проверкой документа на корректность проблем не возникает: если ошибок не выскочило и всё отобразилось так, как мы хотели, то документ корректен. Например, если в HTML-документе написать что-то вроде « Привет! », то наш документ будет полностью корректен, но проигнорирован браузером. Почему? Потому что браузер ничего не знает о том, что это за «Z» такой. И если мы проверим наш документ на допустимость с помощью валидатора , то документ таковым признан не будет. А как об этом узнает валидатор и на основании чего он вынес такой вердикт?

    Допустимость проверяется с помощью определения типа документа (DTD, document type definition). Например, для «строгого» HTML он выглядит так .

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

    Объявление DTD

    Объявление DTD располагается перед первым (корневым) элементом документа, начинается с последовательности « ».

    Внутреннее DTD описывается так:

    Между квадратными скобками располагается содержимое DTD, так называемое внутреннее подмножество , например:

    Если DTD вынесено в отдельный файл (обычно имеющий расширение.dtd), то его объявление в документе записывается так:

    Соответственно, в этом файле и прописываются все правила, так называемое внешнее подмножество .

    Имя, указанное за словом « DOCTYPE » (в нашем случае « catalog »), должно соответствовать имени корневого элемента. То есть, XML-документ должен быть примерно таким:

    Вместо ключевого слова « SYSTEM » может быть использовано слово « PUBLIC », указывающее, что DTD применяется для широкого использования:

    Внутренние и внешние подмножества могут быть заданы одновременно (опять же, аналогия с CSS):

    Здесь, сначала зачитывается содержимое файла « catalog.dtd », а потом содержимое, указанное внутри квадратных скобок.

    Элементы документа

    Элементы объявляются в DTD с помощью ключевого слова « ELEMENT », после которого следует имя элемента и его содержимое заключенное в круглые скобки:

    Если у элемента есть дочерние элементы, то это записывается так:

    что соответствует документу:

    Если у элемента несколько дочерних элементов, то они перечисляются через запятую и должны следовать строго в указанном порядке:

    Приведённый выше пример читается следующим образом. Элемент « book » должен содержать только один элемент « title », за которым должен следовать только один элемент « author ». Сами элементы « title » и « author » никаких элементов не содержат, а могут содержать лишь какой-нибудь текст.

    С помощью следующих специальных символов можно определять количественное присутствие элемента:

    • Символ « * », следующий после элемента, означает, что элемент может присутствовать один или несколько раз, или не присутствовать вовсе(от нуля до + бесконечности)
    • Символ « + », следующий после элемента, означает, что элемент может присутствовать один или несколько раз(от 1 до + бесконечности)
    • Символ « ? », следующий после элемента, означает, что элемент может либо отсуствовать, либо присутствовать только один раз(0 или 1)

    . . .

    Если существует необходимость указать один из нескольких элементов (или title, или author — любой из них, но не оба), надо испольовать символ « | »:

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

    Следующий фрагмент документа валиден вышеприведенному примеру:

    Группы элементов заключаются в круглые скобки. Элемент « book » должен содержать либо текст, либо (один « title », один или неколько « author » и может быть один « pubyear » именно в таком порядке):

    Данному примеру соответствует следующий фрагмент XML-документа:

    Элемент может быть пустым. Такой элемент не может содержать не дочерних элементов ни текста (например, элемент « br » в HTML). Такой элемент задается с ключевым словом « EMPTY »:

    Элемент также может быть объявлен с ключевым словом « ANY » означающее, что элемент может содержать и элементы, и текст, и все это вместе, и даже быть пустым.

    Атрибуты элементов

    Элементы в XML-документе могут иметь атрибуты, которые записываются в виде « имя = значение » в открывающем или пустом тегах. Общее объявление атрибутов конкретного элемента начинается с ключевого слова « ATTLIST », после которого следует имя данного элемента и объявления самих атрибутов:

    Ключевое слово « REQUIRED » указывает на то, что атрибут обязателен. Ключевое слово « IMPLIED », наоборот, говорит, что атрибут необязателен.

    У атрибутов могут быть перечисленны разрешенные значения:

    Также может быть задано значение по-умолчанию:

    pubyear CDATA #IMPLIED «2007»>

    Атрибут может быть и константой, то есть у него может быть только то значение, которое заявлено в объявлении атрибута. Делается это с помощью ключевого слова « FIXED »:

    Тип атрибута « CDATA »позволяет использовать любые символы кроме « », « & », « » » и « » ». В случае использования, данные символы должны быть заменены на спецсимволы типа «

    Еще один тип атрибута « ID » разрешает задавать те же значения, что и тип NMTOKEN, но начинаться значение должно либо с буквы, либо с « _ », либо с « : ». У любого элемента может быть только один атрибут с типом « ID ». Атрибут типа « ID » не может быть константой (объявляться как « FIXED »). Значение атрибута типа « ID » должно быть уникальным для всего XML-документа:

    Атрибут элемента может быть ссылкой на атрибут типа « ID » другого элемента. Для этого он объявляется как атрибут типа « IDREF ». Если атрибут должен ссылаться на атрибут типа « ID » нескольких элементов, то испольуется ключевое слово « IDREFS »:

    В XML-документе это будет выглядить так:

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

    Помимо элементов и их атрибутов, мы можем определить сущности , записываемые с помощью ключевого слова « ENTITY »:

    В результате чего, на место имени сущности « name », будет подставлено ее значение, в нашем случае — « SuperMegaMaster ».


    И для полноты нашего счастья, надо добавить, что атрибуты элементов могут иметь в качестве значения подобные сущности — сущности-атрибуты . Они тоже определяются с помощью ключевого слова « ENTITY », но имеют одно ограничение — они должны ссылаться на внешние неанализируемые сущности, определенные во внешнем подмножестве DTD:

    В вышеприведённом примере, объявлена сущность « list », которая ссылается на внешний документ « companyList.html ». Ключевое слово « NDATA », говорит о том, что внешний документ неявляется XML-документом. Далее, для элемента « user » объявляется атрибут « company », который является обязательным и имеет тип « ENTITY », то есть ссылается на какую-либо сущность. Поскольку в нашем пример задана только одна сущность (« list »), то именно она и только она может быть значением атрибута « company » в XML-документе:

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

    Слово « parse » в объявлении сущности лист указывает на то, каким образом можно проанализировать файл « companyList.html » — найти нотацию с именем « parse » и следовать ее указаниям. В нашем случае, приложение может открыть MS InternetExplorer и загрузить в него документ « companyList.html ».

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

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

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

    Что такое DTD в XML и для чего он нужен

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

    Необходимость проверки грамматики XML-документов заключается в следующем:

    • XML-документ может быть предназначен не для вашей системы.
    • XML-документ может содержать неправильные данные.
    • XML-документ может содержать ошибки в структуре ().

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

    Недостатки XML DTD

    • Отличный от XML синтаксис языка. Это вызывает множество проблем, таких как, например, проблемы с кодировкой или невозможность отслеживать ошибки.
    • Нет проверки типов данных. В DTD есть только один тип – строка.
    • В DTD нет . Нельзя поставить в соответствие документу два и более DTD описаний.

    Это был краткий список недостатков DTD, которые с успехом исправлены в XML схемах, о которых мы поговорим в следующих статьях.

    Объявление элементов, атрибутов и сущностей в DTD. Модификаторы «*», «?», «+»

    Для объявления элементов, атрибутов и сущностей в DTD используются специальные декларации и модификаторы. Чтобы подробно во всем разобраться, давайте для начала рассмотрим теоритическую информацию, а затем во второй части статьи перейдем к практическим примерам.

    Определение элемента XML и последовательности элементов XML

    Элемент book содержит по одному элементу title, author, price и description.

    Элемент pricelist содержит элементы title, price и один элемент из трех на выбор – author, company либо sample.

    Элемент none должен быть пустым.

    Элемент pricelist может содержать два атрибута – атрибут id и атрибут name. При этом атрибут id является обязательным, так как указано #REQUIRED, а атрибут name – не обязательным (указано #IMPLIED). В свою очередь CDATA указывает обработчику, что разбирать содержимое атрибутов не нужно.

    Если встретится сущность «&myname;», то вместо нее автоматически подставится «Дмитрий Денисов».

    Модификаторы (объясняют повторения элементов)

    * — ноль или много.
    ? – ноль или один.
    + — один или много.

    Элемент books может содержать один или более элементов book.

    Теперь давайте рассмотрим, как это все выглядит на более практических примерах.

    Создание DTD-файла для валидации XML-документа на примере прайс-листа книг

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

    Конечно, вышеприведенный пример не является пределом мечтаний, но для примера вполне сойдет. Как видно с примера, у нас есть корневой элемент pricelist, который содержит вложенные элементы book. Внутри элементов book находятся элементы title, author, price и возможно description, которые могут содержать какие-то текстовые данные.

    Для валидации данного прайс-листа мы можем использовать DTD-документ следующего содержания.

    Теперь разберем все более подробно.

    • — декларируем корневой элемент books и в скобках указываем, что он может содержать. В данном случае он может содержать один или более элементов book (плюсик означает один или более, см. выше).
    • — определяем элемент book. Элемент book может содержать один элемент title, один или более элементов author (плюсик), один элемент price и один или ни одного элемента description (знак вопроса).
    • — определяем элемент title. В качестве содержимого элемента указываем #PCDATA. Это означает, что анализатор обязан разбирать то, что находится внутри этого элемента.
    • Аналогичным образом определяем элементы author, price, description.
    • — определяем сущность. Сначала пишем саму сущность, а затем в кавычках то, что будет выводиться на ее месте. По умолчанию в XML определено только 3 сущности. Это больше («>» — ) и амперсанд («&» — &). При желании вы можете создать неограниченное количество сущностей, используя данный способ. В качестве значений могут быть не только слова, но и целые предложения значительного объема.
    Подключение DTD для валидации XML-документов

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

    где вместо DOCUMENT указываем корневой элемент XML-документа.

    Для наглядности рассмотрим пример готового самодостаточного документа с декларативным способом включения DTD.

    Внешнее определение DTD — подключение DTD-документа

    Суть данного метода состоит в том, чтобы подключить к XML-документу файл DTD при помощи следующей конструкции.

    где DOCUMENT – указываем корневой элемент XML-документа.
    file.dtd – ссылка на файл DTD.

    Для наглядности рассмотрим следующий пример.

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

    На этом все. Удачи вам и успехов в изучении XML!

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

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

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

    Внутри же документа DTD- декларации включаются следующим образом:

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

    Определение элемента

    Элемент в DTD определяется с помощью дескриптора!ELEMENT , в котором указывается название элемента и структура его содержимого.

    Например, для элемента можно определить следующее правило:

    Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML . Внутри этой инструкции задается название элемента (flower) и тип его содержимого.

    В определении элемента мы указываем сначала название элемента(flower) , а затем его модель содержимого — определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA (что означает parseable character data — любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY ,ANY . Первая указывает на то, что элемент должен быть пустым(например, ), вторая — на то, что содержимое элемента специально не описывается.

    Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ? :

    В этом примере указывается, что внутри элемента должны быть определены элементы title , author и table-of-contents , причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа «|» :

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

    Если в определении элемента указывается «смешанное» содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA , а затем разделенный символом «|» список элементов.

    Пример корректного XML — документа:

    Определение атрибутов

    Списки атрибутов элемента определяются с помощью ключевого слова!ATTLIST . Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента могут быть определены следующие атрибуты:

    В данном примере для элемента article определяются три атрибута: id, about и type ,которые имеют типы ID (идентификатор), CDATA и список возможных значений соответственно. Всего существует шесть возможных типов значений атрибута:

    • CDATA — содержимым документа могут быть любые символьные данные
    • ID — определяет уникальный идентификатор элемента в документе
    • IDREF (IDREFS )- указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента
    • ENTITY (ENTITIES ) — значение атрибута должно быть названием(или списком названий, если используется ENTITIES ) компонента (макроопределения), определенного в документе
    • NMTOKEN (NMTOKENS ) — содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA )
    • Список допустимых значений — определяется список значений, которые может иметь данный атрибут.

    Также в определении атрибута можно использовать следующие параметры:

    • #REQUIRED — определяет обязательный атрибут, который должен быть задан во всех элементах данного типа
    • #IMPLIED — атрибут не является обязательным
    • #FIXED «значение» — указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору
    • Значение — задает значение атрибута по умолчанию

    Определение компонентов(макроопределений)

    Компонент (entity) представляет собой определения, содержимое которых может быть повторно использовано в документе. В других языках программирования подобные элементы называются макроопределениями. Создаются DTD — компоненты при помощи инструкции !ENTITY :

    Программа-анализатор, просматривая в первую очередь содержимое области DTD — определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD — компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello ; , которое будет заменено на строчку « Мы рады приветствовать Вас»

    В общем случае, внутри DTD можно задать три типа макроопределений:

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

    В XML существует пять предустановленных внутренних символьных констант:

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

    Макроопределения правил — макроопределения параметров могут использоваться только внутри области DTD и обозначаются специальным символом % , вставляемым перед названием макроса. При этом содержимое компонента будет помещено непосредственно в текст DTD — правила

    Например, для следующего фрагмента документа:

    можно использовать более короткую форму записи:

    Макроопределения часто используются для описания параметров в правилах атрибутов. В этом случае появляется возможность использовать одинаковые определения атрибутов для различных элементов:

    Типизация данных

    Довольно часто при создании XML — элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент 10.10.98 , то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL — запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL -запрос.

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

    Задав атрибуту значение по умолчанию LONG и определив его как FIXED , мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD — определении.

    Вот пример XML — документа, в котором определяются и используются несколько элементов с различными типами данных:

    . 5 2
    32.5 true 18346

    Как видно из примера, механизм создания элементов документа при этом нисколько не изменился. Все необходимая для проверки типов данных информация заложена в определения элементов внутри блока DTD .

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

    Работа с XML

    На этой странице

    Adobe InDesign CS5 является одной из программ, позволяющих создавать XML-файлы и работать с ними. После разметки содержимого файла InDesign тегами его можно сохранить и экспортировать в формате XML. Это позволит впоследствии преобразовать его либо в другой файл InDesign, либо в файл другой программы. Аналогичным образом можно импортировать XML-файл в InDesign, а затем отображать и форматировать XML-данные в этой программе по своему усмотрению.

    О формате XML

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

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

    Например, InCopy позволяет создать тег Heading1 и указывать его в документе для каждого заголовка первого уровня. После сохранения документа в виде XML-файла содержимое раздела «Heading1 » может быть импортировано при помощи любого приложения, поддерживающего формат XML, и представлено в виде веб-страницы, печатного каталога, папки, прайс-листа или таблицы базы данных.

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

    Adobe InCopy является одной из программ, позволяющих создавать XML-файлы и работать с ними. После разметки содержимого файла InCopy тегами его можно сохранить и экспортировать в формате XML. Это позволит впоследствии преобразовать его в другой файл InCopy, InDesign или другой программы.

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

    Следует различать XML-теги и текст с тегами InCopy. Дополнительные сведения о тексте с тегами, который представляет еще один способ экспорта и импорта содержимого InCopy, см. в файле PDF о тексте с тегами по адресу www.adobe.com/go/learn_id_taggedtext_cs5_ru (PDF).

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

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

    Например, на следующем рисунке представлен элемент chapter , который содержит несколько элементов recipe (то есть является для них родительским элементом). Каждый из элементов recipe , в свою очередь, является родительским для элементов recipename , ingredients , instructions , notes и servings . Все элементы содержатся внутри Root элемента, который всегда расположен в верхней строке панели «Структура».

    Например, на следующем рисунке представлен элемент chapter , который содержит элемент recipe , являющийся для него родительским элементом. В свою очередь, элемент recipe является родительским для элементов recipename и ingredients . Все элементы содержатся внутри элемента Story , который всегда расположен в верхней строке панели «Структура».

    Инструменты XML

    Работу с XML-содержимым в InCopy обеспечивают палитры «Структура» и «Теги». На палитре «Структура» отображается иерархическая структура элементов документа. Чтобы элемент можно было легко идентифицировать, InCopy отображает его тег и значок, указывающий на тип содержимого. Кроме того, на панели «Структура» могут отображаться первые несколько слов текста элемента, именуемого текстовый сниппет, который не следует путать с файлами сниппетов, в которых сохраняются объекты для повторного использования.

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

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

    На палитре «Теги» перечислены теги элементов. Они могут быть импортированы, экспортированы, добавлены, удалены и переименованы. Палитра «Теги» позволяет применять теги элементов к содержимому, которое необходимо экспортировать в XML.

    О файлах DTD

    Чтобы обеспечить совместное использование данных в формате XML, стандартный набор имен тегов и атрибутов элементов должен быть согласован с другими пользователями, чтобы все члены группы использовали и применяли теги аналогичным образом. Одним из способов обеспечить это является применение DTD-файлов (Document Type Definition).

    DTD-файл предоставляет собой набор элементов и атрибутов, которыми могут пользоваться члены рабочей группы. Он также определяет правила нахождения элементов в иерархической структуре. Например, в DTD-файле может быть указано, что элемент «Заголовок» является дочерним элементом элемента «Материал», поскольку заголовок должен находиться внутри материала. Если будет присутствовать тег заголовка, но не будет тега для материала, в котором он должен находиться, то элемент «Заголовок» будет помечен как недопустимый. DTD-файл позволяет найти и пометить в файле InDesign ошибки в структуре данных. Этот процесс называется проверкой .

    Для использования DTD-файл загружают в документ (если он еще не загружен). Все содержащиеся в нем имена элементов импортируются на палитру «Теги». У всех остальных пользователей, также загрузивших данный DTD-файл, будут определены элементы с теми же именами, благодаря чему все члены группы будут пользоваться одними и теми же элементами. Импортированные из DTD элементы заблокированы, то есть их нельзя удалить и переименовать до тех пор, пока DTD-файл не будет удален из документа.

    Хотя импорт DTD в InCopy не поддерживается, DTD-файлы, импортируемые в InDesign, при редактировании материала в InCopy будут доступны. InCopy позволяет просматривать их и выполнять по ним проверку, гарантируя правильное применение тегов.

    Может оказаться, что созданный в смежной группе или отрасли DTD-файл содержит необходимые теги и структуры. Текущий список зарегистрированных DTD-файлов см. на веб-странице www.xml.com/pub/rg/DTD_Repositories (только на английском языке).

    Наборы правил XML

    Набор правил XML — это набор инструкций, написанных на языке сценариев (например, JavaScript или AppleScript). Они производят вычисление XML-данных и, если данные соответствуют определенным условиям, выполняют некоторые действия. Каждое правило имеет по крайней мере одно условие и одно действие. Правило производит вычисление XML-данных с заданными условиями, и, если условие выполняется, предпринимается соответствующее действие. Например, XML-правило может указывать, что всякий раз при появлении элемента «Абзац» под элементом «Подзаголовок» (условие) применяется определенный стиль (действие) или всякий раз при появлении элемента «Продукт» (условие) создается новый фрейм и в него импортируется изображение продукта (действия). XML-правила представляют собой средства динамического создания и форматирования макетов на основе XML.

    Подготовка XML-файлов для рабочих процессов K4 или InCopy

    Чтобы подготовить файлы путем расстановки XML-тегов для использования в средах K4 или InDesign/InCopy, может потребоваться настроить способ подготовки структуры и импорта XML в файлы InDesign.

    Для импорта XML в среду InDesign применяются два метода: merge (объединение) и append (присоединение). При объединении происходит замена существующей структуры, а при присоединении данные добавляются к существующей структуре. В обоих случаях важно, чтобы корневой элемент не ассоциировался с текстовым фреймом. Следует использовать стандартный элемент с именем «Root» (корень), либо переименовать этот элемент с учетом требований текущего процесса или иных требований по мере необходимости, при этом избегая его ассоциаций с текстовым фреймом.

    Для получения дополнительной информации по использованию XML в средах K4 или InCopy обратитесь к своему системному администратору.

    Описание структуры XML документа средствами DTD – Document Type Definition. Основы использования XML-схем для определения элементов

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

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

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

    Внутри же документа DTD- декларации включаются следующим образом:

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

    Определение элемента

    Элемент в DTD определяется с помощью дескриптора!ELEMENT , в котором указывается название элемента и структура его содержимого.

    Например, для элемента можно определить следующее правило:

    Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML. Внутри этой инструкции задается название элемента(flower) и тип его содержимого.

    В определении элемента мы указываем сначала название элемента(flower), а затем его модель содержимого — определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA(что означает parseable character data — любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY,ANY. Первая указывает на то, что элемент должен быть пустым(например, ), вторая — на то, что содержимое элемента специально не описывается.

    Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ? :

    В этом примере указывается, что внутри элемента должны быть определены элементы title, author и table-of-contents, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа «|» :

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

    Если в определении элемента указывается «смешанное» содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA, а затем разделенный символом «|» список элементов.


    Пример корректного XML- документа:

    Определение атрибутов

    Списки атрибутов элемента определяются с помощью ключевого слова!ATTLIST . Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента могут быть определены следующие атрибуты:

    В данном примере для элемента article определяются три атрибута: id, about и type , которые имеют типы ID(идентификатор), CDATA и список возможных значений соответственно. Всего существует шесть возможных типов значений атрибута:

    • CDATA — содержимым документа могут быть любые символьные данные
    • ID — определяет уникальный идентификатор элемента в документе
    • IDREF(IDREFS)- указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента
    • ENTITY(ENTITIES) — значение атрибута должно быть названием(или списком названий, если используется ENTITIES) компонента (макроопределения), определенного в документе
    • NMTOKEN (NMTOKENS) — содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA)
    • Список допустимых значений — определяется список значений, которые может иметь данный атрибут.

    Также в определении атрибута можно использовать следующие параметры:

    • #REQUIRED — определяет обязательный атрибут, который должен быть задан во всех элементах данного типа
    • #IMPLIED — атрибут не является обязательным
    • #FIXED «значение» — указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору
    • Значение — задает значение атрибута по умолчанию

    Определение компонентов(макроопределений)

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

    Программа-анализатор, просматривая в первую очередь содержимое области DTD- определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD- компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello; , которое будет заменено на строчку «Мы рады приветствовать Вас»

    В общем случае, внутри DTD можно задать три типа макроопределений:

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

    В XML существует пять предустановленных внутренних символьных констант:

    • — символ «>»
    • & — символ «&»
    • » — символ апострофа «»»
    • » — символ двойной кавычки «»»

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

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

    Например, для следующего фрагмента документа:

    можно использовать более короткую форму записи:

    Макроопределения часто используются для описания параметров в правилах атрибутов. В этом случае появляется возможность использовать одинаковые определения атрибутов для различных элементов:

    Типизация данных

    Довольно часто при создании XML- элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент 10.10.98 , то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL- запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL-запрос.

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

    Задав атрибуту значение по умолчанию LONG и определив его как FIXED, мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD- определении.

    Вот пример XML- документа, в котором определяются и используются несколько элементов с различными типами данных:

    . 5 2
    32.5 true 18346

    Как видно из примера, механизм создания элементов документа при этом нисколько не изменился. Все необходимая для проверки типов данных информация заложена в определения элементов внутри блока DTD.

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

    20. Языки описания cхем XML

    DTD схемы. Недостатки DTD схем. XDR схемы. Элементы и атрибуты XDR схем.

    Идея создания собственных тэгов, имеющих специальное значение и помогающих описать содержание документа, сама по себе просто замечательна. Но если каждый пользователь может создавать свои собственные описания, каким образом их распознавать? С этой целью в спецификации XML для описания подобных «самодеятельных» тэгов используются схемы. Они необходимы для того, чтобы:

    описать, что именно является разметкой;

    описать точно, что означает разметка.

    Наиболее известными языками описания схем являются следующие:

    DTD (Document Type Definition) — язык определения типа документов, который первоначально использовался в качестве язык описания структуры SGML-документа.

    XDR (XML Data Reduced) – диалект схемы XML, разработанный Microsoft, который поддерживался в Internet Explorer 4 и 5 версий.

    XML Schema или просто XSD (язык определения схем XML) – рекомендация консорциума W3C с 2001 года.

    Рассмотрим подробнее первые два из них. Третий язык описания схем рассматривается в лабораторной работе 11.

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

    В рамках DTD модель содержимого XML документа можно описать следующим образом:

    Каждый элемент документа может иметь один из типов:

    Содержит только текстовые данные

    Содержит только дочерние элементы

    Содержит комбинацию текстовых данных и дочерних элементов

    Ничего не содержит

    Атрибуты, находящиеся внутри тэгов документа, описываются отдельно с помощью синтаксиса:

    имя_элемента имя_атрибута1 (тип) значение_по_умолчанию

    имя_элемента имя_атрибутаN (тип) значение_по_умолчанию >

    При этом атрибут в DTD может иметь один из трех типов:

    Атрибута с перечислением

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

    Рассмотрим в качестве примера описание атрибутов строкового типа для элемента, описывающего некоторое сообщение:

    Если этот элемент содержит атрибуты с перечислением, то их описание может выглядеть, например, следующим образом:

    Маркированных атрибуты элемента могут быть четырех типов:

    И, наконец, в DTD можно использовать следующие индикаторы вхождения последовательностей:

    Последовательное использование элементов списка

    Используется один из членов списка

    Используется один и только один элемент

    Необязательное использование (0 или 1 раз)

    Используется один или несколько раз

    Используется ноль или несколько раз

    В качестве примера приведем DTD схему, описывающую структуру электронного почтового ящика:

    Исходный XML документ, удовлетворяющий данной схеме, может выглядеть, например, так:

    Remind me about meeting.

    Обратите внимание на 2-ю строчку документа, в которой указывается внешняя ссылка на файл, содержащий DTD схему.

    В принципе, DTD допускает два способа использования в XML документе.

    Объявление внутренней схемы:

    Объявление внешней схемы:

    В заключение укажем на следующие недостатки DTD схем:

    Не являются экземплярами XML. Требуется изучение совершенно другого языка.

    Не предоставляют контроль за типами данных, за исключением самых простых текстовых данных.

    Не являются экземплярами XML, поэтому их нельзя легко расширить или преобразовать к другим языкам разметки – HTML или DHTML.

    Не обеспечивают поддержки пространств имен XML.

    XML-Data – полное имя языка описания схем, предложенного Майкрософт, а XML-DataReduced– это «часть» полной рекомендации. Схема XDR — это экземпляр XML, т.е. соответствует всем синтаксическим правилам и стандартам XML.

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

    Корневым элементом в схеме XDR всегда является элемент Schema:

    Элемент ElementType имеет синтаксис:

    Элемент ElementType может иметь следующие атрибуты:

    Тип данных элемента

    Может принимать значения:

    Open – разрешено использовать элементы, не определенные в схеме

    Closed – запрещено использовать элементы, не определенные в схеме

    Порядок следования дочерних элементов в экземпляре XML. Допустимые значения:

    one – предполагается наличие одного документа

    many – любое количество элементов в любом порядке

    seq – элементы указываются в строго заданном порядке.

    качестве дочерних элементов для ElementType можно использовать следующие:

    Объявляет дочерний элемент

    Обеспечивает описание элемента ElementType

    Обеспечивает тип данных элемента ElementType

    Определяет порядок следования элементов

    Определяет сведения о дочернем элементе AttributeType

    Для объявления атрибутов используется синтаксис:

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

    Значение по умолчанию

    Один из следующих типов:

    entity, entities, enumeration, id, idref, nmtoken, nmtokens, notation, string

    Указывает на обязательное наличие атрибута в описании

    Синтаксис для описания элемента attribute выглядит следующим образом:

    а его возможные значения могут быть такими:

    Используйте для определения структуры XML-документов XML-схемы вместо DTD

    XML-схема обладает более мощными возможностями, чем DTD. Для иллюстрации преимуществ использования механизма XML-схем в первых трех листингах сравниваются различные способы представления элементов. В представлена выдержка из XML-документа. В показаны два элемента, объявленные в синтаксисе DTD, а в представлен синтаксис, соответствующий XML-схеме. Обратите внимание, что синтаксис в Листинге 3 подобен синтаксису XML. При использовании схемы, валидирующий парсер может выполнить проверку, является ли элемент InvoiceNo положительным целым числом, и состоит ли ProductID из заданного набора символов (шести цифр и одной буквы от A до Z). Парсер, обрабатывающий DTD-определение, может лишь подтвердить, что данные элементы представляют собой строки.

    Листинг 1: Фрагмент XML-документа
    Листинг 2: Фрагмент DTD, описывающий элементы из Листинга 1
    Листинг 3: Фрагмент XML-схемы, описывающий элементы из Листинга 1

    Использование пространств имен в XML-схеме

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

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

    Согласно DTD элемент может быть представлен одним из трех способов:

    • Текстовая строка
    • Текстовая строка, смешанная с другим дочерним элементом
    • Набор дочерних элементов

    DTD не обладает синтаксисом XML и предлагает лишь ограниченную поддержку для типов и пространств имен.

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

    Такая XML-схема определяет набор новых имен, таких как имена элементов, типов, атрибутов, групп атрибутов, чьи определения и объявления описаны в схеме. В имена определяются как InvoiceNo , ProductID и ProductCode .

    Имена, определенные в схеме принадлежат так называемому целевому пространству имен . Само по себе пространство имен является фиксированным, произвольным именем, которое должно соответствовать синтаксису URL. К примеру, пространство имен для схемы, представленной в , можно задать следующим образом: http://www.SampleStore.com/Account .

    Синтаксис объявления пространства имен иногда может сбить с толку. Объявление начинается с http:// , однако оно не ссылается на файл с описанием схемы. На самом деле, ссылка http://www.SampleStore.com/Account вообще не ведет ни на один файл, а только на назначенное имя.

    Определения и объявления в схеме могут ссылаться на имена, которые могут принадлежать другим пространствам имен. В данной статье мы ссылаемся на такие пространства имен как на исходные пространства имен . В каждой схеме может быть определено одно целевое пространство имен и возможно множество исходных пространств имен. Вообще, каждое имя в заданной схеме принадлежит некоему пространству имен. Имена пространства имен могут быть довольно длинными, однако их можно сократить при помощи синтаксиса объявления xmlns в документе XML-схемы. Все эти концепции проиллюстрированы в .

    Листинг 4: Целевое и исходное пространства имен

    В XML-схеме, представленной с , пространством имен targetNamespace является http://www.SampleStore.com/Account , оно содержит имена InvoiceNo , ProductID и ProductCode . Имена schema , element , simpleType , pattern , string и positive-integer принадлежат исходному пространству имен http://www.w3.org/1999/XMLSchema , которое сокращается как xsd путем объявления xmlns . В псевдониме xsd нет ничего особенного, можно выбрать и другое имя. Для удобства и простоты в оставшейся части статьи мы будем использовать префикс xsd для ссылки на пространство имен http://www.w3.org/1999/XMLSchema , пропуская уточнение xsd в некоторых частях кода. В нашем примере targetNamespace является также одним из исходных пространств имен, так как имя ProductCode используется в определении других имен.

    Рисунок 1: Пространства имен для Листинга 4
    Листинг 5: Множество исходных пространств имен, импорт пространства имен

    Определение элементов

    Определением элемента заключается в определении его имени и модели контента. В XML-схеме модель контента элемента определяется его типом. Следовательно, элементы в XML-документе могут иметь только значения, которые подходят типам, определенным в его схеме.

    Простые типы

    Спецификация XML-схемы определяет несколько простых типов для значений, как показано в Таблице 2 -предопределенные простые типы значений.

    Тип элемента может быть простым или комплексным (сложным). Элемент простого типа не может содержать другие элементы или атрибуты. Комплексный тип может создавать эффект встраивания элементов в другие элементы или может ассоциировать атрибуты с элементом. До этого момента мы использовали только примеры с простыми типами, определенными пользователем (см. ProductCode). В спецификацию XML-схемы также включены предопределенные простые типы (см. вставку ). Предопределенный простой тип ограничивает значения по их базовому типу. К примеру, значением предопределенного простого типа ProductCode является подмножество значений базового типа string .

    Простые, не вложенные элементы имеют простой тип

    Элемент, который не содержит атрибутов или других элементов может быть отнесен к простому типу, предопределенному или определенному пользователем, такому как string , integer , decimal , time , ProductCode и т.п.

    Листинг 7: Некоторые простые типы элементов

    Элементы с атрибутами должны иметь комплексный тип

    Теперь попробуем добавить к простому элементу price из атрибут currency . Вы не сможете этого сделать, так как элемент простого типа не может иметь атрибутов. Если вы хотите добавить атрибут, вам необходимо определить price как элемент комплексного типа. В примере из , мы определяем, так называемый анонимный тип , в котором комплексному типу не дается явного имени. Другими словами, атрибут name элемента complexType не определен.

    Листинг 8: Элемент комплексного типа

    Элементы, содержащие вложенные элементы должны иметь комплексный тип

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

    Таблица 1: Сравнение комплексных типов данных в DTD и XML-схеме

    XML-документ


    XML-схема
    Листинг 10: Скрытие BookType как локального типа

    Выражение сложных ограничений для элементов

    XML-схема предлагает большую гибкость, чем DTD при выражении ограничений для модели контента элементов. На простейшем уровне, таком как в DTD, вы можете ассоциировать с элементом атрибуты, а также указать, что в нем может появляться последовательность из только одного (1), нуля или более (*), или одного или более (+) элементов из заданного набора элементов. В XML-схеме можно выразить дополнительные ограничения, используя для этой цели, к примеру, атрибуты minOccurs и maxOccurs для элемента element и элементы choice , group и all .

    Листинг 11: Выражение ограничений для типов элементов

    В тег Title является опциональным по отношению к тегу Book (такое же правило можно задать и в DTD). Однако здесь также говорится, что в элементе Book должен быть хотя бы один и не более двух элементов Author . Значением атрибутов minOccurs и maxOccurs тега element по умолчанию является 1. Элемент choice указывает на то, что может появиться только один из указанных дочерних элементов. Другой элемент all определяет, что все дочерние элементы могут появляться только один раз, вместе и в любом порядке, или не появляться совсем. В объявляется, что оба тега Title и Author должны появляться в Book в любом порядке, или не появляться вообще. Подобные ограничения сложно выразить при помощи DTD.

    Листинг 12: Указатель того, что у элемента должны быть определены все типы

    Подведение итогов

    В данном документе мы раскрыли при помощи простых примеров наиболее фундаментальные концепции, необходимые для определения структуры элементов при помощи XML-схемы. Доступно также множество других мощных механизмов:

    • XML-схема содержит всестороннюю поддержку для наследования типов, позволяя повторно использовать определенные ранее структуры. Такое использование называют аспектами . Вы можете вывести новые типы, представляющие меньшее подмножество значений других типов, к примеру, для определения подмножества по перечислению, диапазону или по совпадению с шаблоном. В одном из примеров данной статьи тип ProductCode был определен с использованием аспекта pattern . В подтипе также можно добавить для базового типа новые элементы и атрибуты.
    • Несколько механизмов, позволяющих контролировать общее определение подтипа или заменять его в определенном документе. К примеру, можно указать, что тип InvoiceType (тип номера инвойса) не может содержать подтипы, то есть никто не сможет определить новую версию InvoiceType . Можно также задать, что в отдельном контексте для типа ProductCode не может быть замещения подтипов.
    • Кроме использования подтипов, можно определять эквивалентные типы, то есть значение одного типа может быть замещено значением другого.
    • XML-схема обеспечивает механизм для замещения элемента или типа путем объявления их как абстрактных.
    • Для большего удобства можно обозначить и задать имена группам атрибутов или элементов. Это позволяет повторно использовать их при последующих обращениях.
    • XML-схема предоставляет три элемента – appInfo , documentation и annotation – для использования комментариев, как людьми (documentation) так и приложениями (appInfo)
    • Вы можете выразить уникальные ограничения, основывающиеся на определенных атрибутах дочерних элементов.

    Дополнительную информацию по XML-схемам можно получить из документаций на сайтах W3C (См. ) и dW XML zone. Теперь, когда спецификация XML-схемы получила подтверждение в качестве кандидата на рекомендацию W3C, вы без сомнения можете использовать ее в полной мере.

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

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

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

    Атрибут имя_корневого_элемента соответствует имени корневого элемента в тегах, содержащих весь документ XML. В секции «прочих объявлений» находятся определения элементов, атрибутов и т. д.

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

    Как и в случае с внутренним объявлением DTD, имя_корневого_элемента должно соответствовать имени корневого элемента в тегах, содержащих весь документ XML. Атрибут SYSTEM указывает на то, что some_dtd.dtd находится на локальном сервере. Впрочем, на файл some_dtd.dtd также можно сослаться по его абсолютному URL. Наконец, в кавычках указывается URL внешнего DTD, расположенного на локальном или на удаленном сервере.

    Как же создать DTD для листинга 14.1? Во-первых, мы собираемся создать в документе XML ссылку на внешний DTD. Как упоминалось в предыдущем разделе, ссылка на DTD выглядит так:

    Возвращаясь к листингу 14.1, мы видим, что cookbook является именем корневого элемента, a cookbook.dtd — именем DTD-файла. Содержимое DTD показано в листинге 14.2, а ниже приведены подробные описания всех строк.

    Листинг 14.2. DTD для листинга 14.1(cookbook.dtd)

    Что же означает этот загадочный документ? Несмотря на внешнюю сложность, в действительности он довольно прост. Давайте переберем все содержимое листинга 14.2:

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

    Третья строка описывает элемент XML, в данном случае — корневой элемент cookbook. После него следует слово recipe, заключенное в круглые скобки. Это означает, что в теги cookbook заключается вложенный тег с именем recipe. Знак + говорит о том, что в родительских тегах cookbook находится одна или несколько пар тегов recipe.

    Четвертая строка описывает тег recipe. В ней сообщается, что в тег recipe входят четыре вложенных тега: title, description, ingredients и process. Поскольку после имен тегов не указываются признаки повторения(см. следующий раздел), внутри тегов recipe должна быть заключена ровно одна пара каждого из перечисленных тегов.

    Перед нами первое определение тега, который не содержит вложенных тегов. В соответствии с определением он содержит #PCDATA, то есть произвольные символьные данные, не считающиеся частью разметки.

    В соответствии с определением элемент ingredients содержит один или несколько тегов с именем ingredient. Обратитесь к листингу 14.1, и вы все поймете.

    Поскольку элемент ingredient соответствует отдельному ингредиенту, вполне логично, что этот элемент содержит простые символьные данные.

    Элемент process содержит один или несколько экземпляров элемента step.

    Элемент step, как и элемент ingredient, соответствует отдельному пункту в списке более высокого уровня. Следовательно, он должен содержать символьные данные.

    Обратите внимание: элемент recipe в листинге 14.1 содержит атрибут. Этот атрибут, category, определяет общую категорию, к которой относится рецепт — в приведенном примере это категория «итальянская кухня»(Italian). В определении ATTLIST указывается как имя элемента, так и имя атрибута. Кроме того, отнесение каждого рецепта к определенной категории упрощает классификацию, поэтому атрибут объявляется обязательным(#REQUIRED).

    Последняя строка просто завершает определение DTD. Определение всегда должно быть должным образом завершено, иначе произойдет ошибка.

    В завершение этого раздела я приведу сводку основных компонентов типичного DTD-файла:

    • объявления типов элементов;
    • объявления атрибутов;
    • ID, IDREF и IDREFS;
    • объявления сущностей.

    Некоторые из этих компонентов уже встречались нам в описании листинга 14.2. Далее каждый компонент будет описан более подробно.

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

    Все элементы, используемые в документе XML, должны быть определены в DTD, прилагаемом к документу. Мы уже встречались с двумя распространенными разновидностями определений: для элемента, содержащего другие элементы, и элемента, содержащего символьные данные. Данное определение свидетельствует, что элемент содержит только символьные данные:

    Следующее определение элемента process говорит о том, что он содержит ровно один вложенный элемент с именем step:

    Впрочем, процессы(process) из одного шага(step) встречаются довольно редко — скорее всего, шагов будет несколько. Чтобы указать, что элемент содержит один или несколько экземпляров вложенного элемента step, следует воспользоваться признаком повторения:

    Количество вложенных элементов можно задать несколькими способами. Полный список операторов элементов приведен в табл. 14.1.

    Таблица 14.1. Операторы элементов

    Если элемент будет содержать несколько вложенных элементов, их следует перечислить через запятую в определении родительского элемента:

    Поскольку признаки повторения не указаны, каждый тег должен встречаться ровно один раз.

    Определение элемента уточняется при помощи логических операторов. Предположим, вы работаете с рецептами, в которые всегда входят макароны(pasta) с одним или несколькими типами сыра(cheese) или мяса(meat). В этом случае элемент ingredient определяется следующим образом:

    Поскольку элемент pasta обязательно должен присутствовать в элементе ingredient, он указывается с признаком повторения +. Затем следует либо элемент cheese, либо элемент meat; мы разделяем альтернативы вертикальной чертой и заключаем их в круглые скобки со знаком +, поскольку в рецепт всегда входит либо одно, либо другое.

    Существуют и другие разновидности определений элементов. Мы рассмотрели лишь простейшие случаи. Тем не менее, приведенного материала вполне достаточно для понимания примеров, приведенных в оставшейся части этой главы.

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

    Атрибуты элементов описывают значения, связываемые с элементами. Элементы XML, как и элементы HTML, могут иметь ноль, один или несколько атрибутов. Общий синтаксис объявления атрибутов выглядит следующим образом:

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

    Форматировать объявления подобным образом необязательно; тем не менее, многострочные объявления нагляднее однострочных. Кроме того, поскольку оба атрибута являются обязательными, тег reci ре не может ограничиться каким-нибудь одним атрибутом, он должен включать в себя оба атрибута сразу. Например, следующий тег будет считаться неверным:

    Почему? Потому что в нем отсутствует атрибут category. Правильный тег должен содержать оба атрибута:

    Особые условия обработки атрибута описываются тремя флагами, перечисленными в табл. 14.2.

    Таблица 14.2. Флаги атрибутов

    Типы атрибутов

    Атрибут элемента может объявляться с определенным типом. Типы атрибутов описаны далее.

    Атрибуты CDATA

    Очень часто атрибуты содержат общие символьные данные. Такие атрибуты называются атрибутами CDATA. Следующий пример уже встречался в начале этого раздела:

    Атрибуты ID, IDREF и IDREFS

    Идея однозначного представления данных(например, информации о пользователе или товаре, хранящейся в базе данных) посредством идентификаторов неоднократно встречалась в предыдущих главах книги. Идентификаторы также часто используются в XML, поскольку перекрестные ссылки между документами применяются не только в общих задачах обработки данных, но и в World Wide Web(гиперссылки).

    Идентификаторы элементов присваиваются атрибуту ID. Допустим, вы хотите связать с каждым рецептом уникальный идентификатор. Соответствующий фрагмент DTD может выглядеть так:

    После этого объявление элемента recipe в документе может выглядеть так:

    Spaghetti alla Carbonara

    Рецепт однозначно определяется идентификатором ital003. Следует помнить, что атрибут redpe-id относится к типу ID, поэтому ital003 не может использоваться в качестве значения атрибута recipe-id другого элемента, в противном случае документ будет считаться синтаксически неверным. Теперь допустим, что позднее вы захотели сослаться на этот рецепт из другого документа — скажем, из списка любимых рецептов пользователя. Именно здесь в игру вступают перекрестные ссылки и атрибут IDREF. Атрибуту IDREF присваивается идентификатор, используемый для ссылок на элемент, — по аналогии с тем, как URL используется для идентификации страницы в гиперссылке. Рассмотрим следующий фрагмент кода XML:

    В процессе обработки документа XML элемент заменяется более наглядной ссылкой на рецепт с указанным идентификатором(например, названием рецепта). Вероятно, он будет отформатирован в виде гиперссылки, чтобы упростить переход к указанному рецепту.

    Перечисляемые атрибуты

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

    Если атрибут category не задан явно, по умолчанию ему присваивается значение Italian.

    Атрибуты ENTITY и ENTITIES

    Данные в документах XML не всегда являются текстовыми — документ может содержать и двоичную информацию(например, графику). На такие данные можно ссылаться при помощи атрибута entity. Например, в описании элемента description можно указать атрибут recipePicture с графическим изображением:

    Также можно объявить сразу несколько сущностей, заменив ENTITY на ENTITIES. Значения разделяются пробелами.

    Атрибуты NMTOKEN и NMTOKENS

    Атрибуты NMTOKEN представляют собой строки из символов, входящих в ограниченный набор. Объявление атрибута с типом NMTOKEN предполагает, что значение атрибута соответствует установленным ограничениям. Как правило, значение атрибута NMTOKEN состоит из одного слова:

    Можно объявить сразу несколько атрибутов, заменив NMTOKEN на NMTOKENS. Значения разделяются пробелами.

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

    Объявление сущности напоминает команду define в некоторых языках программирования, включая РНР. Ссылки на сущности кратко упоминались в предыдущем разделе «Знакомство с синтаксисом XML». На всякий случай напомню, что ссылка на сущность используется в качестве замены для другого фрагмента содержания. В процессе обработки документа XML все вхождения сущности заменяются содержанием, которое она представляет. Существует два вида сущностей: внутренние и внешние.

    Внутренние сущности

    Внутренние сущности напоминают строковые переменные, связывающие имя с фрагментом текста. Например, если вы хотите определить имя для ссылки на информацию об авторских правах, можно объявить сущность следующего вида:

    В процессе обработки документа все экземпляры &Соруright заменяются текстом «Copyright 2000 YourCompanyName. All Rights Reserved». Весь код XML в заменяющем тексте обрабатывается так, словно он присутствовал в исходном документе.

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

    Внешние сущности

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

    При последующей обработке документа XML все ссылки &Соруright заменяются содержимым документа copyright.xml. Весь код XML в заменяющем тексте обрабатывается так, словно он присутствовал в исходном документе.

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

    Ресурсы, посвященные XML

    Хотя приведенного выше материала вполне достаточно для понимания базовой структуры документов XML, данное описание не является полным. Ниже приведены ссылки на ресурсы Интернета, содержащие более подробную информацию:

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

    Но стоит познакомиться с базовой стратегией работы с XML в РНР, и все оказывается на удивление просто.

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

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

    Синтаксис

    Основной синтаксис объявления атрибутов DTD следующим образом:

    В вышеуказанном синтаксисе

    Старт атрибутов DTD с ]> Tanmay Patil

    Препятствуйте нам пойти через вышеуказанный Код:

    Начните с объявлением XML с следующим заявлением:

    Немедленно после коллектора XML тип объявление документа, обыкновенно называемое DOCTYPE:

    Удостоверение личности атрибута для имени элемента определено как:

    Здесь тип атрибута CDATA и свое значение #REQUIRED .

    Правила объявления атрибута

    Все атрибуты используемые в документе XML необходимо объявить в определении типа документа (DTD) используя объявление Атрибут-Списка

    Атрибуты могут только появиться в старт или пустые бирки.

    Ключевое слово ATTLIST должно находиться в верхушке — случае

    Никакие двойные имена атрибута не будут позволены внутри список атрибута для, котор дали элемента.

    Типы атрибута

    Объявляя атрибуты, вы можете определить как обработчик должен отрегулировать данные которые появляются в значение. Мы можем классифицировать атрибут печатаем внутри 3 главным образом категории на машинке:

    Следовать таблица обеспечивает сводку различных типов атрибута:

    Тип Описание
    CDATA CDATA данные по характера (текст и не повышение цены). Тип атрибута строки .
    Удостоверение личности Это уникально обозначение атрибута. Оно не должен появиться больше чем раз. Тип атрибута Tokenized .
    IDREF Оно использован для того чтобы снабдить ссылками удостоверение личности другого элемента. Оно использован для того чтобы установить элементы связь между. Тип атрибута Tokenized .
    IDREFS Оно использован для того чтобы снабдить ссылками множественное удостоверение личности. Тип атрибута Tokenized .
    РЕАЛЬНОСТЬ Она представляет внешнюю реальность в документе. Тип атрибута Tokenized .
    РЕАЛЬНОСТИ Оно представляет список внешних реальностей в документе. Тип атрибута Tokenized .
    NMTOKEN Оно подобен к CDATA и атрибут со значением состоит из действительного имени XML. Тип атрибута Tokenized .
    NMTOKENS Оно подобен к CDATA и атрибут со значением состоит список действительного имени XML. Тип атрибута Tokenized .
    НОТАЦИЯ Элемент будет снабжен ссылками к объявленной нотации в документе DTD. Перечисленный тип атрибута .
    Обозначение Оно позволяет определить специфический список значений где одно из значений должно соответствовать. Перечисленный тип атрибута .

    Объявление атрибута со значением

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

    смогите иметь автоматически принимаемое значение

    смогите иметь фикчированное значение

    Автоматически принимаемые значения

    Он содержит автоматически принимаемое значение. Значения могут быть заключили в одиночные кавычки («) или двойные цитаты («)

    Следование синтаксис значения:

    где значени по умолчанию-значение определенный атрибут со значением.

    Следование простой пример объявления атрибута с автоматически принимаемым значением:

    В этом примере мы имеем элемент имени с удостоверением личности атрибута которого автоматически принимаемое значение . Автоматически принимаемое значение заключено в пределах двойных цитат.

    ФИКЧИРОВАННЫЕ значения

    ключевое слово #FIXED следовать фикчированным значением использовано когда вы хотите определить что атрибут со значением постоянн и не может быть изменен. Общяя польза фикчированных атрибутов определяет номера версии.

    Следование синтаксис фикчированных значений:

    где #FIXED определенный атрибут со значением.

    Следование простой пример объявления атрибута с ФИКЧИРОВАННЫМ значением:

    В этом примере мы использовали #FIXED ключевого слова где оно показывает что значение «tutorialspoint» единственное значение для имени атрибута элемента. Если мы пробуем изменить атрибут со значением после этого, то он дает ошибку.

    Следование инвалидный DTD:

    НЕОБХОДИМЫЕ значения

    Когда вы хотите определите что атрибут необходим, используйте ключевое слово #REQUIRED.

    Следование синтаксис #REQUIRED:

    где #REQUIRED определенный тип атрибута.

    Следование простой пример объявления атрибута DTD с ключевым словом #REQUIRED:

    В этом примере мы использовали ключевое слово #REQUIRED для того чтобы определить что удостоверение личности атрибута необходимо предусмотреть для имени элемент- имени

    ПОДРАЗУМЕВАЕМЫЕ значения

    Объявляя атрибуты вы должны всегда определять объявление значения. Если атрибут вы объявляете не имеет никакое автоматически принимаемое значение, то не имеет никакое фикчированное значение, и не требует, тогда вы должны объявить что атрибут как подразумевали . #IMPLIED ключевого слова использовано для того чтобы определить атрибут как подразумевали .

    Следование синтаксис #IMPLIED:

    где #IMPLIED определенный тип атрибута.

    Следование простой пример #IMPLIED

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

    DTD — Атрибуты. Язык XML — Documents Type Definitions (DTD)

    Аннотация: В данном разделе описываются общие принципы написания Определение типа документа. Так же рассмотрены основные недостатки и особенности DTD.


    Зачем нужно DTD.

    Создавая XML документ разработчик сам решает: как назвать теги, в каком порядке они будут следовать, какие данные будут записаны в том или ином элементе, будут ли у элемента атрибуты или нет и многое другое. Без формального описания структуры документа этим самым документом может воспользоваться только его разработчик. В случае если разработанный XML документ предназначен для передачи во внешний мир, например партнерам по бизнесу, и если к тому же планируется получать в ответ документы, написанные в том же самом формате без определения типов документов ( Document Type Definition , DTD ) не обойтись. Это связано с тем, что для того, что бы обе стороны могли понимать полученную информацию элементы и атрибуты в документах должны употребляться всеми сторонами одинаково. Определения типа документа вносят строгость и точность в правила написания правильно оформленных документов XML . Хранимые в начале файла XML или внешним образом в виде файла *.DTD , определения типов документов описывают информационную структуру документа. В DTD перечисляются возможные имена элементов, определяются имеющиеся атрибуты для каждого типа элементов и описывается вложенность элементов.

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

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

    Написание определений DTD: общие принципы.

    Ассоциирование DTD с документом XML

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

    Декларация DOCTYPE содержит ключевое слово DOCTYPE , за которым следует имя корневого элемента документа, а затем конструкция с декларациями содержания. Перед разъяснением этого утверждения рассмотрим пример расположения декларации DOCTYPE в экземпляре документа. Ниже приводятся первые три строчки документа XML:

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

    Декларации XML могут содержать атрибут standalone, принимающий только значения «yes» и «nо». Если значение атрибута равно yes, то внешние для экземпляра документа декларации не влияют на информацию, передаваемую документом использующему его приложению. Значение no показывает, что существуют внешние декларации со значениями, необходимыми для правильного описания содержания документа — например конкретные значения по умолчанию. На практике необязательный атрибут standalone используется редко. Наличие этого атрибута со значением, yes не гарантирует отсутствия внешних зависимостей любого типа. Просто внешние зависимости в этом случае не приведут к ошибке в документе, если не будут включены в обработку. Таким образом, в основном этот атрибут представляет собой знак для анализаторов и других приложений, показывающий, нужно ли им использовать какое-либо внешнее содержание.

    Блок внутренней декларации разметки тега DOCTYPE состоит из левой квадратной скобки, списка деклараций и правой квадратной скобки:

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

    Внешние DTD в некоторых отношениях более гибкие. В данном случае декларация DOCTYPE состоит из обычного ключевого слова и имени корневого элемента, за которым следует еще одно ключевое слово SYSTEM либо PUBLIC , обозначающее источник внешнего определения DTD , а за ним — локализация этого определения. Если ключевое слово SYSTEM , DTD обязано непосредственно и явным образом находится по указанному URL адресу.

    Если внешние DTD переписываются очень часто, они начинают терять свое значение, а это признак плохого первоначального проекта.

    Ключевое слова PUBLIC предназначено для хорошо известных словарей. Приложение, анализирующее документ из этого словаря, должно использовать некоторую стратегию по поиску соответствующего DTD .

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

    Основные декларации разметки

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

    Первые два типа связаны с информацией, которую мы рассчитываем найти в документе XML, — элементами и атрибутами.

    Последние два типа используются для поддержки. Особенно облегчают жизнь разработчика словаря XML сущности. Как правило, они состоят из содержания, которое настолько часто используется в DTD или документе, что оправдывает создание специальной декларации. Применение этой декларации напоминает оператор include в языках C/C++ , когда в качестве замены для содержания используется имя.

    Нотации описывают содержание, разработанное не на языке XML. Используются они для того, чтобы объявить конкретный класс данных и связать его с внешней программой. Эта внешняя программа становится обработчиком объявленного класса данных. Например, связав с документом изображение в формате JPEG, разработчик желает, чтобы программа приняла и визуализировала двоичные данные в этом формате. Конечно, в таком случае документ зависит от того, какой обработчик имеется в системе, получающей документ. В интересах портативности и переносимости некоторые авторы не приводят ссылки на обработчики. В таком случае нотация превращается просто в механизм набора текста.

    Как раз таковыми и являются. Причём XML сам по себе предусматривает расширяемость. Документы созданные с помощью этих языков могут быть «корректными (well-formed)» и «допустимыми (valid)».

    С проверкой документа на корректность проблем не возникает: если ошибок не выскочило и всё отобразилось так, как мы хотели, то документ корректен. Например, если в HTML-документе написать что-то вроде « Привет! », то наш документ будет полностью корректен, но проигнорирован браузером. Почему? Потому что браузер ничего не знает о том, что это за «Z» такой. И если мы проверим наш документ на допустимость с помощью валидатора , то документ таковым признан не будет. А как об этом узнает валидатор и на основании чего он вынес такой вердикт?

    Допустимость проверяется с помощью определения типа документа (DTD, document type definition). Например, для «строгого» HTML он выглядит так .

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

    Объявление DTD

    Объявление DTD располагается перед первым (корневым) элементом документа, начинается с последовательности « ».

    Внутреннее DTD описывается так:

    Между квадратными скобками располагается содержимое DTD, так называемое внутреннее подмножество , например:

    Если DTD вынесено в отдельный файл (обычно имеющий расширение.dtd), то его объявление в документе записывается так:

    Соответственно, в этом файле и прописываются все правила, так называемое внешнее подмножество .

    Имя, указанное за словом « DOCTYPE » (в нашем случае « catalog »), должно соответствовать имени корневого элемента. То есть, XML-документ должен быть примерно таким:

    Вместо ключевого слова « SYSTEM » может быть использовано слово « PUBLIC », указывающее, что DTD применяется для широкого использования:

    Внутренние и внешние подмножества могут быть заданы одновременно (опять же, аналогия с CSS):

    Здесь, сначала зачитывается содержимое файла « catalog.dtd », а потом содержимое, указанное внутри квадратных скобок.

    Элементы документа

    Элементы объявляются в DTD с помощью ключевого слова « ELEMENT », после которого следует имя элемента и его содержимое заключенное в круглые скобки:

    Если у элемента есть дочерние элементы, то это записывается так:

    что соответствует документу:

    Если у элемента несколько дочерних элементов, то они перечисляются через запятую и должны следовать строго в указанном порядке:

    Приведённый выше пример читается следующим образом. Элемент « book » должен содержать только один элемент « title », за которым должен следовать только один элемент « author ». Сами элементы « title » и « author » никаких элементов не содержат, а могут содержать лишь какой-нибудь текст.

    С помощью следующих специальных символов можно определять количественное присутствие элемента:

    • Символ « * », следующий после элемента, означает, что элемент может присутствовать один или несколько раз, или не присутствовать вовсе(от нуля до + бесконечности)
    • Символ « + », следующий после элемента, означает, что элемент может присутствовать один или несколько раз(от 1 до + бесконечности)
    • Символ « ? », следующий после элемента, означает, что элемент может либо отсуствовать, либо присутствовать только один раз(0 или 1)

    . . .

    Если существует необходимость указать один из нескольких элементов (или title, или author — любой из них, но не оба), надо испольовать символ « | »:

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

    Следующий фрагмент документа валиден вышеприведенному примеру:

    Группы элементов заключаются в круглые скобки. Элемент « book » должен содержать либо текст, либо (один « title », один или неколько « author » и может быть один « pubyear » именно в таком порядке):

    Данному примеру соответствует следующий фрагмент XML-документа:

    Элемент может быть пустым. Такой элемент не может содержать не дочерних элементов ни текста (например, элемент « br » в HTML). Такой элемент задается с ключевым словом « EMPTY »:

    Элемент также может быть объявлен с ключевым словом « ANY » означающее, что элемент может содержать и элементы, и текст, и все это вместе, и даже быть пустым.

    Атрибуты элементов

    Элементы в XML-документе могут иметь атрибуты, которые записываются в виде « имя = значение » в открывающем или пустом тегах. Общее объявление атрибутов конкретного элемента начинается с ключевого слова « ATTLIST », после которого следует имя данного элемента и объявления самих атрибутов:

    Ключевое слово « REQUIRED » указывает на то, что атрибут обязателен. Ключевое слово « IMPLIED », наоборот, говорит, что атрибут необязателен.

    У атрибутов могут быть перечисленны разрешенные значения:

    Также может быть задано значение по-умолчанию:

    pubyear CDATA #IMPLIED «2007»>

    Атрибут может быть и константой, то есть у него может быть только то значение, которое заявлено в объявлении атрибута. Делается это с помощью ключевого слова « FIXED »:

    Тип атрибута « CDATA »позволяет использовать любые символы кроме « », « & », « » » и « » ». В случае использования, данные символы должны быть заменены на спецсимволы типа «

    Еще один тип атрибута « ID » разрешает задавать те же значения, что и тип NMTOKEN, но начинаться значение должно либо с буквы, либо с « _ », либо с « : ». У любого элемента может быть только один атрибут с типом « ID ». Атрибут типа « ID » не может быть константой (объявляться как « FIXED »). Значение атрибута типа « ID » должно быть уникальным для всего XML-документа:

    Атрибут элемента может быть ссылкой на атрибут типа « ID » другого элемента. Для этого он объявляется как атрибут типа « IDREF ». Если атрибут должен ссылаться на атрибут типа « ID » нескольких элементов, то испольуется ключевое слово « IDREFS »:

    В XML-документе это будет выглядить так:

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

    Помимо элементов и их атрибутов, мы можем определить сущности , записываемые с помощью ключевого слова « ENTITY »:

    В результате чего, на место имени сущности « name », будет подставлено ее значение, в нашем случае — « SuperMegaMaster ».

    И для полноты нашего счастья, надо добавить, что атрибуты элементов могут иметь в качестве значения подобные сущности — сущности-атрибуты . Они тоже определяются с помощью ключевого слова « ENTITY », но имеют одно ограничение — они должны ссылаться на внешние неанализируемые сущности, определенные во внешнем подмножестве DTD:

    В вышеприведённом примере, объявлена сущность « list », которая ссылается на внешний документ « companyList.html ». Ключевое слово « NDATA », говорит о том, что внешний документ неявляется XML-документом. Далее, для элемента « user » объявляется атрибут « company », который является обязательным и имеет тип « ENTITY », то есть ссылается на какую-либо сущность. Поскольку в нашем пример задана только одна сущность (« list »), то именно она и только она может быть значением атрибута « company » в XML-документе:

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

    Слово « parse » в объявлении сущности лист указывает на то, каким образом можно проанализировать файл « companyList.html » — найти нотацию с именем « parse » и следовать ее указаниям. В нашем случае, приложение может открыть MS InternetExplorer и загрузить в него документ « companyList.html ».

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

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

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

    Атрибут имя_корневого_элемента соответствует имени корневого элемента в тегах, содержащих весь документ XML. В секции «прочих объявлений» находятся определения элементов, атрибутов и т. д.

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

    Как и в случае с внутренним объявлением DTD, имя_корневого_элемента должно соответствовать имени корневого элемента в тегах, содержащих весь документ XML. Атрибут SYSTEM указывает на то, что some_dtd.dtd находится на локальном сервере. Впрочем, на файл some_dtd.dtd также можно сослаться по его абсолютному URL. Наконец, в кавычках указывается URL внешнего DTD, расположенного на локальном или на удаленном сервере.

    Как же создать DTD для листинга 14.1? Во-первых, мы собираемся создать в документе XML ссылку на внешний DTD. Как упоминалось в предыдущем разделе, ссылка на DTD выглядит так:

    Возвращаясь к листингу 14.1, мы видим, что cookbook является именем корневого элемента, a cookbook.dtd — именем DTD-файла. Содержимое DTD показано в листинге 14.2, а ниже приведены подробные описания всех строк.

    Листинг 14.2. DTD для листинга 14.1(cookbook.dtd)

    Что же означает этот загадочный документ? Несмотря на внешнюю сложность, в действительности он довольно прост. Давайте переберем все содержимое листинга 14.2:

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

    Третья строка описывает элемент XML, в данном случае — корневой элемент cookbook. После него следует слово recipe, заключенное в круглые скобки. Это означает, что в теги cookbook заключается вложенный тег с именем recipe. Знак + говорит о том, что в родительских тегах cookbook находится одна или несколько пар тегов recipe.

    Четвертая строка описывает тег recipe. В ней сообщается, что в тег recipe входят четыре вложенных тега: title, description, ingredients и process. Поскольку после имен тегов не указываются признаки повторения(см. следующий раздел), внутри тегов recipe должна быть заключена ровно одна пара каждого из перечисленных тегов.

    Перед нами первое определение тега, который не содержит вложенных тегов. В соответствии с определением он содержит #PCDATA, то есть произвольные символьные данные, не считающиеся частью разметки.

    В соответствии с определением элемент ingredients содержит один или несколько тегов с именем ingredient. Обратитесь к листингу 14.1, и вы все поймете.

    Поскольку элемент ingredient соответствует отдельному ингредиенту, вполне логично, что этот элемент содержит простые символьные данные.

    Элемент process содержит один или несколько экземпляров элемента step.

    Элемент step, как и элемент ingredient, соответствует отдельному пункту в списке более высокого уровня. Следовательно, он должен содержать символьные данные.

    Обратите внимание: элемент recipe в листинге 14.1 содержит атрибут. Этот атрибут, category, определяет общую категорию, к которой относится рецепт — в приведенном примере это категория «итальянская кухня»(Italian). В определении ATTLIST указывается как имя элемента, так и имя атрибута. Кроме того, отнесение каждого рецепта к определенной категории упрощает классификацию, поэтому атрибут объявляется обязательным(#REQUIRED).

    Последняя строка просто завершает определение DTD. Определение всегда должно быть должным образом завершено, иначе произойдет ошибка.

    В завершение этого раздела я приведу сводку основных компонентов типичного DTD-файла:

    • объявления типов элементов;
    • объявления атрибутов;
    • ID, IDREF и IDREFS;
    • объявления сущностей.

    Некоторые из этих компонентов уже встречались нам в описании листинга 14.2. Далее каждый компонент будет описан более подробно.

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

    Все элементы, используемые в документе XML, должны быть определены в DTD, прилагаемом к документу. Мы уже встречались с двумя распространенными разновидностями определений: для элемента, содержащего другие элементы, и элемента, содержащего символьные данные. Данное определение свидетельствует, что элемент содержит только символьные данные:

    Следующее определение элемента process говорит о том, что он содержит ровно один вложенный элемент с именем step:

    Впрочем, процессы(process) из одного шага(step) встречаются довольно редко — скорее всего, шагов будет несколько. Чтобы указать, что элемент содержит один или несколько экземпляров вложенного элемента step, следует воспользоваться признаком повторения:

    Количество вложенных элементов можно задать несколькими способами. Полный список операторов элементов приведен в табл. 14.1.

    Таблица 14.1. Операторы элементов

    Если элемент будет содержать несколько вложенных элементов, их следует перечислить через запятую в определении родительского элемента:

    Поскольку признаки повторения не указаны, каждый тег должен встречаться ровно один раз.

    Определение элемента уточняется при помощи логических операторов. Предположим, вы работаете с рецептами, в которые всегда входят макароны(pasta) с одним или несколькими типами сыра(cheese) или мяса(meat). В этом случае элемент ingredient определяется следующим образом:

    Поскольку элемент pasta обязательно должен присутствовать в элементе ingredient, он указывается с признаком повторения +. Затем следует либо элемент cheese, либо элемент meat; мы разделяем альтернативы вертикальной чертой и заключаем их в круглые скобки со знаком +, поскольку в рецепт всегда входит либо одно, либо другое.

    Существуют и другие разновидности определений элементов. Мы рассмотрели лишь простейшие случаи. Тем не менее, приведенного материала вполне достаточно для понимания примеров, приведенных в оставшейся части этой главы.

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

    Атрибуты элементов описывают значения, связываемые с элементами. Элементы XML, как и элементы HTML, могут иметь ноль, один или несколько атрибутов. Общий синтаксис объявления атрибутов выглядит следующим образом:

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

    Форматировать объявления подобным образом необязательно; тем не менее, многострочные объявления нагляднее однострочных. Кроме того, поскольку оба атрибута являются обязательными, тег reci ре не может ограничиться каким-нибудь одним атрибутом, он должен включать в себя оба атрибута сразу. Например, следующий тег будет считаться неверным:

    Почему? Потому что в нем отсутствует атрибут category. Правильный тег должен содержать оба атрибута:

    Особые условия обработки атрибута описываются тремя флагами, перечисленными в табл. 14.2.

    Таблица 14.2. Флаги атрибутов

    Типы атрибутов

    Атрибут элемента может объявляться с определенным типом. Типы атрибутов описаны далее.

    Атрибуты CDATA

    Очень часто атрибуты содержат общие символьные данные. Такие атрибуты называются атрибутами CDATA. Следующий пример уже встречался в начале этого раздела:

    Атрибуты ID, IDREF и IDREFS

    Идея однозначного представления данных(например, информации о пользователе или товаре, хранящейся в базе данных) посредством идентификаторов неоднократно встречалась в предыдущих главах книги. Идентификаторы также часто используются в XML, поскольку перекрестные ссылки между документами применяются не только в общих задачах обработки данных, но и в World Wide Web(гиперссылки).

    Идентификаторы элементов присваиваются атрибуту ID. Допустим, вы хотите связать с каждым рецептом уникальный идентификатор. Соответствующий фрагмент DTD может выглядеть так:

    После этого объявление элемента recipe в документе может выглядеть так:

    Spaghetti alla Carbonara

    Рецепт однозначно определяется идентификатором ital003. Следует помнить, что атрибут redpe-id относится к типу ID, поэтому ital003 не может использоваться в качестве значения атрибута recipe-id другого элемента, в противном случае документ будет считаться синтаксически неверным. Теперь допустим, что позднее вы захотели сослаться на этот рецепт из другого документа — скажем, из списка любимых рецептов пользователя. Именно здесь в игру вступают перекрестные ссылки и атрибут IDREF. Атрибуту IDREF присваивается идентификатор, используемый для ссылок на элемент, — по аналогии с тем, как URL используется для идентификации страницы в гиперссылке. Рассмотрим следующий фрагмент кода XML:

    В процессе обработки документа XML элемент заменяется более наглядной ссылкой на рецепт с указанным идентификатором(например, названием рецепта). Вероятно, он будет отформатирован в виде гиперссылки, чтобы упростить переход к указанному рецепту.

    Перечисляемые атрибуты

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

    Если атрибут category не задан явно, по умолчанию ему присваивается значение Italian.

    Атрибуты ENTITY и ENTITIES

    Данные в документах XML не всегда являются текстовыми — документ может содержать и двоичную информацию(например, графику). На такие данные можно ссылаться при помощи атрибута entity. Например, в описании элемента description можно указать атрибут recipePicture с графическим изображением:

    Также можно объявить сразу несколько сущностей, заменив ENTITY на ENTITIES. Значения разделяются пробелами.

    Атрибуты NMTOKEN и NMTOKENS

    Атрибуты NMTOKEN представляют собой строки из символов, входящих в ограниченный набор. Объявление атрибута с типом NMTOKEN предполагает, что значение атрибута соответствует установленным ограничениям. Как правило, значение атрибута NMTOKEN состоит из одного слова:

    Можно объявить сразу несколько атрибутов, заменив NMTOKEN на NMTOKENS. Значения разделяются пробелами.

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

    Объявление сущности напоминает команду define в некоторых языках программирования, включая РНР. Ссылки на сущности кратко упоминались в предыдущем разделе «Знакомство с синтаксисом XML». На всякий случай напомню, что ссылка на сущность используется в качестве замены для другого фрагмента содержания. В процессе обработки документа XML все вхождения сущности заменяются содержанием, которое она представляет. Существует два вида сущностей: внутренние и внешние.

    Внутренние сущности

    Внутренние сущности напоминают строковые переменные, связывающие имя с фрагментом текста. Например, если вы хотите определить имя для ссылки на информацию об авторских правах, можно объявить сущность следующего вида:

    В процессе обработки документа все экземпляры &Соруright заменяются текстом «Copyright 2000 YourCompanyName. All Rights Reserved». Весь код XML в заменяющем тексте обрабатывается так, словно он присутствовал в исходном документе.

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

    Внешние сущности

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


    При последующей обработке документа XML все ссылки &Соруright заменяются содержимым документа copyright.xml. Весь код XML в заменяющем тексте обрабатывается так, словно он присутствовал в исходном документе.

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

    Ресурсы, посвященные XML

    Хотя приведенного выше материала вполне достаточно для понимания базовой структуры документов XML, данное описание не является полным. Ниже приведены ссылки на ресурсы Интернета, содержащие более подробную информацию:

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

    Но стоит познакомиться с базовой стратегией работы с XML в РНР, и все оказывается на удивление просто.

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

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

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

    Что такое DTD в XML и для чего он нужен

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

    Необходимость проверки грамматики XML-документов заключается в следующем:

    • XML-документ может быть предназначен не для вашей системы.
    • XML-документ может содержать неправильные данные.
    • XML-документ может содержать ошибки в структуре ().

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

    Недостатки XML DTD

    • Отличный от XML синтаксис языка. Это вызывает множество проблем, таких как, например, проблемы с кодировкой или невозможность отслеживать ошибки.
    • Нет проверки типов данных. В DTD есть только один тип – строка.
    • В DTD нет . Нельзя поставить в соответствие документу два и более DTD описаний.

    Это был краткий список недостатков DTD, которые с успехом исправлены в XML схемах, о которых мы поговорим в следующих статьях.

    Объявление элементов, атрибутов и сущностей в DTD. Модификаторы «*», «?», «+»

    Для объявления элементов, атрибутов и сущностей в DTD используются специальные декларации и модификаторы. Чтобы подробно во всем разобраться, давайте для начала рассмотрим теоритическую информацию, а затем во второй части статьи перейдем к практическим примерам.

    Определение элемента XML и последовательности элементов XML

    Элемент book содержит по одному элементу title, author, price и description.

    Элемент pricelist содержит элементы title, price и один элемент из трех на выбор – author, company либо sample.

    Элемент none должен быть пустым.

    Элемент pricelist может содержать два атрибута – атрибут id и атрибут name. При этом атрибут id является обязательным, так как указано #REQUIRED, а атрибут name – не обязательным (указано #IMPLIED). В свою очередь CDATA указывает обработчику, что разбирать содержимое атрибутов не нужно.

    Если встретится сущность «&myname;», то вместо нее автоматически подставится «Дмитрий Денисов».

    Модификаторы (объясняют повторения элементов)

    * — ноль или много.
    ? – ноль или один.
    + — один или много.

    Элемент books может содержать один или более элементов book.

    Теперь давайте рассмотрим, как это все выглядит на более практических примерах.

    Создание DTD-файла для валидации XML-документа на примере прайс-листа книг

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

    Конечно, вышеприведенный пример не является пределом мечтаний, но для примера вполне сойдет. Как видно с примера, у нас есть корневой элемент pricelist, который содержит вложенные элементы book. Внутри элементов book находятся элементы title, author, price и возможно description, которые могут содержать какие-то текстовые данные.

    Для валидации данного прайс-листа мы можем использовать DTD-документ следующего содержания.

    Теперь разберем все более подробно.

    • — декларируем корневой элемент books и в скобках указываем, что он может содержать. В данном случае он может содержать один или более элементов book (плюсик означает один или более, см. выше).
    • — определяем элемент book. Элемент book может содержать один элемент title, один или более элементов author (плюсик), один элемент price и один или ни одного элемента description (знак вопроса).
    • — определяем элемент title. В качестве содержимого элемента указываем #PCDATA. Это означает, что анализатор обязан разбирать то, что находится внутри этого элемента.
    • Аналогичным образом определяем элементы author, price, description.
    • — определяем сущность. Сначала пишем саму сущность, а затем в кавычках то, что будет выводиться на ее месте. По умолчанию в XML определено только 3 сущности. Это больше («>» — ) и амперсанд («&» — &). При желании вы можете создать неограниченное количество сущностей, используя данный способ. В качестве значений могут быть не только слова, но и целые предложения значительного объема.
    Подключение DTD для валидации XML-документов

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

    где вместо DOCUMENT указываем корневой элемент XML-документа.

    Для наглядности рассмотрим пример готового самодостаточного документа с декларативным способом включения DTD.

    Внешнее определение DTD — подключение DTD-документа

    Суть данного метода состоит в том, чтобы подключить к XML-документу файл DTD при помощи следующей конструкции.

    где DOCUMENT – указываем корневой элемент XML-документа.
    file.dtd – ссылка на файл DTD.

    Для наглядности рассмотрим следующий пример.

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

    На этом все. Удачи вам и успехов в изучении XML!

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

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

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

    Внутри же документа DTD- декларации включаются следующим образом:

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

    Определение элемента

    Элемент в DTD определяется с помощью дескриптора!ELEMENT , в котором указывается название элемента и структура его содержимого.

    Например, для элемента можно определить следующее правило:

    Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML. Внутри этой инструкции задается название элемента(flower) и тип его содержимого.

    В определении элемента мы указываем сначала название элемента(flower), а затем его модель содержимого — определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA(что означает parseable character data — любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY,ANY. Первая указывает на то, что элемент должен быть пустым(например, ), вторая — на то, что содержимое элемента специально не описывается.

    Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ? :

    В этом примере указывается, что внутри элемента должны быть определены элементы title, author и table-of-contents, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа «|» :

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

    Если в определении элемента указывается «смешанное» содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA, а затем разделенный символом «|» список элементов.

    Пример корректного XML- документа:

    Определение атрибутов

    Списки атрибутов элемента определяются с помощью ключевого слова!ATTLIST . Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента могут быть определены следующие атрибуты:

    В данном примере для элемента article определяются три атрибута: id, about и type , которые имеют типы ID(идентификатор), CDATA и список возможных значений соответственно. Всего существует шесть возможных типов значений атрибута:

    • CDATA — содержимым документа могут быть любые символьные данные
    • ID — определяет уникальный идентификатор элемента в документе
    • IDREF(IDREFS)- указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента
    • ENTITY(ENTITIES) — значение атрибута должно быть названием(или списком названий, если используется ENTITIES) компонента (макроопределения), определенного в документе
    • NMTOKEN (NMTOKENS) — содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA)
    • Список допустимых значений — определяется список значений, которые может иметь данный атрибут.

    Также в определении атрибута можно использовать следующие параметры:

    • #REQUIRED — определяет обязательный атрибут, который должен быть задан во всех элементах данного типа
    • #IMPLIED — атрибут не является обязательным
    • #FIXED «значение» — указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору
    • Значение — задает значение атрибута по умолчанию

    Определение компонентов(макроопределений)

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

    Программа-анализатор, просматривая в первую очередь содержимое области DTD- определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD- компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello; , которое будет заменено на строчку «Мы рады приветствовать Вас»

    В общем случае, внутри DTD можно задать три типа макроопределений:

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

    В XML существует пять предустановленных внутренних символьных констант:

    • — символ «>»
    • & — символ «&»
    • » — символ апострофа «»»
    • » — символ двойной кавычки «»»

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

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

    Например, для следующего фрагмента документа:

    можно использовать более короткую форму записи:

    Макроопределения часто используются для описания параметров в правилах атрибутов. В этом случае появляется возможность использовать одинаковые определения атрибутов для различных элементов:

    Типизация данных

    Довольно часто при создании XML- элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент 10.10.98 , то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL- запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL-запрос.

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

    Задав атрибуту значение по умолчанию LONG и определив его как FIXED, мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD- определении.

    Вот пример XML- документа, в котором определяются и используются несколько элементов с различными типами данных:

    . 5 2
    32.5 true 18346

    Как видно из примера, механизм создания элементов документа при этом нисколько не изменился. Все необходимая для проверки типов данных информация заложена в определения элементов внутри блока DTD.

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

    Язык XML — практическое введение

    . Documents Type Definitions (DTD)

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

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

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

    Внутри же документа DTD- декларации включаются следующим образом:

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

    Определение элемента

    Элемент в DTD определяется с помощью дескриптора ! ELEMENT , в котором указывается название элемента и структура его содержимого.

    Например, для элемента можно определить следующее правило:

    Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML. Внутри этой инструкции задается название элемента(flower) и тип его содержимого.

    В определении элемента мы указываем сначала название элемента(flower), а затем его модель содержимого — определяем, какие другие элементы или типы данных могут встречаться внутри него. В данном случае содержимое элемента flower будет определяться при помощи специального маркера PCDATA( что означает parseable character data — любая информация, с которой может работать программа-анализатор). Существует еще две инструкции, определяющие тип содержимого: EMPTY,ANY. Первая указывает на то, что элемент должен быть пустым(например, ), вторая — на то, что содержимое элемента специально не описывается.

    Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов могут использоваться символы +,*, ? :

    В этом примере указывается, что внутри элемента должны быть определены элементы title, author и table-of-contents, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents является опциональным, т.е. может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа «|» :

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

    Если в определении элемента указывается «смешанное» содержимое, т.е. текстовые данные или набор элементов, то необходимо сначала указать PCDATA, а затем разделенный символом «|» список элементов.

    Пример корректного XML- документа:

    Определение атрибутов

    Списки атрибутов элемента определяются с помощью ключевого слова ! ATTLIST . Внутри него задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента могут быть определены следующие атрибуты:

    В данном примере для элемента article определяются три атрибута: id, about и type , которые имеют типы ID(идентификатор), CDATA и список возможных значений соответственно. Всего существует шесть возможных типов значений атрибута:

    CDATA — содержимым документа могут быть любые символьные данные

    ID — определяет уникальный идентификатор элемента в документе

    IDREF( IDREFS )- указывает, что значением атрибута должно выступать название(или несколько таких названий, разделенных пробелами во втором случае) уникального идентификатора определенного в этом документе элемента

    ENTITY( ENTITIES) — значение атрибута должно быть названием(или списком названий, если используется ENTITIES) компонента (макроопределения), определенного в документе

    NMTOKEN (NMTOKENS) — содержимым элемента может быть только одно отдельное слово(т.е. этот параметр является ограниченным вариантом CDATA)

    Список допустимых значений — определяется список значений, которые может иметь данный атрибут.

    Также в определении атрибута можно использовать следующие параметры:

    #REQUIRED — определяет обязательный атрибут, который должен быть задан во всех элементах данного типа

    #IMPLIED — атрибут не является обязательным

    #FIXED «значение» — указывает, что атрибут должен иметь только указанное значение, однако само определение атрибута не является обязательным, но в процессе разбора его значение в любом случае будет передано программе-анализатору

    Значение — задает значение атрибута по умолчанию

    Определение компонентов(макроопределений)

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

    Программа-анализатор, просматривая в первую очередь содержимое области DTD- определений, обработает эту инструкцию и при дальнейшем разборе документа будет использовать содержимое DTD- компонента в том месте, где будет встречаться его название. Т.е. теперь в документе мы можем использовать выражение &hello; , которое будет заменено на строчку «Мы рады приветствовать Вас»

    В общем случае, внутри DTD можно задать три типа макроопределений:

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

    В XML существует пять предустановленных внутренних символьных констант:

    » — символ двойной кавычки «»»

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

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

    Например, для следующего фрагмента документа:

    можно использовать более короткую форму записи:

    Макроопределения часто используются для описания параметров в правилах атрибутов. В этом случае появляется возможность использовать одинаковые определения атрибутов для различных элементов:

    Типизация данных

    Довольно часто при создании XML- элемента разработчику требуется определить, данные какого типа могут использоваться в качестве его содержимого. Т.е. если мы определяем элемент 10.10.98 , то хотим быть уверенными, что в документе в этом месте будет находиться строка, представляющая собой дату, а не число или произвольную последовательность символов. Используя типизацию данных, можно создавать элементы, значения которых могут использоваться, например, в качестве параметров SQL- запросов. Программа клиент в этом случае должна знать, к какому типу данных относится текущее значение элемента и в случае соответствия формирует SQL-запрос.

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

    Задав атрибуту значение по умолчанию LONG и определив его как FIXED, мы позволили тем самым программе-клиенту получить необходимую информацию о типе содержимого данного элемента, и теперь она может самостоятельно определить соответствие типа этого содержимого указанному в DTD- определении .

    Вот пример XML- документа, в котором определяются и используются несколько элементов с различными типами данных:

    Как видно из примера, механизм создания элементов документа при этом нисколько не изменился. Все необходимая для проверки типов данных информация заложена в определения элементов внутри блока DTD.

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

    Назад | Содержание | Вперед

    5. Схемы данных

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

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

    В настоящее время в W3 консорциуме идет работа над первой спецификацией схем данных, рабочий ее вариант сейчас доступен на сервере [ 36 ]. В этом разделе мы рассмотрим основные возможности схем данных, попытаемся использовать их для проверки корректности ранее описываемых XML- документов.

    Как это выглядит

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

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

    , а некорректным этот:

    Все конструкции языка схем описываются правилами «XML DTD for XML-Data-Schema». Этот документ вы можете найти среди другой официальной документации, доступной на сервере W3 — консорциума. В этой статье мы коснемся лишь основных приемов для работы со схемами данных. Ссылки на более подробные источники приведены в конце.

    Область схемы данных

    Создавая схемы данных, мы определяем в документе специальный элемент, ;, внутри которого содержатся описания правил:

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

    Описание элементов

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

    Элемент содержит информацию об очередном выпуске журнала

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

    Как видно из примера, при определении класса элемента, можно также использовать комментарии к нему, которые заключаются в тэги descript>

    Атрибуты элемента

    Для того, чтобы в описании элемента определить его атрибуты и описать свойства этих атрибутов мы должны использовать элемент attribute :

    В данном примере элементу

    определяется атрибут src , значением которого может быть любая последовательность разрешенных символов:

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

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

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

    Для приведенных примеров корректным будет являться следующий фрагмент XML-документа:

    Модель содержимого элемента

    Под моделью содержимого в схеме данных понимают описание всех допустимых объектов XML- документа, использование которых внутри данного элемента является корректным. Модель содержимого определяется инструкциями, расположенными внутри блока .

    Для этого правила корректным будет являться следующий фрагмент документа:

    Психи и маньяки в Интернет

    Вложенные элементы описываются при помощи инструкции element , в которой параметром type указывается класс объекта — ссылка на его определение:

    Если требуется указать режим использования вложенного элемента, то надо определить параметр occurs :

    Возможные значения этого параметра таковы:

    REQUIRED — элемент должен быть обязательно определен

    OPTIONAL — использование элемента не является обязательным

    ZEROORMORE — вложенный элемент может встречаться несколько раз или ни разу

    ONEORMORE — элемент должен встречаться хотя бы один раз

    Примеры правильных XML-документа, использующих приведенную выше схему:

    Зачем он нужен, XML?

    нужен ли он нам

    Зачем он нужен, XML?

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

    — указывает на то, что содержимым элемента является только свободная текстовая информация(секция PCDATA) :

    Илон Маск рекомендует:  Что такое код swf_defineline
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL