Правила навигации (элементы типа arc)

По сравнению с простыми связями расширенные связи являются несколько более сложными концепцией, поскольку они предоставляют множество различных путей обхода. Например, в расширенной связи с тремя ресурсами A, B и C возможны девять различных обходов:

A --> A

B --> B

C --> C

A --> B

B --> A

A --> C

C --> A

B --> C

C --> B

Каждый из этих потенциальных путей между ресурсами может иметь различные правила определения того, когда связь должна обходиться и что должно происходить при ее обходе. Эти потенциальные обходы называются ребрами (arc), а в XML они представляются с помощью элементов, у которых значение атрибута xlink:type равно arc. Правила обхода указываются добавлением атрибутов xlink:show и xlink:actuate к элементам типа arc.

Сами элементы типа arc используют атрибуты to и from, для указания направления перехода. Для задания начала и конца перехода применяются атрибуты xlink:label, значения которых сопоставляются для различных ресурсов в расширенной связи. Например, если атрибут xlink:from равен A, а атрибут xlink:to - B, то тогда ребро направляется из ресурса, у которого атрибут xlink:label равен A, в ресурс, чей атрибут xlink:label равен B. Приведенный ниже код демонстрирует сказанное:

Первый элемент CONNECTION описывает ветвь из ресурса с xlink:label, равным "source", в ресурс с xlink:label, равным "ch". Второй элемент CONNECTION описывает ветвь из ресурса с xlink:label, равным "source", в ресурс с xlink:label, равным "us", - и так далее. На рисунке 2 приведена эта связь: овалы показывают ресурсы, а стрелки - ветви. Этот рисунок поход на рисунок 1 с тем исключением, что на нем между ресурсами появились соединения, указанные элементами типа arc.

Рис. 2.

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

Расширенные связи

Можно сказать, что простые связи в большей или меньшей степени напоминают связи HTML. Расширенные связи значительно превосходят связи HTML с точки зрения предоставляемых возможностей: они включают многонаправленные связи между многочисленными документами и внешние (out-of-line) связи. Расширенная связь состоит из набора ресурсов и их соединений. Ресурсы, используемые в связи, могут быть либо локальными (являющиеся частью элемента расширенной связи), либо удаленными (не являющиеся частью элемента расширенной связи и обычно находящиеся, хотя и необязательно, в другом документе). Каждый ресурс может быть или адресатом, или источником, либо тем и другим. Если связь не содержит ни одного локального ресурса, а только удаленные ресурсы, она называется внешней связью.

Синтаксис расширенных связей

Расширенные связи подразделяются на удаленные и локальные ресурсы. Локальный ресурс является частью элемента расширенной связи, значение атрибута xlink:type которого равно resource.

Удаленный ресурс находится вне элемента расширенной связи, обычно в другом документе. Эти элементы могут иметь любое имя, но включают атрибут xlink:type, значение которого равно locator. Каждый элемент типа locator также содержит атрибут xlink:href, значением которого является URI, локализующий этот удаленный ресурс.

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

Предположим, например, что мы описываем страницу связей с сайтами Java. Один из этих сайтов - это Cafe au Lait в . Помимо него существуют еще три "зеркальных отображения" (mirror) в трех странах. Часть людей, зашедших на этот сайт, захочет получить доступ к основному сайту, другая часть предпочтет отправиться на "сайты-зеркала". С помощью XLink можно создать одну связь, которая соединяет все четыре сайта, а также страницу, с которой мы связываемся. При активизации связи браузер сможет выбрать ближайшую к пользователю связь (повторимся, что этот пример является исключительно теоретическим). Четыре сайта описываются с помощью элементов типа locator. Текст, который будет показан пользователю, на нашей странице описывается элементом типа resource. Ниже приведен соответствующий код XML:

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

Рис. 1.

Подготовлено: по материалам зарубежных сайтов

Перевод:

Внешние связи

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

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

В качестве еще одного примера рассмотрим некий учебный курс по Java, публикуемый на Web-сайте. На рисунке 3 показана вводная страница этого курса. Этот курс состоит из 13 занятий (недель - week), каждое из которых охватывает от 30 до 60 страниц лекционного текста. Страница оглавления для каждого занятия включает связи с каждой такой страницей теста, читаемого на занятии.

