Dtd определения для xml документа приложения 1


Содержание

Dtd определения для xml документа приложения 1

Определение типа документа (Document Type Definition, DTD) является тем фундаментом, на котором создаются XML-документы. Вы можете создать DTD или использовать заранее определенные DTD, которые специально созданы для применения в таких отраслях, как медицина и автомобильная промышленность, и которые описывают стандартизованные документы. Независимо от того, создаете ли вы собственное DTD, или же используете заранее определенное, вам необходимо знать, что такое DTD, как оно составляется и как работает.

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

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

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

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

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

Today's Memo Памятка на сегодня
August 1, 2000 1 августа 2000 г.
200 West 34th Suite 953, Anchorage. 200 West 34th Suite 953, Anchorage.
This memo is to alert you to the Это — извещение о том, что
new XML Black Book has now been издательство Coriolis, в серии
printed. Published by The Coriolis Black Book, выпустило новую книгу
Group, this book outlines пo XML, которая содержит все
everything you need to know необходимые сведения об этом языке
about XML. разметки.

Анализатор XML сверяет разметку документа по объявлениям различных элементов. Он также осуществляет замещение сущности, для которой в DTD было определено конкретное значение. В данном примере анализатор заменяет ссылку на сущность &PUBLISHER;- объявленным значением этой сущности, т. е. — The Coriolis Group. Таблица стилей, которая будет описана позднее в отдельном HTML-файле, управляет отображением данных.

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

  • &lt?XML version=»1.0″ encoding=»UTF-8″ standalone=»no»?&gt — это объявление указывает на то, что данный документ является XML-документом. Это первая строка инструкций, которая должна быть послана анализатору. Для получения более подробной информации об объявлении XML, обратитесь к разделу «Объявление XML», который приводится далее в этой главе.
  • &lt!DОСТУРЕ DOC [ — данное объявление указывает, где размещено DTD — в данном случае — в самом документе, но могло находиться и в другом месте, например &lt!DOCTYPE novel PUBLIC «-//Megginson//DTD Novel//EN» «novel. dtd&gt.
  • &lt!ELEMENT DOC (SUBJECT, DATE, ADDRESS, MEMO) &gt — Определяет список элементов для корневого элемента DOC. Это объявление элемента сообщает анализатору о том, что корневой элемент DOC содержит элементы-потомки SUBJECT, DATE, ADDRESS и MEMO и что эти элементы должны появляться в документе в этом же порядке. Если этот порядок будет нарушен, то анализатор выдаст сообщение об ошибке.
  • &lt!ELEMENT SUBJECT (# PCDATA) &gt —определяет элемент SUBJECT и указывает, что этот элемент будет содержать символьные данные, которые подлежат обработке анализатором.
  • &lt! ELEMENT DATE (#PCDATA)&gt— определяет элемент DATE и указывает, что этот элемент будет содержать символьные данные, которые подлежат обработке анализатором.
  • &lt! ELEMENT ADDRESS (#PCDATA)&gt — Определяет элемент ADDRESS и указывает, что этот элемент будет содержать символьные данные, которые подлежат обработке анализатором.
  • &lt! ELEMENT MEMO (#PCDATA)&gt— определяет элемент MEMO и указывает, что этот элемент будет содержать символьные данные, которые подлежат обработке анализатором.
  • &lt! ENTITY PUBLISHER «The Coriolis Group»&gt — определяет простую сущность PUBLISHER и указывает, что значением этой сущности является «The Coriolis Group».
  • ] &gt — указывает конец DTD.

Объявления

Объявлением называют разметку, которая служит для процессора XML специальной инструкцией, указывающей, как он должен обрабатывать данный документ. Существуют объявления элементов, атрибутов, сущностей, условных обозначений, объявление процессора и объявление типа документа. Рассмотрим два самых важных из них — объявление процессора и объявление типа документа. В отличие от остальных объявлений, объявление процессора и объявление типа документа не участвуют в конструировании самого документа. Они не поясняют структурную роль каждого отдельного элемента или атрибута. Наоборот, они указывают процессору, какой стандарт необходимо использовать, к какому типу относится обрабатываемый документ, а также где хранится DTD, в соответствии с которым сконструирован данный документ. Еще раз обратите внимание на две строки кода, которые определяют объявление процессора или так называемое объявление XML (XML declaration) и объявление типа документа:

<?XML version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE DOC [

Объявление XML

Первая строка в предыдущем примере называется объявлением XML. Это объявление указывает процессору, что для обработки XML-документа необходимо использовать спецификацию XML используемой версии (в настоящее время — версии 1.0. Вторая часть объявления XML указывает кодировку символов в данном документе. В этом примере применена 8-битная кодировка Unicode.

Заключительный фрагмент информации, который мы включаем в объявление XML, называется объявлением отдельного документа (standalone document declaration). Это объявление указывает, существуют ли внешние источники информации для данного документа. Так, значение «yes» говорит, что в данном документе не используется внешнее DTD или же какие-либо внешние параметрические сущности (external parameter entities). Другими словами, данный документ является самодостаточным и вся необходимая информация содержится в нем самом. Значение «yes» также указывает процессору, что в разметке необходимо игнорировать любые объявления внешних ссылок. Значение «nо» указывает процессору, что он может обрабатывать любые внешние объявления. Устанавливая для атрибута standalone значение «nо», вы сообщаете XML-процессорy, что данный документ может иметь ссылки на любые внешние объявления, например на любые внешние DTD. Это не означает, что вы должны включать внешние ссылки, а лишь то, что процессор должен принять и обработать любую внешнюю ссылку, если она указана в документе.

Когда устанавливать значение «yes», а когда «nо»? Если внешнее DTD содержит объявления атрибутов с любыми установками значений по умолчанию, и эти значения применяются по отношению к элементам, встречающимся в вашем документе, то следует установить значение «nо». Также необходимо установить значение «nо», если документ содержит какие-либо пустые участки, или в документе есть сущности, и ссылки на них встречаются в самом содержании документа. Значение «yes» можно установить, если в документе нет ссылок на внешние сущности, и если вы только используете общие сущности (general entities), являющиеся частью языка XML, например, амперсанд, символы «больше чем», «меньше чем», апостроф или же кавычки.

Объявление типа документа

Строка кода &lt! DOCTYPE DOC [ называется объявлением типа документа, и она служит для связи XML-документа с соответствующим DTD. Выражение, следующее за &lt! DOCTYPE, является именем используемого DTD. В том случае если DTD является внутренним, то за объявлением &lt! DOCTYPE следует список элементов и атрибутов, определенных для внутреннего DTD. Именно в объявлении типа документа автор XML-документа указывает, является ли данное DTD общим (public), или же частным (private). Далее, после закрывающей скобки указывается либо само DTD, либо локатор ссылки (reference locator)-на его местоположение. Если вы не опишете DTD, то процессор не получит информацию, необходимую для конструирования документа.

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

Вот пример DTD, содержащегося в самом документе:

<!DOCTYPE DOC [
<!ELEMENT DOC (SUBJECT, DATE, ADDRESS, MEMO) >
<ELEMENT SUBJECT (#PCDATA)>
<!ELEMENT DATE (#PCDATA)>
<!ELEMENT ADDRESS (#PCDATA)>
<!ELEMENT MEMO (# PCDATA) >
<!ENTITY PUBLISHER "The Corioiis Group">
]>

Вот пример того, как DTD хранится вне документа:

<! DOCTYPE book PUBLIC "-//CompanyXYZ//DTD book//EN"
"http : / /www . s ite . com/dtds /book . dtd">

Где могут храниться DTD

DTD могут храниться как внутри самого документа, так и вне его. В данном примере мы храним DTD внутри документа:

<?XML version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE DOC [

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

<!DOCTYPE [ Начало DTD . ]>

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

Общие и системные DTD

У вас есть возможность использовать как общедоступные (publicy available) DTD, которые разработаны для определенных целей, либо создать собственные DTD. Работая с общедоступными DTD, необходимо в объявлении типа документа указать ключевое имя PUBLIC. А если вы собираетесь использовать собственное DTD, то укажите ключевое слово SYSTEM. Вот пример кода для объявления общедоступного DTD:

<! DOCTYPE book PUBLIC "-//CompanyXYZ//DTD book//EN"
”http://www.site.com/dtds/book.dtd">

В XML для указания общедоступных DTD применяется точно такая же структура, как и в SGML. Если указанная сущность или DTD является стандартом ISO, то DTD начинается словом ISO. Если же указанная сущность или DTD не является стандартом ISO, однако используемый стандарт официально принят группой стандартизации, то объявление следует начинать со знака плюс (+). Если же он не принят официально группой стандартизации, то объявление следует начинать со знака минус (-). Далее следуют две наклонных черты (//), а затем владелец данного DTD. Если мы проанализируем DTD из предыдущего примера, то обнаружим, что указанное DTD не является стандартным, и что владельцем данного DTD является компания CompanyXYZ. Мы также увидим, что имя данного DTD — book, и что DTD расположено по адресу http://www.site.com/ в каталоге dtds.

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

<! DOCTYPE book SYSTEM "http://www.site.com/dtds/book.dtd">

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

Примечание
Можно встраивать одно DTD в другое, тогда встроенное DTD вызывается внешним DTD.

Быть или не быть DTD

Как вы уже знаете, в XML применение DTD не обязательно (в отличие от SGML). Поскольку XML был изначально приспособлен для работы в World W > Как же узнать, когда нужно использовать DTD, а когда нет? И как узнать каким DTD должно быть — внутренним или внешним?

Существуют некоторые факторы, которые помогут вам принять решение:

  • Большие документы требуют применения внешних DTD. DTD необходимы для документов большого объема. При помощи внешнего DTD вы сможете создать некоторое приближение к стандартизации, что сделает этот документ логически более последовательным, поскольку применение DTD предполагает обязательное следование определенным правилам.
  • Малые документы не требуют использования внешних DTD. Не следует создавать DTD для простой корреспонденции, например, для служебных записок и факсов размером в одну страницу.
  • В некоторых документах, предназначенных для Internet, применения внешних DTD нецелесообразно, т. к. может вызвать большую загрузку канала передачи данных.
  • XML-процессоры, не проверяющие действительность (val > Итак, мы показали, в каких случаях следует использовать DTD, а в каких — нет, но фактически следует рассматривать вариант создания DTD для каждого документа и хранить это DTD отдельно от документов, для работы с которыми это DTD предназначено. Хранение DTD в отдельных файлах не только обеспечит возможность их многократного использования, но и упростит их обновление и изменение. Это также будет препятствовать случайному вмешательству в DTD.

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

Приняв решение о создании DTD, следует определить способ его хранения. Размер документа — лишь один из факторов, которые следует учитывать Необходимо также тщательно рассмотреть, нужна ли проверка действительности (val >

Внутренние DTD

Первый вопрос, на который следует ответить при создании документа, можно сформулировать так: нужно ли, чтобы документ был самодостаточным (self-contained). Самодостаточный документ можно перемещать из системы в систему, без потери компонентов. С таким документом можно работать в локальной системе, без выхода в Internet, а можно поместить его сменный носитель и иметь его при себе. И любой процессор XML сможет его обработать.


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

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

Внешние DTD

Несмотря на то что внешние DTD увеличивают время обработки и загрузку сети, все же их применение предпочтительно. Почему? Этот подход дает массу преимуществ, особенно в области управления документами, их обновления и редактирования. Приведем лишь несколько доводов в пользу применения внешних DTD:

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

XML DTD

XML имеет правильный синтаксис называется «хорошей форме» в XML.

DTD проверка XML с помощью «легального» XML.

В виде хорошо сформированных документов XML

«Хорошо сформировавшиеся» XML-документ имеет правильный синтаксис.

Правила синтаксиса, описанные в предыдущем разделе:

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

Понимание XML

Узнайте, как Расширяемый язык разметки (Extensible Markup Language — XML) облегчает универсальный доступ к данным. XML — основанный на Unicode метаязык: язык для описания языков разметки. Он не привязан ни к одному языку программирования, операционной системе или поставщику программного обеспечения. XML обеспечивает доступ к огромному количеству технологий по манипулированию, структурированию, трансформированию и запрашиванию данных.

Введение

Расширяемый язык разметки (XML) изначально был задуман как язык для описания новых форматов документов World W >‘ ’ ). Web-разработчики могут заметить некоторую схожесть между HTML и XML, обусловленную тем фактом, что они оба происходят от SGML.

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

XML является предпочтительным для существовавших ранее форматов данных, потому что XML может запросто представить и табличные данные (такие как реляционные данные из базы данных или больших таблиц), и псевдоструктурированные данные (такие как Web-страницы или деловые документы). Популярные ранние форматы, такие как файлы с разделяемыми запятой значениями (CSV), или подходят для табличных данных и плохо описывают псевдоструктурированные данные, или, как RTF, слишком специализированы для псевдоструктурированных текстовых документов. Это привело к широкому распространению XML как языка для обмена информацией.

XML везде

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

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

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

Преимущества представления данных в виде XML были признаны многими и привели к распространению XML-источников данных. Деловые документы, базы данных и межделовое общение — все это примеры информационных источников, которые переходят или перешли к использованию XML как формата представления. Такие продукты Microsoft как Microsoft Office®, Microsoft SQL Server™ и Microsoft .NET Framework дают возможность конечным пользователям и разработчикам создавать и использовать документы, сетевые сообщения и другие данные в виде XML.

Синтаксис XML 1.0

Как было упомянуто ранее, рекомендация W3C XML 1.0 описывает текстовый формат для описания структурированных и псевдоструктурированных данных, используя синтаксис, подобный HTML.

Сравнение XML и HTML

И HTML, и XML документы состоят из элементов, каждый из которых включает «начальный тэг» ( ), «конечный тэг» ( ) и информацию, заключенную между этими двумя тэгами (которая называется содержимым элемента). Элементы могут быть аннотированы атрибутами, содержащими метаданные об элементе и его содержимом.

Однако между HTML и XML есть существенные отличия. XML чувствителен к регистру, в то время как HTML — нет. Это значит, что в XML начальные тэги

и

различны, тогда как в HTML — это одно и то же. Другое различие между HTML и XML в том, что XML представляет концепцию правильного построения. Правила построения XML устраняют некоторую неопределенность, присущую обработке таких языков разметки как HTML, вводя такие постулаты, как то, что все значения атрибутов должны быть заключены в кавычки, и что у всех элементов должны быть или начальный и конечный тэги, или явное указание того, что это пустые элементы. Краткое описание правил построения дается в XML FAQ в разделе D.2.

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

Анатомия XML-документа

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

Документ начинается с необязательного описания XML, в котором указывается, какая версия XML и кодирование символом используются. Далее следует инструкция обработки xml-stylesheet, которая используется для связывания таблицы стилей, содержащей инструкции по форматированию, с XML-документом. Таблица стилей используется для формирования привлекательного внешнего вида документа в пользовательских приложениях, таких как Web-браузеры. Инструкции обработки обычно используются для введения информации о приложении в XML-документ. Например, большинство приложений, обрабатывающих содержимое приведенного выше документа, вероятно, проигнорируют инструкцию обработки xml-stylesheet. С другой стороны, приложения, используемые для отображения XML-документа, такие как Web-браузер, могли бы использовать информацию инструкции обработки для того, чтобы определить, где располагается таблица стилей, содержащая специальные инструкции для отображения документа.

Unicode + угловые скобки = возможность взаимодействовать

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

То, что XML основан на Unicode, делает его подходящим для совместного использования информации через глобальные сети, такие как World Wide Web.

Infoset и семейство XML-технологий

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

Информационное множество (Infoset) XML

Рекомендация информационного множества W3C XML (W3C XML Information Set recommendation) описывает абстрактное представление XML-документа. XML Infoset, главным образом, изначально выступает в роли набора определений, используемых XML-технологиями для формального описания того, с какими частями XML-документа они работают. В терминах XML Infoset описаны несколько W3C XML-технологий, включая SOAP 1.2, XML Schema и XQuery.

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

согласно XML Infoset, считается эквивалентным. Аналогично, не имеет значения и тип кавычек, используемых для атрибутов; таким образом, элементы

согласно XML Infoset, эквивалентны. Список аспектов синтаксиса XML 1.0, которые не рассматриваются XML Infoset, приведен в Приложении D рекомендации Информационного множества W3C XML.

Рекомендация Информационного множества W3C XML описывает концепцию синтетических информационных множеств, которые создаются средствами, отличными от синтаксического разбора текстового XML-документа. Синтетические информационные множества подготавливают почву для обработки с помощью XML-технологий не-XML-данных, которые могут быть преобразованы в XML Infoset. Примером обработки синтетического информационного множества является ObjectXPathNavigator (http://msdn.microsoft.com/library/en-us/dnexxml/html/xml03172003.asp), который обеспечивает возможность запрашивать объекты в .NET Framework, используя XPath, или преобразовывать их, используя XSLT.

Языки Схемы

Язык XML-схемы используется для описания структуры и содержимого XML-документа. Например, схема может использоваться для определения документа, состоящего из одного или более элементов compact-disc, каждый из которых включает в качестве дочерних элементы price, title и artist. Во время обмена документами XML-схема описывает контракт между производителем и потребителем XML, поскольку она описывает то, что составляет действительное XML-сообщение передаваемое между двумя сторонами. Хотя для XML существует несколько языков схемы, от DTD до XDR, ведущим является Язык описания XML-схемы W3C (W3C XML Schema Definition Language), сокращенно XSD.

XSD уникален среди языков XML-схемы, потому что он первым пытается вывести роль XML-схемы за рамки традиционного ее применения для описания контракта между двумя сущностями, обменивающимися документами. XSD представляет концепцию Post Schema Validation Infoset (PSVI). Совместимый XSD-обработчик принимает XML Infoset как входные данные и после проверки преобразовывает его в Информационное множества после проверки схемы (PSVI). PSVI — это исходные входные данные XML Infoset с добавленными к существующим новыми единицами информации и новыми свойствами. В Рекомендации XML-схема W3C приведен список дополнений в Информационное множества после проверки схемы (PSVI).


Одним важным классом дополнений PSVI является аннотации типов. Элементы и атрибуты получают строгий контроль типов и имеют ассоциированную информацию о типе данных. Такие XML со строгим контролем типов весьма универсальны, потому что теперь они с помощью таких технологий как XmlSerializer (http://msdn.microsoft.com/library/en-us/dnexxml/html/xml01202003.asp) из .NET Framework могут быть преобразованы в объекты, с помощью технологий SQLXML (http://msdn.microsoft.com/sqlxml) и DataSet (http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemDataDataSetClassTopic.asp) из .NET Framework они могут быть преобразованы в реляционные таблицы или их можно обработать с помощью языков запросов XML, таких как XPath 2.0 и XQuery, которые используют преимущество строгого контроля типов.

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

API, использующие модель дерева
Древовидная модель API представляет XML-документ как дерево узлов, которые обычно загружаются в память все сразу. Самая популярная древовидная модель API для XML — Объектная модель документа W3C (W3C Document Object Model — DOM). DOM обеспечивает возможность программно читать, манипулировать и изменять XML-документ.

Ниже приведен пример использования класса XmlDocument (http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemXmlXmlDocumentClassTopic.asp) в .NET Framework для получения имени исполнителя и названия первого compact-disc в элементе items.

Курсорные APIs

Курсорные API в XML можно представить как лупу, которая проходит по XML-документу, согласно указаниям фокусируясь на отдельных аспектах документа. Класс XPathNavigator в .NET Framework — это пример курсорного API в XML. Преимущество курсорных API над древовидной моделью API в том, что для них не требуется, чтобы весь XML-документ был загружен в память, что открывает двери оптимизациям со стороны создателя XML, в которых документ загружается «по мере надобности».

Вот пример использования класса XPathNavigator (http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemXmlXPathXPathNavigatorClassTopic.asp) в .NET Framework для получения имени исполнителя и названия первого compact-disc в элементе items.

Потоковые API

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

Передающие синтаксические анализаторы, такие как SAX, проходят по XML-потоку, а затем при встрече с XML-узлами «выталкивают» события в зарегистрированные обработчики событий (методы обратного вызова). Принимающие анализаторы, такие как класс XmlReader (http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemXmlXmlReaderClassTopic.asp) в .NET Framework, работают в XML-потоке как однонаправленные курсоры.

Ниже представлен пример использования класса XmlReader в .NET Framework для получения имени исполнителя и названия первого compact-disc в элементе items.

XML-запрос

XML-преобразование

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

XSLT (http://www.w3.org/TR/xslt) — первый язык XML-преобразования. Преобразование, выраженное в XSLT, описывает правила преобразования исходного дерева в результирующее дерево. Преобразование достигается путем ассоциирования шаблонов. Шаблон — это выражение XPath, может рассматриваться как регулярное выражение, ставящее части исходного дерева XML в соответствие частям строки. Шаблон ставится в соответствие элементам исходного дерева. В случаях совпадения создается экземпляр шаблона для создания части результирующего дерева. При создании результирующего дерева элементы исходного дерева могут быть отфильтрованы и реорганизованы, а произвольная структура может быть добавлена.

Следующая таблица стилей XSLT преобразовывает элемент items в Web-страницу XHTML, содержащую таблицу с информацией о компакт дисках.

XHTML-документ, созданный с использованием этой таблицы стилей, показан ниже:

Заключение

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

Dtd определения для xml документа приложения 1

В спецификация 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 определения для xml документа приложения 1

5. Лекция: Создание валидных XML-документов

Основной критерий для валидного документа

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

Корректно сформированный XML-документ также может быть валидным. Валидным (valid) называется корректно сформированный (well-formed) документ, отвечающий двум дополнительным требованиям:

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

остальной документ должен отвечать структуре, заданной в DTD.

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

Требования корректности формирования и валидности

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

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

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

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

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

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

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

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

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

Совет . Если вы открываете XML-документ (самостоятельный или с присоединенной таблицей стилей) непосредственно в Internet Explorer, процессор Internet Explorer проверяет весь документ (в том числе объявление типа документа, если оно присутствует) на корректность формы составления, и выводит сообщение о фатальной ошибке при любом обнаруженном несоответствии. Однако процессор Internet Explorer не проверяет документ на валидность.

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

Добавление DTD

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

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

Примечание. Процессор Internet Explorer проверяет документ на валидность только в том случае, если вы открываете документ через HTML Web-страницу (с использованием техники, с которой вы познакомитесь в лекциях 8 и 9). Если вы открываете XML-документ непосредственно в Internet Explorer 5, процессор будет проверять документ (включая любое объявление типа документа, которое он содержит) на корректность формы составления, но не будет проверять документ на валидность, даже если он содержит объявление типа документа.

Форма записи DTD

Объявление типа документа имеет следующую обобщенную форму записи:

Здесь Имя указывает на имя элемента Документ. Имя действительного элемента Документ должно в точности соответствовать имени, записанному в объявлении. (Правила, в соответствии с которыми следует выбирать имена элементов, приведены в разделе «Анатомия элемента» в лекции 3.) Например, если вы создаете объявление типа документа для документа, рассмотренного в предыдущем разделе, вам следует использовать имя INVENTORY:

(Это еще не законченное объявление типа документа. DTD следует заменить реальным содержимым.)

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

Примечание. Подобно всем ключевым словам XML, DOCTYPE должно быть набрано прописными буквами.

Создание DTD

DTD состоит из символа левой квадратной скобки ([), после которой следует ряд объявлений разметки, заканчивающихся правой квадратной скобкой (]). Объявления разметки описывают логическую структуру документа; т.е. задают элементы документа, атрибуты и другие компоненты. На рисунке 5.2 приведен законченный валидный XML-документ, содержащий DTD с единственным объявлением разметки, которое определяет один тип элемента в документе, SIMPLE.

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


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

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

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

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

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

Инструкции по обработке. Эта тема затрагивалась в разделе «Использование инструкций по обработке» в лекции 4.

Комментарии. О них говорилось в разделе «Добавление комментариев» в лекции 4.

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

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

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

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

Форма записи объявления типа элемента

Объявление типа элемента имеет следующую обобщенную форму:

Здесь Имя есть имя объявляемого типа элемента. (Свод правил по правильному заданию имен элементов приведен в разделе «Анатомия элемента» в лекции 3.) Опись_содержимого – это описание содержимого, которое определяет, что может содержать элемент. В следующем разделе приведены различные типы описаний содержимого, которые вы можете использовать.

Ниже приведено объявление типа элемента с именем TITLE, для содержимого которого могут использоваться только символьные данные (дочерние элементы не допускаются):

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

В качестве последнего примера рассмотрим законченный XML-документ с двумя типами элементов. Объявление типа элемента COLLECTION указывает, что он может содержать один или несколько элементов CD, а объявление типа элемента CD указывает, что он может содержать только символьные данные. Заметим, что документ соответствует этим объявлениям, и, следовательно, является валидным:

Примечание. Вы можете объявить определенный тип элемента в данном документе только один раз.

Описание содержимого элемента

Вы можете описать содержимое элемента – т.е. заполнить часть опись_содержимого в объявлении типа элемента – четырьмя различными способами.

Пустое содержимое (EMPTY). Ключевое слово EMPTY указывает, что элемент должен быть пустым – т.е. не может иметь содержимого. Например:

Ниже приведены валидные элементы IMAGE, которые вы можете поместить в документ:

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

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

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

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

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

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

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

Модель содержимого может иметь одну из следующих основных форм.

Последовательная. Последовательная форма модели содержимого указывает, что элемент должен иметь заданную последовательность дочерних элементов. Вы отделяете имена типов дочерних элементов запятыми. Например, следующее DTD указывает, что элемент MOUNTAIN должен иметь один дочерний элемент NAME, после которого идет один дочерний элемент HEIGHT, за которым следует один дочерний элемент STATE:

Следовательно, следующий элемент Документ будет валидным:

Следующий элемент Документ, однако, не будет валидным, поскольку порядок дочерних элементов не соответствует объявленному:

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

Выборочная. Выборочная форма модели содержимого указывает, что элемент может иметь любой из серии допустимых дочерних элементов, разделяемых символом |. Например, следующее DTD указывает, что элемент FILM может состоять из одного дочернего элемента STAR, или одного дочернего элемента NARRATOR, или одного дочернего элемента INSTRUCTOR:

Следовательно, следующий элемент Документ будет валидным:

а также элемент:

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

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

Ни одного или один из предшествующих элементов

Основы XML для начинающих пользователей

Введение в правильную разметку

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

Языки разметки прошли путь от первых форм, создаваашихся компаниями и госучреждениями, до Стандартного языка обобщенной разметки (Standard Generalized Markup Language — SGML), Гипертекстового языка разметки (Hypertext Markup Language — HTML) и в конечном итоге до XML. SGML может показаться сложным, а HTML (который, по сути, сначала был просто набором элементов) оказался недостаточно мощным для идентификации информации. XML разрабатывался как простой в применении и удобный для расширения язык разметки.

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

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

Как уже упоминалось, файлы XML состоят из текста и разметки. Большая часть текста помещается в элементы, в которых текст окружен тегами. Например, допустим, нужно создать поваренную книгу в формате XML. У нас есть рецепт под названием Ice Cream Sundae, который нужно преобразовать в XML. Чтобы разметить название рецепта, заключим его текст в элемент, который начинается и заканчивается тегами. Этот элемент можно назвать recipename . Чтобы отметить начальный тег элемента, поместим его имя в угловые скобки <> ), вот так: . Затем введем текст Ice Cream Sundae . После текста поставим замыкающий тег, который представляет собой имя элемента в угловых скобках, плюс косая черта завершения элемента ( / ) перед именем элемента, вот так: . Эти теги образуют элемент, в который можно вводить текст и даже другие элементы.


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

Начало создания файла XML

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

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

Создание корневого элемента

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

Листинг 1. Корневой элемент

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

Наименования элементов

Соблюдение регистра в тегах

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

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

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

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

Листинг 2. Другие элементы

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

Вложение элементов

Вложение— это размещение элементов внутри других элементов. Эти новые элементы называются дочерними элементами, а элементы, которые их окружают, — их родительскими элементами. В листинге 3 в корневой элемент вложено несколько элементов. Это вложенные дочерние элементы , и

Добавление атрибутов

К элементам иногда добавляются Атрибуты. Атрибуты состоят из пары имя-значение, где значение берется в двойные кавычки ( » ), вот так: type=»dessert» . Атрибуты позволяют сохранять вместе с элементом дополнительные параметры, меняя значения этих параметров от элемента к элементу в одном и том же документе.

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

Листинг 4. Наш файл XML с элементами и атрибутами

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

Правильно и неправильно построенный XML

Если вы следуете правилам, определенным в вашей структуре, вы сможете легко создавать правильно построенный код XML. Правильный XML— это код XML, составленный с соблюдением всех правил XML: правильное именование элементов, вложение, именование атрибутов и т.п.

В зависимости от того, что именно вы делаете с XML, вам может понадобиться работа с правильно построенным XML. Рассмотрим приведенный выше пример сортировки по типу рецептов. Нужно, чтобы элементы содержали атрибут type . Очень важно иметь возможность успешно проверить код и гарантировать постоянное присутствие значения этого атрибута.

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

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

Листинг 5. DOCTYPE

Этот пример означает, что ваш файл списка элементов с именем filename.dtd находится в вашем компьютере (то есть в каталоге SYSTEM , а не в общем каталоге PUBLIC ).

Использование сущностей

Сущности (entity)могут представлять собой фрагменты текста или специальные символы. Они могут указываться внутри документа или вне его. Во избежание ошибок и для правильности отображения сущности должны быть надлежащим образом объявлены и выражены.

Нельзя вводить специальные символы прямо в текст. Для использования в тексте специальных символов их нужно сделать сущностями и использовать коды этих символов. В качестве сущностей можно определить фразы, такие как название компании, а затем использовать их по всему тексту. Чтобы создать сущность, назначьте ей имя и вставляйте это имя и вставляйте это имя в текст после знака амперсанда ( & ) и заканчивая точкой с запятой — например, &coname; (или другое имя). Затем укажите этот код в своей строке DOCTYPE в квадратных скобках( [] ), как в листинге 6. Этот код определяет текст, который подставляется вместо сущности.

Листинг 6. Сущность

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

Как избежать ошибок

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

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

Листинг 7. Правильно построенный документ XML

Примечание: Разрывы строк облегчают чтение кода, не влияют на сам XML.

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

Проверка XML

На рисунке 1 показан XML-документ, элементы которого отображаются без сбоев в Internet Explorer. Текст обрамляют открывающий и замыкающий теги. Рядом с родительскими элементами расположены значки плюс ( + ) и минус( — ), которые позволяют убрать внутрь элементов все вложенные в них элементы (их потомков).

Рисунок 1. Пример файла XML со свернутыми потомками

Заключение


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

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

Ресурсы для скачивания

  • этот контент в PDF
  • Пример исходного кода (example.zip | 2KБ)

Похожие темы

  • Оригинал статьи (EN).
  • Статьи на тему XML в Wikipedia: подробнее об XML.
  • Руководства по XML на сайте W3 Schools: от основ XML — к JavaScript и другим, более сложным предметам.
  • Спецификация XML от World W >

Комментарии

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

Новые книги

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

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

Язык XML. DTD-определения для XML-документа

В чем разница между XML-схемой и DTD?

У меня есть этот вопрос, но я не понимаю, что такое XML-схема и DTD (определение типа документа), и почему схема XML более эффективна по сравнению с DTD.

Любое руководство будет высоко оценено.

Критическое различие между DTD и XML-схема — это XML-схема используйте синтаксис на основе XML, тогда как DTD имеют уникальный синтаксис из DTD SGML. Хотя DTD из-за этой необходимости часто критикуют для изучения нового синтаксиса, синтаксиса сама по себе довольно короткая. Противоположность true для XML-схемы, которые verbose, но также использовать теги и XML, чтобы авторы XML могли найти синтаксис XML Schema less пугающим.

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

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

Typing

Наиболее значительным различием между DTD и XML Schema является возможность создавать и использовать типы данных в Схеме в сочетании с объявлениями элементов и атрибутов. На самом деле, такая важная разница в том, что одна половина Рекомендации XML Schema посвящена datatyping и XML Schema. Мы подробно рассмотрим типы данных в части III этой книги» Типы данных XML-схемы «.

Постоянные ограничения

Другая область, где DTD и схема значительно различаются, связаны с ограничениями на появление. Если вы вспомните наши предыдущие примеры в главе 2″ Структура схемы» (или ваша собственная работа с DTD), есть три символа, которые можно использовать для ограничения количества вхождений элемента: *, + и?.

Перечисления

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

Но что, если мы хотим, чтобы size был элементом? Мы не сможем сделать это с помощью DTD. DTD не предоставляют перечисления в текстовом элементе элемента. Однако из-за типов данных с помощью схемы, когда мы объявили перечисление в предыдущем примере, мы фактически создали simpleType , называемый size_values , который мы теперь можем использовать с элементом:

Различия между определением схемы XML (XSD) и определением типа документа (DTD) включают в себя:

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

ОБНОВЛЕНИЕ: 2015.08.26

Не все эти пулевые точки на 100% точны, но вы получаете суть.

С другой стороны:

  • DTD позволяет вам определять новые значения ENTITY для использования в вашем XML файле.
  • DTD позволяет вам распространять его локально в отдельный файл XML.

DTD предшествует XML и, следовательно, недействителен сам XML. Вероятно, это самая большая причина для изобретения XSD.

Одно из отличий заключается также в том, что в DTD модель контента элемента полностью определяется его именем независимо от того, где оно появляется в документе. Итак, скажите, что вы хотите иметь дочерний элемент name вашего элемента person , который сам имеет дочерние элементы first и last . Затем, если вы хотите иметь дочерний элемент name для элемента city в том же документе, для этого также должны быть дочерние элементы first и last . Напротив, XML Schema позволяет объявлять типы дочерних элементов локально, поэтому в этом случае вы можете объявлять дочерние элементы name для person и city отдельно, предоставляя им соответствующие модели контента в этих контекстах.

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

Для меня другие различия в основном поверхностны. Поддержка Datatype может быть легко добавлена ​​в DTD, а синтаксис — просто синтаксис. (Я, например, считаю синтаксис XML Schema ужасным и никогда не захочет вручную поддерживать XML-схему, о которой я бы не сказал о DTD или схемах RELAX NG, если мне по какой-то причине нужна XML-схема, я обычно пишу RELAX NG и преобразовать его с помощью trang .)

Синтаксис и основные понятия языка XML, создание валидных документов

Понятие о языке XML


XML — это расширяемый язык разметки (Extensible Markup Language), разработанный специально для размещения информации в World Wide Web, наряду с HTML, который давно стал стандартным языком создания Web-страниц. В отличие от HTML, вместо использования ограниченного набора определённых элементов вы имеете возможность создавать ваши собственные элементы и присваивать им любые имена по вашему выбору. Примечание: подразумевается, что читатель данной статьи хотя бы очень поверхностно знаком с языком HTML.

XML решает ряд проблем, которые не решает HTML, например:

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

В зависимости от уровня соответствия стандартам документ может быть «верно сформированным» («well-formed»), либо «валидным» («valid»). Вот несколько основных правил создания верно сформированного документа:

  • Каждый элемент XML должен содержать начальный и конечный тэг (либо пустой тэг типа , который может нести информацию посредством своих атрибутов).
  • Любой вложенный элемент должен быть полностью определён внутри элемента, в состав которого он входит.
  • Документ должен иметь только один элемент верхнего уровня.
  • Имена элементов чувствительны к регистру.

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

  • Каскадная таблица стилей (Cascading Style Sheet — CSS) или расширяемая таблица в формате языка стилевых таблиц (Extensible Stylesheet Language — XSL).
  • Связывание данных. Этот метод требует создания HTML-страницы, связывания с ней XML-документа и установления взаимодействий HTML-элементов с элементами XML. В дальнейшем HTML-элементы автоматически отображают информацию из связанных с ними XML-элементов.
  • Написание сценария. Этот метод требует создания HTML-страницы, связывания с ней XML-документа и получение доступа к XML-элементам с помощью кода сценария JavaScript или VBScript.

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

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

Простейший XML-документ

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

  • Объявление типа документа.
  • Одну или несколько инструкций по обработке.

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

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

Dtd определения для xml документа приложения 1

В спецификация 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)
Илон Маск рекомендует:  Что такое код asp cpuenablepagefaults
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL