1 Введение в XML
В этом разделе рассмотрены основы XML. Наша цель - предоставить информацию для начала работы с XML, дать вам понять, что же такое XML. (Вы изучите XML в следующих разделах руководства.) Далее мы отметим основные особенности, которые делают XML идеальным средством для хранения и обмена информацией, и рассмотрим главные принципы использования XML.
1.1 Что такое XML?
XML - это текстовый язык разметки, который быстро становится стандартом для обмена данными в Web. Как и в HTML для определения данных используются теги (идентификаторы, заключенные в угловые скобки - <...>). Совокупность тегов называется разметкой.
Но, в отличие от HTML, XML-теги идентифицируют данные, а не способ их отображения. Если HTML-тег указывает, например, "отобразить эти данные жирным шрифтом" (...), XML-тег действует как имя поля в вашей программе. Он ставит метку на часть данных, которые идентифицирует (например: ...).
Примечание: Поскольку идентификация данных происходит по их значению (как их интерпретировать и что необходимо с ними сделать), XML иногда описывается как механизм для определения семантики (значения) данных.
Так же как при определении имен полей структуры данных вы можете использовать любые XML-теги, имеющие значение для данного приложения. Естественно, для того чтобы несколько приложений использовали одни и те же XML-данные, они должны договориться об именах тегов.
Вот пример XML-данных, которые можно использовать в почтовом приложении:
<to>[email protected]</to>
<from>[email protected]</from>
<subject>XML Is Really Cool</subject>
<text>
How many ways is XML cool? Let me count the ways...
</text>
Примечание: В этом руководстве жирный шрифт используется для выделения текста, на который мы хотим обратить ваше внимание. XML не использует жирный шрифт!
Теги в этом примере идентифицируют сообщение в целом, адреса отправителя и получателя, тему и текст сообщения. Так же как и в HTML тег имеет соответствующий завершающий тег . Данные между тегом и соответствующим ему завершающим тегом определяют элемент XML-данных. Обратите внимание, что содержимое тега полностью содержится в области действия тега .... Именно способность одного тега содержать другие обеспечивает в XML способность представлять иерархические структуры данных.
И снова, так же как в HTML, пробелы не существенны, так что вы можете форматировать данные для удобства чтения и в то же время легко обрабатывать их в программе. В отличие от HTML, однако, в XML вы можете легко искать в наборе данных сообщения, содержащие в своей теме слово "cool", поскольку XML-теги идентифицируют содержимое данных, а не их представление.
1.1.1 Теги и атрибуты
Теги могут также содержать атрибуты - дополнительную информацию, включаемую как часть самого тега вовнутрь его угловых скобок. В следующем примере показана структура сообщения электронной почты, использующего атрибуты для полей "to", "from" и "subject":
to="[email protected]" from="[email protected]"
subject="XML Is Really Cool">
How many ways is XML cool? Let me count the ways...
Как и в HTML, после имени атрибута следуют знак равенства и значение атрибута, а несколько атрибутов разделяются пробелами. Однако, в отличие от HTML, запятые между атрибутами в XML не игнорируются; если они существуют, генерируется ошибка.
Поскольку вы можете создать такую структуру данных как , одинаково хорошо используя как атрибуты, так и теги, принятие решения, какой дизайн лучше подходит для конкретных целей, может потребовать значительных усилий. В разделе "Проектирование структуры XML-данных" приведены некоторые рекомендации, которые помогут вам решить, когда использовать атрибуты, а когда теги.
1.1.2 Пустые теги
Одним из действительно больших различий между HTML и XML является то, что XML-документ всегда обязан быть формально-правильным. Существует несколько правил, которые определяют корректность документа, но одним из самых важных является следующее правило - каждый тег должен иметь завершающий тег. То есть, в XML тег является обязательным. Элемент никогда не завершается каким-либо тегом, отличным от .
Примечание: Еще одним важным аспектом формально-правильного документа является полная вложенность всех тегов. То есть вы можете записать ......, но никогда не сможете ....... Полный список требований находится в XML Frequently Asked Questions (FAQ) на странице https://www.ucc.ie/xml/#FAQ-VALIDWF. (Этот FAQ находится в списке "Рекомендуется прочитать" организации W3C на htp://www.w3.org/XML/.)
Однако, иногда есть смысл использовать тег, стоящий особняком. Например, вы возможно захотите добавить тег "flag", который помечает важное сообщение. Такой тег не имеет никакого содержимого, и называется "пустым тегом". Вы можете создать пустой тег, закончив его знаками /> вместо >. Например, следующее сообщение содержит такой тег:
subject="XML Is Really Cool">
<flag/>
How many ways is XML cool? Let me count the ways...
Примечание: Пустой тег предохраняет вас от необходимости записи для сохранения корректности документа. Вы можете контролировать, какие теги могут быть пустыми, создав Document Type Definition, или DTD. Через некоторое время мы поговорим об этом. Если DTD не существует, документ может содержать любые типы тегов, какие вы захотите, пока документ остается формально-правильным.
1.1.3 Комментарии в XML-файлах
XML-комментарии выглядят также как и в HTML:
subject="XML Is Really Cool">
<!-Это комментарий -->
How many ways is XML cool? Let me count the ways...
1.1.4 Пролог XML
И, в завершение этого введения в XML, обратите внимание, что XML-файл всегда начинается с пролога. Минимальный пролог содержит объявление, идентифицирующее документ как XML-документ, например:
Объявление может также содержать дополнительную информацию, например:
XML-объявление по существу является таким же как и заголовок HTML, , за исключением того, что в нем используются и он может иметь следующие атрибуты:
version - Идентифицирует используемую версию языка разметки XML. Этот атрибут является обязательным.
encoding - Идентифицирует набор символов, используемый для кодирования данных. "ISO-8859-1" - это набор символов "Latin-1" для языков Западной Европы и Англии. (По умолчанию устанавливается сжатый Unicode: UTF-8.)
standalone - Указывает, ссылается или нет документ на внешнюю сущность или на внешнюю спецификацию типов данных (см. ниже). Если нет внешних ссылок, используется значение "yes".
Пролог может также содержать определения сущностей (элементов, вставляемых тогда, когда вы ссылаетесь на них в документе) и спецификаций, указывающих, какие теги являются разрешенными в документе. Сущности и спецификации объявляются в Document Type Definition (DTD), определяемом непосредственно в прологе, или через указатель на внешние файлы спецификаций. Но это - предмет для дальнейшего изучения в этом руководстве. Более подробная информация об этом и многих других аспектах XML находится в списке "Рекомендуется прочитать" организации htp://www.w3.org/XML/.
Примечание: На самом деле объявление не обязательно. Но включение его в любой создаваемый XML-файл является хорошей идеей. Объявление должно содержать номер версии и, по возможности, систему кодирования. Эта рекомендация упростит жизнь, если в будущем XML-стандарт расширится, или если когда-нибудь понадобится локализовать данные для других географических регионов.
Все, что следует за XML-прологом, составляет содержимое документа.
1.1.5 Директивы
XML-файл может также содержать директивы, которые передают команды или информацию приложению, обрабатывающему XML-данные. Директивы имеют следующий формат:
где target - имя приложения, которое, как ожидается, будет осуществлять обработку, а instructions - это строка символов, заключающая в себе информацию или команды для обработки приложением.
Поскольку директивы зависят от приложения, XML-файл может иметь несколько директив, указывающих различным приложениям выполнить похожие действия, хотя и разными способами. XML-файл для слайдшоу, например, может содержать директивы, позволяющие докладчику выбрать техническую версию презентации или версию для исполнительного звена. Если бы использовались несколько программ презентации, в программе, возможно, понадобилось бы наличие нескольких версий директив (хотя было бы лучше, если бы эти приложения распознавали стандартные директивы).
Примечание: Имя "XML" (в любой комбинации строчных или прописных букв) зарезервировано для XML-стандартов. В некотором смысле объявление является директивой, удовлетворяющей стандарту. (Однако, если вы позже будете работать с анализатором, вы увидите, что метод для обработки директив никогда не видит объявления.)
1.2 В чем важность XML?
Существует большое количество причин всеобщего признания XML. В этом разделе перечислены наиболее важные из них.
1.2.1 Обыкновенный текст
Поскольку XML не является двоичным форматом, вы можете создать и редактировать файлы при помощи любого средства, начиная от стандартного текстового редактора и заканчивая визуальной средой разработки. Это облегчает отладку ваших программ и приносит пользу при хранении небольшого количества данных. С другой стороны, внешний интерфейс XML к базе данных делает также возможным эффективное хранение большого количества XML-данных. То есть XML, обеспечивает полную масштабируемость, начиная от небольших конфигурационных файлов и заканчивая корпоративным хранилищем данных.
1.2.2 Идентификация данных
XML указывает типы данных, а не способ их отображения. Поскольку теги разметки идентифицируют информацию и разбивают данные на части, почтовая программа может обрабатывать их, программа поиска может искать сообщения, переданные определенному человеку, а адресная книга может извлекать адрес из оставшейся части сообщения. Короче говоря, поскольку идентифицируются различные части информации, они могут быть использованы различными способами различными приложениями.
1.2.3 Стиль отображения
Когда способ отображения является важным, стандарт таблицы стилей XSL позволяет вам указать, как отобразить данные. Например, таблица стилей для:
[email protected]
может сказать:
-
Начать новую строку.
-
Отобразить "To:" жирным шрифтом с последующим пробелом.
-
Отобразить данные получателя.
Вот что получится:
To: you@yourAddress
Конечно, вы можете сделать тоже самое и в HTML, но вы не сможете обработать данные программами поиска и программами, извлекающими адреса и т.д. Более важным является то, что, поскольку XML по своей сути не имеет стиля, вы можете использовать совершенно разные таблицы стилей для выполнения вывода в форматах postscript, TEX, PDF или каких-либо новых форматах, которые еще даже не разработаны. Такая гибкость означает то, что один автор описал как "будущая защита" вашей информации. XML-документы, созданные сегодня, могут использоваться в будущих, еще не известных системах доставки документов.
1.2.4 Встроенная возможность многократного использования
Одной из замечательных возможностей XML-документов является возможность их составления из отдельных модулей. Это возможно и в HTML, но только при помощи указания ссылок на другие документы. В отличие от HTML, XML-модули могут быть включены в документ "по месту". Подключенные модули выглядят как нормальные части документа - вы можете производить поиск по всему документу одновременно или загружать его одной частью. Это дает возможность разбивать документ на модули без помощи ссылок. Вы можете отделить модуль так, что редактирование в нем отражается везде, где он используется, а документ, составленный из таких модулей, выглядит для всех состоящим только из одной части.
1.2.5 Связываемость
Благодаря HTML, способность определять связи между документами рассматривается сегодня как необходимость. В следующем разделе этого руководства, "XML и связанные спецификации: освоение алфавитной путаницы", обсуждается программа создания спецификации по ссылкам. Эта программа позволяет вам определять двунаправленные ссылки, многоцелевые ссылки, "расширяющиеся" ссылки (в которых переход по ссылке вызывает появление запрошенной информации в текущем месте документа), и ссылки между двумя существующими документами, определенные в третьем.
1.2.6 Простота обработки
Как упоминалось ранее, регулярная и непротиворечивая нотация облегчает создание программ для обработки XML-данных. Например, в HTML тег - может быть ограничен тегами
, другим - ,
- или
. Это несколько затрудняет программирование. Но в XML тег В будущем XML станет потенциальным решением при обмене данными в транзакциях любого типа, как только обе стороны согласятся использовать одинаковую разметку. (Например, какие теги почтовая программа должна обрабатывать: и , или и ). Необходимость в общих стандартах в ближайшие годы приведет к разработке многих отраслевых стандартов. Между тем, будут важны механизмы, позволяющие "транслировать" теги в XML-документе. Такими механизмами являются, например, инициатива RDF, в которой определяются "базовые теги", и XSL-спецификация, определяющая трансляцию одних XML-тегов в другие.
Конечно, для таких компонентов имеет смысл использовать платформу Java. Для создания таких приложений можно использовать и JavaBeans™ для интерфейсов, и JavaBeans™ для бизнес-логики. И хотя ни одно из предпринятых усилий еще не доведено до коммерческого использования, очень много предварительной работы уже сделано.
Примечание: Язык программирования Java также отлично подходит для создания средств обработки XML, которые являются такими же переносимыми, как и XML. Для платформы Java были написаны несколько визуальных редакторов XML. Список редакторов, средств обработки и других XML-ресурсов находится в разделе "Software" SGML/XML Web-страницы, созданной Robin Cover, по адресу https://www.oasis-open.org/cover/.
должны соответствовать одному из распознаваемых форматов даты, один из аспектов критерия верификации данных уже определен - остается только написать код. Хотя спецификация DTD не может обеспечить такой же уровень детализации, DTD (как и схема) описывает грамматику, указывающую, какие структуры данных могут встретиться и в какой последовательности. В этой спецификации указывается, как написать высокоуровневый код, обрабатывающий элементы данных.
Но когда структура данных (и возможно схема) полностью определена, код, необходимый вам для обработки этих данных, может быть легко сгенерирован автоматически. Этот процесс известен под названием связывание - создание классов, распознающих и обрабатывающих различные элементы данных при обработке спецификации, которая определяет эти элементы. Со временем вы обнаружите, что используете спецификацию данных для генерирования значительной части кода, и сможете сконцентрироваться на программировании уникальных для вашего приложения задач.
1.3.4 Архивация
Чашей Святого Грааля в программировании является создание повторно используемых, модульных компонентов. В идеальном случае вы хотели бы взять их с полки, настроить и подключить их для создания приложения, с минимальным дополнительным кодированием и дополнительной компиляцией.
Основной механизм сохранения информации называется архивированием. Компонент архивируется путем записи его в выходной поток в форме, которую можно будет использовать в дальнейшем. Потом можно будет прочитать его и создать экземпляр, используя сохраненные параметры. (Например, если вы сохранили элемент таблицы, его параметрами могут быть количество строк и столбцов для отображения.) Архивированные компоненты можно перемещать по Web и использовать множеством способов.
Когда компоненты архивируются в бинарной форме, существуют некоторые ограничения в видах изменений, которые можно сделать в классах при желании сохранить совместимость с предыдущими версиями. Если бы вы могли модифицировать архивную версию так, чтобы изменения отразились в ней, это решило бы проблему. Но это очень тяжело сделать с двоичными объектами. Такие рассуждения вызвали большое количество исследований в использовании XML для архивирования. Но если состояние объекта было сархивировано в текстовой форме с использованием XML, тогда все в нем может быть изменено так же легко, как и сказать "найти и заменить".
Текстовый формат XML может также облегчить передачу объектов между приложениями, написанными на разных языках. По всем этим причинам основанное на XML архивирование возможно будет иметь большое распространение в не таком уж далеком будущем.
1.3.5 Итог
XML является довольно простым и очень гибким языком разметки. Он имеет много применений, которые еще должны быть открыты - мы только начинаем использовать его потенциал. Он является фундаментом для многих грядущих стандартов, обеспечивая общий язык, который могут использовать различные компьютерные системы для обмена данными друг с другом. Как только каждая отраслевая группа выйдет со своими стандартами, компьютеры начнут связываться друг с другом способами, которые раньше трудно было бы представить.
2 XML и связанные спецификации: освоение алфавитной путаницы
Теперь, когда вы понимаете основы XML, имеет смысл рассмотреть различные имеющие отношение к XML акронимы и их значение. Большой объем работы над XML продолжается, так что у нас есть что изучить.
Существующими в настоящее время API для обработки XML-документов в последовательном режиме или в режиме произвольного доступа являются соответственно SAX и DOM. Спецификациями для обеспечения корректности XML-документов являются DTD (оригинальный механизм, определенный как часть спецификации XML) и различные предложения стандартов схем (новые механизмы, использующие синтаксис XML для описания критериев верификации).
Среди других будущих стандартов, близких к завершению является стандарт XSL - механизм для настройки правил трансляции XML-документов (например, в HTML или другой XML) и для описания правил визуализации документа. Часть этого стандарта, предназначенная для преобразований, XSLT(+XPATH) завершена и описана в этом руководстве. Еще один стандарт, близкий к завершению - спецификация XML Link Language (XML Linking), разрешающая связи между XML-документами.
Это основные стандарты, с которыми вы должны быть хорошо знакомы. В этом разделе приведен также обзор нескольких других интересных предложений, включая HTML-подобный стандарт, XHTML, и мета-стандарт для описания информации, содержащейся в XML-документе, RDF. Продолжается работа также над стандартами, расширяющими возможности XML, например Xlink и Xpointer.
Наконец, существует несколько интересных стандартов и предложений стандартов, которые построены на XML, включая Synchronised Multimedia Integration Language (SMIL), Mathematical Markup Language (MathML), Scalable Vector Graphics (SVG) и DrawML, а также несколько стандартов eCommerce.
В остальной части этой главы приведено более детальное описание этих стандартов. Для ясности они разделены на:
-
Основные стандарты
-
Стандарты схем
-
Стандарты связи и представления
-
Стандарты знаний
-
Стандарты, построенные на XML
Бегло просмотрите термины один раз для ознакомления и храните копию этого документа под рукой, чтобы можно было обратиться к нему при встрече этих терминов где-нибудь еще. Очень скоро все они зафиксируются в вашей памяти, и вы станете "хорошо знакомы" с XML!
2.1 Основные стандарты
Существуют основные стандарты, с которыми вы должны быть хорошо знакомы. Они присутствуют практически в любом обсуждении XML.
2.1.1 SAX
Простой API для XML.
Этот API был фактически продуктом совместной работы участников списка рассылки XML-DEV, а не продуктом W3C. Он включен сюда потому, что имеет такие же "окончательные" характеристики, что и рекомендации W3C.
Вы можете рассматривать этот стандарт как протокол "последовательного доступа" к XML. Он является быстрым механизмом, который можно применить, например, для чтения или записи XML-данных на сервер. Его называют также протоколом, управляемым событиями, поскольку техника работы с ним следующая: регистрация вашего обработчика в SAX-анализаторе, после чего анализатор обращается к вашим методам обратного вызова при обнаружении нового XML-тега (либо встречает ошибку, либо хочет передать вам что-нибудь еще).
Более детальная информация по протоколу SAX находится в разделе "Простой API для XML".
2.1.2 DOM
Document Object Model (объектная модель документа).
Протокол Document Object Model преобразует XML-документ в набор объектов вашей программы. После этого вы можете манипулировать ими любым способом. Этот механизм известен также под названием - протокол "произвольного доступа", поскольку можно обратиться к любой части данных в любое время. Вы можете затем модифицировать данные, удалить их или вставить новые. Более подробная информация по спецификации DOM находится в разделе Document Object Model.
2.1.3 JDOM и dom4j
В то время как Document Object Model (DOM) обеспечивает большие возможности документо-ориентированной обработки, он не предоставляет чего-нибудь значительного в области объектно-ориентированного подхода. Java-разработчики, работающие со структурами, более ориентированными на данные, а не с книгами, статьями или другими полностью готовыми документами, часто находят, что объектно-ориентированные API, такие как JDOM и dom4j, легче в использовании и больше подходят под их требования.
Ниже приведены важные различия, которые нужно принимать во внимание при выборе одного из этих API:
-
JDOM немного более понятный, меньший по объему API. Когда важен "стиль кодирования", JDOM - это хороший выбор.
-
JDOM - это разработка Java Community Process (JCP). После завершения он станет рекомендованным стандартом.
-
dom4j - маленькая, быстрая реализация, находящая широкое применение в течение уже нескольких лет.
-
dom4j - является реализацией, основанной на генераторе. Это облегчает использование в сложных приложениях специального назначения. На момент написания руководства JDOM еще не использовал генератор для создания экземпляра анализатора (хотя стандарт, кажется, продвигается в этом направлении). То есть, в JDOM вы всегда получаете оригинальный анализатор. (Это хорошо для большинства приложений, но не подходит для приложений специального назначения.)
Более подробная информация по JDOM находится на странице https://www.jdom.org/.
Более подробная информация по dom4j находится на странице https://dom4j.org/.
2.1.4 DTD
Document Type Definition (определение типа документа).
Спецификация DTD является фактически частью спецификации XML, а не отдельной сущностью. С другой стороны, она не обязательна - вы можете написать XML-документ без нее. И существует несколько альтернативных стандартов схем, предлагающих более гибкие возможности. Поэтому DTD рассматривается здесь как отдельная спецификация.
DTD определяет типы тегов, которые можно использовать в XML-документе, и их правильное расположение. DTD можно использовать для гарантии корректности XML-структуры. Вы можете использовать ее также для проверки корректности XML-структуры, которую читаете (или которая передается по сети).
К сожалению, очень трудно сформировать DTD для сложного документа так, чтобы она предотвращала все неверные комбинации и разрешала все правильные. Создание DTD представляет собой в какой-то степени искусство. DTD может существовать в самом документе, как часть пролога. Она может существовать также в виде отдельной сущности, или может быть разделена между прологом документа и одной или несколькими дополнительными сущностями.
Однако, хотя механизм DTD был первым методом указания корректной структуры документа, он не был последним. Было разработано несколько новых спецификаций схем. Очень скоро вы узнаете про них.
Детальная информация приведена в разделе Создание Document Type Definition (DTD).
2.1.5 Пространство имен
Стандарт пространства имен позволяет вам написать XML-документ, использующий два и более набора XML-тегов модульным способом. Предположим, что вы создали основанный на XML список деталей, использующий XML-описания деталей, предлагаемых другими производителями (в режиме онлайн!). Элемент "price" для субкомпонентов может означать суммарную цену выбранных деталей, в то время как элемент "price" для структуры в целом может означать что-либо для отображения. Спецификация пространства имен определяет механизм уточнения имен для устранения двусмысленности. Она позволяет вам писать программы, использующие информацию из других источников и правильно работающие с ней.
Последняя информация по пространству имен находится на странице https://www.w3.org/TR/REC-xml-names.
2.1.6 XSL
Extensible Stylesheet Language (расширяемый язык таблиц стилей).
XML-стандарт определяет способ интерпретации данных, а не способ их отображения. HTML, с другой стороны, определяет, как данные должны быть отображены, без указания их значения. XSL-стандарт имеет две части, XSLT (стандарт преобразования, описываемый ниже) и XSL-FO (часть, описывающая объекты форматирования, известные, также, под названием поток объектов). XSL-FO дает возможность определить различные области на странице и затем связать их вместе. Когда текстовый поток направляется в такую коллекцию, текст заполняет полностью первую область, а затем "перетекает" во вторую область. Такие объекты используются в почтовых рассылках, каталогах и периодических изданиях.
Последние работы W3C по XSL находятся на странице https://www.w3.org/TR/WD-xsl.
2.1.7 XSLT (+XPATH)
Extensible Stylesheet Language for Transformations (расширяемый язык таблиц стилей для преобразований).
Стандарт преобразований XSLT является по существу механизмом преобразования, дающим возможность указать, как преобразовать XML-тег так, чтобы его можно было отобразить, например, в HTML. Различные XSL-форматы могут быть использованы для отображения тех же самых данных различными способами для различных пользователей. (Стандарт XPATH является механизмом адресации, используемым при создании инструкций преобразования для указания частей XML-структуры, которые необходимо преобразовать.)
Дополнительная информация находится в разделе XML Stylesheet Language for Transformations.
2.2 Стандарты схем
DTD дает возможность проверять структуру относительно простых XML-документов, но это все, на что он способен.
DTD не может ограничить содержимое элементов и не может определить сложные связи. Например, в DTD невозможно определить, что для должен иметь и и <author>, в то время как <heading> для <chapter> должен иметь только <title>. В DTD можно определить структуру элемента <heading> только один раз. В нем нет чувствительности к контексту.</p>
<p>Это происходит из-за того факта, что спецификация DTD не является иерархической. Например, для почтового адреса, содержащего несколько элементов PCDATA ("parsed character data"), DTD может выглядеть следующим образом:
<br/><span lang="en"><b>name</b>, address, zipcode)>
<br/>
<br/><span lang="en"><b>name</b> (#PCDATA)>
</p>
<p>Как вы можете заметить, спецификации являются линейными. Этот факт заставляет вас записывать новые имена похожих элементов в различных местах. Так что если вы захотите добавить еще один элемент "name" в DTD, содержащий <firstname>, <middleinitial> и <lastname> вы должны записать другой идентификатор. Вы не можете просто назвать его "name" без возникновения конфликта с элементом <name>, определенным в <mailaddress>.</p>
<p>Другой проблемой не иерархической природы спецификации DTD является неясность того, к чему относятся комментарии. Такой комментарий в начале как может относиться ко всем элементам, составляющим почтовый адрес. Но такой комментарий как может относиться только к элементу name. С другой стороны, такой комментарий как может относиться только к части #PCDATA элемента zipcode для описания правильного формата. Наконец, DTD не позволяет формально определять критерии верификации полей, такие как, например, ограничение в 5 цифр (или 5 и 4) в поле zipcode.
</p>
<p>И, наконец, DTD использует синтаксис, существенно отличающийся от XML, и поэтому не может обрабатываться стандартным XML-анализатором. Это означает, что нельзя прочитать DTD в DOM, например, для его модификации и сохранения.</p>
<p>Для преодоления этих недостатков были сделаны несколько предложений более похожих на базы данных иерархических схем, определяющих критерии верификации. Основные предложения обсуждаются ниже.
<br/><h4>2.2.1 XML Schema</h4>
<br/>Это большой комплексный стандарт, имеющий две части. Одна часть определяет структурные взаимосвязи. (Это самая большая и наиболее сложная часть.) Другая часть определяет механизмы проверки содержимого XML-элементов при помощи определения <b>типов данных</b> (возможно очень сложных) для каждого элемента. Хорошей новостью является то, что XML Schema for Structures позволяет указать любой тип взаимосвязей, какие можно только представить. Плохой новостью является большой объем работы для их реализации и некоторое время на изучение. Большинство из альтернатив предоставляют более простые определения структуры, чем стандарт типов данных XML Schema.
</p>
<p>Дополнительная информация по XML Schema находится в спецификации W3C XML Schema (Structures) и XML Schema (Datatypes) вместе с другой дополнительной информацией на странице https://www.w3.org/XML/Schema.</p>
<br/><h4>2.2.2 RELAX NG</h4>
<br/>Regular Language description for XML (описание языка регулярных выражений для XML).
<p>Более простым, чем XML Structure Schema, является появляющийся стандарт под протекцией OASIS (Organization for the Advancement of Structured Information Systems) - Организации по развитию структурированных информационных систем. RELAX NG использует модель регулярных выражений для указания ограничений структурных взаимосвязей. Этот стандарт разработан для работы с механизмом определения типов данных XML Schema и указания ограничений их содержимого. Он использует синтаксис XML и содержит преобразователь DTD в RELAX. ("NG" обозначает "Next Generation". Это более новая версия механизма схем RELAX, которая интегрирует в себя TREX.)</p>
<p>Дополнительная информация по RELAX NG находится на странице https://www.oasis-open.org/committes/relax-ng/.
<br/><h4>2.2.3 TREX</h4>
<br/>Tree Regular Expressions for XML (дерево регулярных выражений для XML).
</p>
<p>Это средство выражения критериев верификации путем описания <b>шаблона</b> структуры и содержимого XML-документа. Сейчас является частью спецификации RELAX NG.</p>
<p>Дополнительная информация по TREX находится на странице https://www.thaiopensource.com/trex/.
<br/><h4>2.2.4 SOX</h4>
<br/>Schema for Object-oriented XML (схема для объектно-ориентированного XML).
</p>
<p>SOX является схемой, включающей расширяемые типы данных, пространства имен и встраиваемую документацию.</p>
<p>Дополнительная информация по SOX находится на странице https://www.w3.org/TR/NOTE-SOX/.
<br/><h4>2.2.5 Schematron</h4>
<br/>Схема для объектно-ориентированного XML.
</p>
<p>Механизм схемы, основанный на утверждениях и предлагающий комплексную верификацию.</p>
<p>Дополнительная информация по механизму верификации Schematron находится на странице https://www.ascc.net/xml/resource/schematron/schematron.html.
<br/><h3>2.3 Стандарты связывания и представления</h3>
<br/>Бесспорно, двумя основными преимуществами HTML были способность иметь связи между документами и способность создавать форматированные документы (и, в конечном итоге, очень сложные форматированные документы). Следующие стандарты призваны сохранить преимущества HTML в области XML, а также добавить новую функциональность.
<br/><h4>2.3.1 XML Linking</h4>
<br/>Эти спецификации предоставляют разнообразные мощные механизмы связывания и, конечно же, оказывают большое влияние на то, как используются XML-документы.
<br/>
<br/><b>XLink</b>
</p>
<p>Протокол XLink - это спецификация обработки связей между XML-документами. Эта спецификация предоставляет возможность организовывать некоторые довольно непростые связи, включая двунаправленные ссылки, ссылки на несколько документов, "расширяющиеся" ссылки, которые вставляют связанную информацию в ваш документ, а не заменяют его новой страницей, ссылки между двумя документами, созданными в третьем, независимом документе, и непрямые ссылки (так что вы можете указать на "адресную книгу" а не прямо на нужный документ - обновление адресной книги автоматически изменит все ссылки, ее использующие).</p>
<br/>
<br/><b>XML Base</b>
<p>Этот стандарт определяет атрибут XML-документов, в котором указывается "базовый" адрес, используемый при вычислении указанного в документе относительного адреса. (Так, например, простое имя файла может быть найдено в указанном в базовом адресе каталоге.)</p>
<br/>
<br/><b>XPointer</b>
<p>В общем случае, спецификация XLink ссылается на документ или сегмент документа, используя его ID (идентификатор). Спецификация XPointer определяет механизмы для "адресации во внутренние структуры XML-документов" без необходимости указания автором документа ID для этого сегмента. Цитируя спецификацию, она обеспечивает "обращение к элементам, строкам символов и другим частям XML-документов, независимо от того, имеют они или нет явный атрибут ID".</p>
<p>Дополнительная информация по стандартам XML Linking находится на странице https://www.w3.org/XML/Linking.
<br/><h4>2.3.2 XHTML</h4>
<br/>Спецификация XHTML - это способ создания XML-документов, которые выглядят и ведут себя так же как HTML-документы. Поскольку XML-документ может содержать любые теги, которые вы позаботились определить, почему бы не определить набор тегов, выглядящих как HTML? Во всяком случае, именно эта идея стоит за спецификацией XHTML. Результатом применения этой спецификации является документ, который может отображаться в броузерах, а также обрабатываться как XML-данные. Данные могут быть не настолько идентифицируемыми, как в "чистом" XML, но ими можно будет намного легче манипулировать, чем в стандартном HTML, поскольку XML предлагает намного большую регулярность и логичность.
</p>
<p>Например, каждый тег в формально-правильном XML-документе должен иметь завершающий тег или должен заканчиваться знаками />. То есть, вы можете увидеть </p>
<br/>...
<br/> или
<br/>, но вы никогда не увидите стоящего отдельно
<br/>. Из-за этого требования вы никогда не должны программировать непонятные конструкции, которые можно увидеть в HTML, где, например, тег <dt> может завершаться тегом </dt>, другим <dt>, <dd> или </dl>. Это намного облегчает написание кода!
<p>Спецификация XHTML - это перенос HTML 4.0 в XML. Последняя информация находится на странице https://www.w3.org/TR/xhtml1.</p>
<br/><h3>2.4 Стандарты знаний</h3>
<br/>Если оглянуться на весь путь развития информации в Web за последние пять или шесть лет, можно заметить, что она превратилась в одну огромную базу знаний ("семантика Web"). Последняя информация по этому вопросу находится на странице https://www.w3.org/2001/sw/.
<p>Между тем, вот фундаментальные стандарты, о которых вы должны знать:</p>
<br/><h4>2.4.1 RDF</h4>
<br/>Resource Description Framework (среда описаний ресурсов).
<p>RDF является стандартом для определения <b>метаданных</b> - информации, описывающей, чем является элемент данных и как он может быть использован. Используемый совместно со спецификацией XHTML например, или с HTML-страницами, RDF может применяться для описания содержимого страниц. Например, если ваш броузер сохранил вашу идентификационную информацию как FIRSTNAME, LASTNAME и EMAIL, описание RDF могло бы сделать возможной передачу данных в приложение, нуждающееся в NAME и EMAILADDRESS. Только представьте: однажды вам не надо будет вводить имя и адрес на каждом Web-сайте, который вы посещаете!</p>
<p>Последняя информация по RDF находится на странице https://www.w3.org/TR/REC-rdf-syntax.
<br/><h4>2.4.2 RDF Schema</h4>
<br/>RDF Schema предоставляет спецификацию логических правил и дополнительную информацию, описывающую, как должны интерпретироваться операторы в RDF.
</p>
<p>Дополнительная информация по рекомендациям RDF Schema находится на странице https://www.w3.org/TR/rdf-schema.</p>
<br/><h3>2.6 Итоги</h3>
<br/>XML становится общепринятым стандартом, используемым в огромном разнообразии прикладных областей.
<br/><h2>3 Разработка структуры данных XML</h2>
<br/>В этом разделе рассмотрены некоторые эвристические подходы к принятию тех или иных решений при создании XML-документа.
<br/><h3>3.1 Облегчение своей работы</h3>
<br/>Когда это возможно, используйте существующее определение схемы. Всегда легче игнорировать ненужные элементы, чем создавать свои собственные с нуля. Кроме того, использование DTD делает возможным обмен данными и может сделать возможным использование программных средств, разработанных другими.
<p>Итак, если существует отраслевой стандарт, используйте ссылку на его DTD. Одним из мест для поиска отраслевых стандартов DTD является архив, созданный Organization for the Advancement of Structured Information Standards (OASIS - организацией по развитию стандартов структурированной информации), находящийся на сайте https://www.XML.org. Другим местом для проверки является XML Exchange от CommerceOne на сайте https://www.xmlx.com, который описывается как "архив для создания и совместного доступа к определениям типов документов".</p>
<p>Примечание: Очень много хороших рекомендаций по созданию XML-структур находится на странице OASIS https://www.oasis-open.org/cover/elementsAndAttrs.html.
<br/><h3>3.2 Атрибуты и элементы</h3>
<br/>Одним из вопросов, с которым вы будете часто сталкиваться при разработке XML-структуры, является вопрос, как смоделировать какой-либо элемент данных как субэлемент, или как атрибут существующего элемента. Например, вы можете смоделировать заголовок слайда либо как:
<br/><slide>
<br/>
<br/><title>This is the title
либо как:
...
В некоторых случаях различные характеристики атрибутов и элементов облегчают выбор. Рассмотрим сначала именно такие случаи, а затем перейдем к таким, где выбор более неоднозначный.
3.2.1 Вынужденный выбор
Иногда выбор между атрибутом и элементом очень прост из-за их природы. Рассмотрим несколько таких случаев:
Данные содержат подструктуры
В этом случае данные должны быть представлены как элемент. Он не может быть представлен как атрибут, поскольку атрибуты могут содержать только простые строки. То есть, если заголовок может содержать выделенный текст, как, например, The Best Choice, то заголовок должен быть элементом.
Данные содержат несколько строк
Здесь тоже имеет смысл использовать элемент. Атрибуты должны быть простыми, короткими строками, иначе они станут нечитаемыми, или вообще непригодными к использованию.
Возможны несколько экземпляров
Если элемент данных может встретиться несколько раз, например параграфы в строке, он должен быть представлен как элемент. Элемент, содержащий такие данные, может иметь только один атрибут данного типа, но может иметь много субэлементов того же типа.
Нет часто изменяемых данных
Если данные будут часто меняться при помощи редактора, имеет смысл представить их как элемент. Многие из XML-редакторов легко позволяют модифицировать элементы данных, в то время как к атрибутам иногда нелегко получить доступ.
Данные представляют собой короткую, простую строку, которая редко или никогда не меняется
Такие данные могут быть представлены как атрибуты. Однако то, что вы можете сделать, не означает то, что вы должны это сделать. Прочитайте следующий раздел "Стилистический выбор", чтобы быть уверенным в своих действиях.
Использование DTD в том случае, когда данные ограничены небольшим количеством фиксированных вариантов
Это как раз тот случай, когда имеет смысл использовать атрибуты. DTD может защитить атрибут от получения значения, не входящего в предопределенный список, но не может таким же образом ограничить элемент. (С другой стороны, схема может ограничить и атрибуты и элементы.)
3.2.2 Стилистический выбор
Очень часто выбор не так тривиален, как описано выше. Когда выбор не является вынужденным, вам нужно чувство "стиля" для направления хода мыслей. Следовательно, нужно ответить на вопрос - что создает хороший XML-стиль, и почему.
Определение чувства стиля для XML, к сожалению, такое же неблагодарное дело, как и определение "стиля" в искусстве или музыке. Однако существует несколько путей для достижения этого. Цель этого раздела - изложить несколько полезных мыслей по вопросу "XML-стиля".
Видимость
Один из эвристических подходов к выбору между XML-элементами и атрибутами использует концепцию видимости. Если данные планируется показывать - отобразить для какого-либо конечного пользователя - то они должны быть представлены как элемент. С другой стороны, если информация предназначена для XML-обработки и никогда не показывается пользователю, то ее лучше представить в виде атрибута. Например, в форме заказа обуви, размер ее определенно может быть элементом. С другой стороны, кодовый номер производителя разумно представить атрибутом.
Потребитель/поставщик
Другим подходом является ответ на вопрос - кто является потребителем и/или поставщиком информации. Размер обуви вводится человеком-продавцом, то есть это - элемент. С другой стороны кодовый номер производителя для данной модели обуви может быть передан в приложение или записан в базу данных, то есть, он должен быть атрибутом. (Если бы он вводился продавцом, он, возможно, был бы элементом.)
Контейнер против содержимого
Возможно, лучшим подходом к размышлению об элементах и атрибутах является предположение, что элемент - это контейнер. Используя аналогию, содержимое контейнера (вода или молоко) соответствует XML-данным, представленным как элементы. Такие данные, по сути, являются переменными. С другой стороны, характеристики контейнера (белый или синий кувшин) могут быть представлены как атрибуты. Такой тип информации является более постоянным. Хорошим XML-стилем будет, следовательно, отделение содержимого каждого контейнера от его характеристик.
Покажем эти эвристические подходы на практике. При показе слайдов тип слайда (для администрации или для технического персонала) лучше всего представить в виде атрибута. Это характеристика слайда, позволяющая выбрать или отложить слайд для конкретной аудитории. Название слайда, с другой стороны, является частью его содержимого. Подход, основанный на видимости, здесь тоже работает. При показе слайда его название показывается, а тип слайда нет. Наконец в этом примере потребителем информации о названии является аудитория, в то время как потребителем информации о типе является программа презентации.
3.3 Нормализация данных
В разделе "Разработка структуры данных XML" показано, как создать внешний объект, на который вы можете ссылаться в XML-документе. Такой объект обладает всеми преимуществами модульной подпрограммы - изменение этой одной копии влияет на каждый документ, к ней обращающийся. Процесс устранения избыточности известен под названием нормализация, так что определение объектов - это один из хороших методов нормализации ваших данных.
В HTML-файле единственным способом достичь такого типа модульности является использование HTML-ссылок - естественно документ становится фрагментированным. XML-сущности, с другой стороны, не страдают от такой фрагментации. Ссылка на сущность работает как макроподстановка - содержимое объекта размещается в текущем месте, создавая цельный документ, а не фрагментированный. И когда сущность определена во внешнем файле, несколько документов могут ссылаться на нее.
Соображения для определения ссылки на сущность, следовательно, почти такие же, как и те, какие вы применяете для разбиения на модули программного кода:
-
Где бы вы ни обнаружили, что записываете один и тот же фрагмент более чем один раз, подумайте об отдельной сущности. Это позволит вам записать ее один раз и поставить ссылки в нескольких местах.
-
Если существует вероятность изменения информации, особенно если она используется более одного раза, определенно подумайте об определении сущности. Примером является определение productName в виде сущности, для того чтобы можно было легко изменить документы при изменении названия продукта.
-
Если на сущность никогда не будет ссылок кроме текущего файла, определите ее в local_subset DTD документа, точно также как вы определяете метод или внутренний класс в программе.
-
Если на сущность есть ссылки из нескольких документов, определите ее как внешнюю сущность, так же как вы определяете любой общий класс в качестве внешнего класса.
Внешние сущности формируют XML-документ, который меньше по размерам, легче для обновления и поддержки. Они могут также сделать результирующий документ несколько более трудным для визуализации, также как и хороший OO-дизайн (объектно-ориентированный) может быть легким для изменения, если вы понимаете его, но поначалу тяжелым для просмотра, поскольку нужно мотать головой в разные стороны в поисках нужных классов.
Вы можете также зайти слишком далеко при использовании сущностей. Впав в крайность, вы можете создать ссылки на отдельную сущность для слова "the" - это не принесет вам никакой выгоды, но вы можете сделать это.
Примечание: Чем больше сущность, тем менее вероятно, что ее изменение вызовет побочные эффекты. При определении внешней сущности, охватывающей всю часть инструкций по установке, например, при изменении в этой части очень маловероятно испортить документы, зависящие от нее. Однако маленькие встроенные подстановки могут быть более проблематичными. Например, если productName определен как сущность, можно изменить имя в другую часть речи, и это может произойти. Предположим, что имя продукта, например, "HtmlEdit". Это глагол. То есть вы пишете предложение, которое после подстановки сущности выглядит так: "You can HtmlEdit your file...". Это предложение читается нормально, поскольку глагол хорошо подходит в этот контекст. Но если имя случайно изменить на "HtmlEditor", предложение станет таким: "You can HtmlEditor your file...", которое явно не верно. Тем не менее, даже если такие подстановки могут иногда вызвать проблемы, они могут потенциально сохранить много времени. (Одной из альтернатив было бы создание сущностей с именем productNoun, productVerb, productAdj и productAdverb!)
3.4 Нормализация DTD
Также как вы можете нормализовать ваш XML-документ, вы можете нормализовать ваши DTD-описания путем вынесения общих частей и создания ссылок на них при помощи параметра. Этот процесс описан в руководства по SAX в разделе "Определение параметров и условных секций". Выделение частей в DTD (называемое также как модуляризация или нормализация) дает те же преимущества и недостатки, что и нормализованный XML-документ - легко меняется, но немного трудно просматривается.
Вы можете также настроить условные DTD, как описано в разделе руководства по SAX "Условные секции". Если количество и размер условных секций малы по сравнению с размером целого DTD, вы можете создать "один источник" DTD, который сможете использовать для разных целей. Если количество условных секций становится большим, в результате может получиться сложный документ, который трудно редактировать.