Рис. 3.

Каждая из нескольких сотен станиц, образующих весь этот учебный курс, имеет связи с предыдущим документом (Previous link), следующим документом (Next link) и оглавлением (Top link) для каждого занятия (см. рисунок 4). Если попытаться грубо оценить этот проект, то в нем оказывается задействованным более тысячи внутренних соединений, охватывающих все эти документы.

Рис. 4.

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

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

&lt!- Список аналогичных элементов -->

xlink:label="class"/> <CLASS xlink:type="locator" xlink:href="week13.xml" xlink:label="class"/> <CONNECTION xlink:type="arc" from="index" to="class"/> <CONNECTION xlink:type="arc" from="class" to="index"/> </COURSE>

В следующем примере приведена еще одна возможная внешняя расширенная связь. Она обеспечивает предыдущую (previous) и следующую (next) связи между указанными тринадцатью занятиями:

<COURSE xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended"> <CLASS xlink:type="locator" xlink:href="week1.xml" xlink:label="1"/> <CLASS xlink:type="locator" xlink:href="week2.xml" xlink:label="2"/>

&lt!- Список аналогичных элементов -->

<CLASS xlink:type="locator" xlink:href="week13.xml" xlink:label="13"/>

 <CONNECTION xlink:type="arc" xlink:from="2" xlink:to="1"/> <CONNECTION xlink:type="arc" xlink:from="3" xlink:to="2"/>

&lt!- Список аналогичных элементов -->

<CONNECTION xlink:type="arc" xlink:from="13" xlink:to="12"/>

 <CONNECTION xlink:type="arc" xlink:from="1" xlink:to="2"/> <CONNECTION xlink:type="arc" xlink:from="2" xlink:to="3"/>

&lt!- Список аналогичных элементов -->

<CONNECTION xlink:type="arc" xlink:from="12" xlink:to="13"/> </COURSE>

Ниже приведен код, в котором один из элементов типа arc содержит атрибут xlink:arcrole, значение которого равно . Атрибут xlink:to этого элемента типа arc должен идентифицировать элемент типа locator, который дает URL этой базы связей. Атрибут xlink:actuate элемента типа arc определяет, загружаются ли эти связи автоматически или для этого требуется пользовательский запрос. Например, если приведенные выше два примера кода находились бы в файле по URL , этот элемент мог бы быть включен в основную страницу для лекций по курсу Java:

<LINKBASE xlink:type="xlink:extended" xmlns:xlink="http://www.w3.org/1999/xlink"> <SOURCE xlink:type="resource" xlink:label="source"/> <LINKS xlink:type="locator" xlink:label="linkbase" xlink:href= "http://ibiblio.org/javafaq/course/courselinks.xml"/> <LOAD xlink:type="arc" xlink:arcrole= "http://www.w3.org/1999/xlink/properties/linkbase" xlink:from="source" xlink:to="linkbase" xlink:actuate="onLoad" /> </LINKBASE>

Эвристические процедуры

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

<?xml <!DOCTYPE <foo, где foo - любое имя XML

Проблемы с наборами символов несколько усложняют распознавание. Во всех трех случаях перед этими символами может присутствовать или отсутствовать порядковый знак в виде байта Unicode, причем в различных форматах: UTF-8, а также UTF-16 с прямым или обратным порядком байтов. Более того, могут использоваться числа из любых наборов символов помимо Unicode, в частности из ASCII, ISO-8859-1 (Latin-1) и EBCDIC. Но поскольку эти наборы во многом перекрываются в области символов, которые с наибольшей вероятностью могут оказаться в начале документа XML, все их разнообразие сводится к нескольким общим последовательностям байтов, показанным ниже в шестнадцатеричном формате:

FE FF 00 3C 00 3F FF FE 3C 00 3F 00 3C 3F 78 6D EF BB BF 3C 3F 4C 6F A7 94 3C

Эти эвристические процедуры отнюдь не являются универсальными. Их наиболее характерная ошибка - идентификация неправильно оформленных документов HTML как возможных файлов XML. Работу этих процедур можно улучшить, если убрать начальные пробелы (знаки табуляции, символ возврата каретки или новой строки и собственно пробел) перед первым знаком < или убедиться, что первый знак после символа < - это ?, ! или одна из возможных первых букв имени XML. На практике, если документ не начинается с одной из выше названных последовательностей, он вряд ли окажется файлом XML. Если контролировать эти символы в первую очередь, то можно отбросить множество лишней информации и сэкономить время за счет того, что парсеры будут проверять только документы, которые с наибольшей вероятностью являются файлами XML.

Ресурсы

Многоцелевые расширения почтовых сообщений Internet. Часть 2: типы электронной корреспонденции (RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types). Общественный регистр типов электронной корреспонденции (MIME type registry). Типы электронной корреспонденции XML (RFC 3023, XML Media Types). Архитектура всемирной сети, том 1 (Architecture of the World Wide Web, Volume One). Улучшенный способ идентификации типов файлов, изобретенный фирмой Apple Computer двадцать лет назад. Он также описан в книге "Внутри Macintosh: основы инструментальных панелей" (Inside Macintosh: Macintosh Toolbox Essentials): глава 7 - "Интерфейс поиска" (Finder Interface). Опыт использования операционной системы BeOS в проекте Haiku. Библия XML 1.1 (XML 1.1 Bible). Книга также доступна в интернет-магазине Amazon.com.

DB2® - программное решение IBM для управления информацией, основанное на совокупности мощных серверов систем управления реляционными базами данных. Дополнительные ресурсы по XML на сайте IBM (developerWorks XML zone). Информация о том, как стать Сертифицированным разработчиком IBM в области XML и других смежных технологий (IBM Certified Developer in XML and related technologies).

Типы электронной корреспонденции

При передаче файла web-сервер посылает не только его имя и содержание. Он также отправляет множество метаданных о файле в заголовке HTTP (см. листинг 1):

Листинг 1. Пример метаданных

HTTP/1.1 200 OK Date: Sun, 23 Jan 2005 18:21:33 GMT Server: Apache/2.0.52 (Unix) mod_ssl/2.0.52 OpenSSL/0.9.7d Last-Modified: Sun, 10 Oct 2004 16:17:21 GMT ETag: "3e06d-16a05-2dbc8640" Accept-Ranges: bytes Content-Length: 92677 Content-Type: application/xhtml+xml

Необходимо обратить внимание на заголовок Content-Type в последней строке. Его значение - application/xhtml+xml - это тип электронной корреспонденции (он может сопровождаться информацией о наборе символов документа). Web-браузеры и другие получатели используют эти метаданные для того, чтобы понять, как обрабатывать файл. Например, такие данные позволяют определить, может ли файл быть представлен в своем оригинальном виде или необходимо использовать вспомогательное приложение. Типы электронной корреспонденции используются и в других контекстах, в том числе в электронной почте, а также в некоторых экспериментальных операционных системах, например, BeOS. Linux и другие системы UNIX® также пользуются типами электронной корреспонденции, но делают это несколько по-другому. Они не присваивают файлам напрямую определенные типы электронной корреспонденции, а преобразуют ("мэппируют") расширения файлов в эти типы. Основная область практического использования типов электронной корреспонденции - это интернет.

Основной тип содержимого для типичного документа XML - application/xml. Тип text/xml также является зарегистрированным, но он подвергнулся осуждению из-за некоторых неудачных взаимодействий с другими частями протокола HTTP. (Использование text/xml указывает, что документ находится в кодировке ASCII, даже если декларация XML дает другую информацию). Ниже приведены еще несколько основных зарегистрированных типов электронной корреспонденции:

application/xml-dtd - используется для определения типа документа; application/xml-external-parsed-entity - используется для фрагментов документов.

По существующему соглашению, для более специфических типов форматов XML используется тип application/foo+xml, где foo подразумевает употребление специального словаря XML. Например, application/rdf+xml для RDF, application/xhtml+xml для XHTML, application/svg+xml для SVG и т.д. При этом обычные процессоры XML могут распознать, что документ находится в формате XML, а процессоры для обработки тех или иных специальных форматов способны определить, в каком именно формате он создан. В таблице 2 перечислены некоторые наиболее распространенные типы электронной корреспонденции.

Таблица 2. Типы электронной корреспонденции XML

Типы корреспонденции	Формат документа
image/svg+xml*	Масштабируемая векторная графика
application/atom+xml*	Синдикация атомарных данных
application/mathml+xml*	Математический язык разметки
application/beep+xml	Расширяемый протокол обмена блоков
application/cpl+xml	Язык обработки запросов
application/soap+xml	Сообщение SOAP
application/epp+xml	Расширяемый протокол инициализации
application/rdf+xml	XML-синтаксис описания ресурсов
application/xhtml+xml	Расширяемый язык разметки гипертекста
application/xop+xml	Бинарная оптимизированная организация пакетов XML
application/xslt+xml*	Таблица стилей расширяемого языка преобразования таблиц стилей
application/xmpp+xml	Расширяемый протокол обмена сообщениями и присутствия
application/voicexml+xml*	Голосовой расширяемый язык разметки

* Находится в процессе регистрации

Невозможно создавать новые типы электронной корреспонденции для каждого вновь появляющегося формата. Новые типы должны публиковаться в виде формальной спецификации (часто это так называемые "Запросы на комментарии" (Request for Comments) Проблемной группы проектирования Internet (Internet Engineering Task Force, сокр. IETF)) и регистрироваться в Агентстве по выделению имен и уникальных параметров протоколов Internet (Internet Assigned Numbers Authority - IANA). Но экспериментальные подтипы могут определяться и без регистрации. Они должны начинаться с символов х-. Например, тип корреспонденции для авторского языка разметки номенклатуры телевизоров, придуманного автором в качестве примера для его книги "Библия XML 1.1" (XML 1.1 Bible), может быть назван application/x-tvml+xml. Тип application указывает процессорам, что данный файл должен обрабатываться не как данные ASCII. Выражение +xml в конце названия подтипа информирует, что это файл XML, х- говорит о том, что это не зарегистрированный тип, а tvml несет информацию о виде данных.

Управление данными XML: подходы к определению документов XML

Перевод: Intersoft Lab

Оригинал: Managing XML data: Identify XML documents

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

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

Если документы XML хранятся в виде файлов, то лучше использовать стандартные расширения. Это существенно облегчает поиск, распознавание и обработку файлов XML. На сегодня самым распространенным расширением является .xml, но для отдельных подмножеств XML используется и ряд других (табл. 1).

Таблица 1. Стандартные расширения файлов XML

Расширение	Значение
.xml	Общий документ XML
.ent	Элемент документа, фрагмент документа
.dtd	Определение типа документа
.rdf	XML-синтаксис описания ресурсов
.atom	Обеспечение синдикации атомарных данных
.owl	Язык онтологии web
.xhtml	Расширяемый язык разметки гипертекста
.xsd	Язык схем XML (W3C XML Schema Language)
.xsl	Преобразования расширяемого языка таблиц стилей (Extensible Stylesheet Language, сокр. XSL)
.fo	Форматирование объектов XSL
.rng	Синтаксис RELAX NG XML
.sch	Схема языка Schematron
.svg	Масштабируемая векторная графика
.rss	Простая синдикация (Really Simple Syndication), формат Rich Site Summary или RDF Site Summary
.plist	Формат списка свойств Apple

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

Еще один способ определить, какие

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

Элементы или атрибуты?

Автор: Дэвид Мертц (David Mertz)

Перевод:

Авторские права:

Моделирование неупорядоченных вложенных элементов

Для того, чтобы XML-документ, представленный в Листинге 2, был допустимым, в DTD следует добавить следующее определение:

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

<!ELEMENT contact (name?,age?,telephone?)+>

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

Громоздкое, но точное DTD для элементов, несущих контактную информацию

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

Обязательность сохранения свободного места

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

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

Ресурсы

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

В рубрике XML Cover Pages приводятся рекомендации по "Использованию элементов и атрибутов" (). На этой странице также можно найти ссылки на ряд статей, в которых предлагаются взаимопротиворечащие рассуждения о том, что выбрать атрибуты или элементы. Именно по этой причине мы, программисты, и "получаем наш длинный доллар"!

Еще один способ понять различие между атрибутами и элементами - это изучить материалы "Форматы, основанные на документах, или форматы, основанные на данных" ("").

Познакомьтесь с другими статьями колонки "Советы о XML" (), публикуемыми в разделе developerWorks XML.

Важен ли порядок следования данных

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

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

Листинг 1. Использование атрибутов для передачи контактной информации

<?xml version="1.0" ?> <!DOCTYPE contacts SYSTEM "attrs.dtd" > <contacts> <contact name="Jane Doe" age="74" telephone="555-3412" /> <contact name="Chieu Win" telephone="555-8888" age="44" /> </contacts>

Листинг 2. Использование вложенных элементов для передачи контактной информации

<?xml version="1.0" ?> <!DOCTYPE contacts SYSTEM "subelem.dtd" > <contacts> <contact> <name>Jane Doe</name> <age>74</age> <telephone>555-3412</telephone> </contact> <contact> <name>Chieu Win</name> <telephone>555-8888</telephone> <age>44</age> </contact> </contacts>

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

Листинг 3. DTD для документа с использованием атрибутов

<!ELEMENT contacts (contact*)> <!ELEMENT contact EMPTY> <!ATTLIST contact name CDATA #REQUIRED age CDATA #REQUIRED telephone CDATA #REQUIRED >

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

Листинг 4. DTD для документа с использованием вложенных элементов

<!ELEMENT contacts (contact*)> <!ELEMENT contact (name,age,telephone)> <!ELEMENT name (#PCDATA)> <!ELEMENT age (#PCDATA)> <!ELEMENT telephone (#PCDATA)>

Очевидный недостаток DTD, приведенного в Листинге 4, состоит в том, что этот простой пример (Листинг 2) является недопустимым согласно этому DTD. Дело в том, что порядок вложенных элементов нарушен. В таблице показано, как можно использовать неупорядоченные вложенные элементы с DTD, хотя, если не имеется иных непреодолимых причин, лучший выбор - воспользоваться заданием атрибутов для передачи неупорядоченных данных.

Важность удобочитаемости

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

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

Вопросы проектирования XML-форматов

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

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

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

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

Возможность нахождения многочисленных данных на одном уровне

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

Однако, в реальной жизни при внесении изменений разработчики часто уходят от этого принципа проектирования. Рассмотрим, как это может происходить: сначала вы определяете, что у каждого Flazbar имеется прикрепленный к нему flizbam (а flizbam описывается одной величиной). Кажется вполне разумным сберечь дополнительное наполнение вложенных элементов и создать атрибут flizbam для тега Flazbar. Однако, затем - после того, как вы уже написали великолепный рабочий код для обработки несколькими Flazbar - вы узнаете, что в некоторых случаях у Flazbar могут быть два flizbam. Но это не проблема: вы вносите незначительные изменения в установленный код и просто переписываете DTD:

<!ATTLIST Flazbar flizbam CDATA #REQUIRED flizbam2 CDATA #IMPLIED>

После исправления кода ваши старые XML-документы по-прежнему допустимы, и новые работоспособны. Немного погодя вы обнаруживаете, что у Flazbar может быть третий flizbam...

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

В этой статье было показано,

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

Более интересные примеры

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

Первый вариант - использование пространств имен как метода идентификации типов документов или управления их версиями. Достаточно распространенными являются следующие конструкции: <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

Это пример самого верхнего тэга сообщения SOAP 1.2. Здесь пространство имен выполняет важную задачу. Оно информирует потребителя, что данный элемент XML является конвертом SOAP, связан с международным консорциумом W3C (World Wide Web Consortium) и соответствует версии спецификации, принятой в мае 2003 г. Это, безусловно, более информативно, чем альтернативный тэг без пространства имени: <Envelope>.

Итак, данный пример выглядит как один из случаев оправданного использования пространств имен. Но так ли это? Идентификация, безусловно, необходима, но ее можно осуществить и без пространств имен. Все, что для этого требуется, - атрибут и соглашение, подобное следующему: идентифицировать документы с помощью атрибута documentIdentifier в самом верхнем тэге: <Envelope documentIdentifier="http://www.w3.org/2003/05/soap-envelope">

Можно рассмотреть другой пример. Пространства имен широко используются для обеспечения уникальных идентификаторов типов. Нередко встречаются фрагменты XML, подобные следующему: <element name="cost" type="xsd:float"/>

или <element name="greeting" type="SOAP-ENC:string"/>

Здесь xsd и SOAP-ENC - идентификаторы пространства имен, которые относятся к типам схемы XML (XSD) и кодировки SOAP, соответственно. Таким образом, cost является элементом типа float, определяемого в соответствии с XSD, а greeting - элементом типа string, определяемого в соответствии со спецификацией кодировки SOAP. Вот еще похожий пример: <cost xsi:type="xsd:float">29.95</cost>

Эта запись обозначает, что элемент cost имеет определенный тип, определяемый XSI, а также то, что float является типом, определяемым XSD. Ключевым моментом является то, что каждому типу действительно требуются исключительные идентификаторы, не привязанные к контексту. Здесь не происходит объединения одного документа с другим, имеющим кодировку XSD или SOAP. Просто определенные элементы в каждой из спецификаций, используемых в документе, имеют собственные обозначения. Спецификация даже не обязательно должна быть написана на XML, поскольку речь идет о плоской структуре, просто списке типов. Если структура типа является иерархической, тогда нужно полностью указать путь к нему: <cost xsi:type="xsd:/types/simple/float">29.95</cost>

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

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

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

Элементы в контексте

К сожалению, спецификация пространства имен XML игнорирует один из основных принципов XML: документы XML являются иерархическими; ни один тэг не является изолированным.

При выборе того или иного элемента Address пользователь может указать конкретно, какой именно элемент ему нужен: адрес сервера, который находится внутри тэгов Server, или адрес отдела, обозначенный тэгами Department. В формате XML это будут выглядеть следующим образом: /Department/Server/Address или /Department/Address, соответственно. Такой формат не несет никакой двусмысленности; совершенно очевидно, какой элемент имеется в виду в том или другом случае. Это происходит потому, что тэг XML определяется контекстом, а не только именем.

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

Игнорировать структуру и иерархию при работе с XML - это фундаментальная ошибка.

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

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

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

Какова цель создания пространств имен XML?

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

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

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

В таком случае возникает следующий вопрос:

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

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

Объединенный документ выглядит следующим образом.

Листинг 1. Объединенный документ с пространствами имен

<Department> <Name>DVS1</Name> <addr:Address xmlns:addr="http://www.tu-darmstadt.de/ito/addresses"> <addr:Street>Wilhelminenstr. 7</addr:Street> <addr:City>Darmstadt</addr:City> <addr:State>Hessen</addr:State> <addr:Country>Germany</addr:Country> <addr:PostalCode>D-64285</addr:PostalCode> </addr:Address> <serv:Server xmlns:serv="http://www.tu-darmstadt.de/ito/servers"> <serv:Name>OurWebServer</serv:Name> <serv:Address>123.45.67.8</serv:Address> </serv:Server> </Department>

А вот тот же самый документ без пространств имен. В нем отчетливо видны проблемы, связанные с распознаванием и конфликтом имен.

Листинг 2. Объединенный документ без пространств имен

<Department> <Name>DVS1</Name> <Address> <Street>Wilhelminenstr. 7</Street> <City>Darmstadt</City> <State>Hessen</State> <Country>Germany</Country> <PostalCode>D-64285</PostalCode> </Address> <Server> <Name>OurWebServer</Name> <Address>123.45.67.8</Address> </Server> </Department>

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

Каковы преимущества пространства имен XML?

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

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

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

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

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

"Осуждение" пространств имен XML

Автор считает, что приведенные им аргументы достаточно убедительно свидетельствуют о проблемах с пространствами имен XML и о их ограниченной применимости.

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

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

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

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

Проблема

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

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

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

Ресурсы

Спецификация пространств имен XML (). Часто задаваемые вопросы о пространствах имен XML (). Статья "Пространства имен XML не требуют URI" (). Статья "Аккуратное использование пространств имен XML" (). Статья "Планирование использования пространств имен XML" (). Дополнительные ресурсы по XML на сайте . Информация о том, как стать Сертифицированным разработчиком IBM в области XML и других смежных технологий ().

Стоит ли отменять пространства имен XML?

Пэрэнд Тони Дэйруджэр (Parand Tony Darugar)
Перевод:

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