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

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

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

Проблема

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

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

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

Каковы преимущества пространства имен 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 являются иерархическими; ни один тэг не является изолированным.

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

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

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

Если решение проблемы неоднозначности тэгов при объединении документов важно для работы приложения, то использование существующего контекста документа XML является гораздо более простым способом, чем применение сложной новой модели, основанной на уникальных именах. Решение проблемы конфликта и распознавания с помощью пространств имен 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 и их исключение из широкого использования. Он не считает, что в пространствах имен нет вообще никакой необходимости, но утверждает, что потребность в них возникает очень редко и что современная спецификация пространств имен XML создает много проблем. Использование пространств имен в общих документах XML отнюдь не является самой удачной практикой; скорее, это очень затратный способ.

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

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

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

Ресурсы

• Спецификация пространств имен XML (XML Namespace Specification).
• Часто задаваемые вопросы о пространствах имен XML (XML Namespace FAQ).
• Статья "Пространства имен XML не требуют URI" (XML Namespaces Don't Need URIs).
• Статья "Аккуратное использование пространств имен XML" (Use XML namespaces with care).
• Статья "Планирование использования пространств имен XML" (Plan to use XML namespaces).
• Дополнительные ресурсы по XML на сайте developerWorks.
• Информация о том, как стать Сертифицированным разработчиком IBM в области XML и других смежных технологий (IBM Certified Developer in XML and related technologies).

Об авторе

Большая часть карьеры Пэрэнда Тони Дэйругэра (Parand Tony Darugar) была посвящена созданию высокопроизводительных распределенных систем, а также разработке их архитектуры. Он имеет опыт руководства нескольким проектами одновременно, а также работал в крупном интернет-бизнесе. Его интересы включают web-сервисы и сервис-ориентированную архитектуру (Service Oriented Architectures, сокр. SOA), XML, распределенную архитектуру и искусственный интеллект. Его статьи доступны на сайте Standard Deviations. Связаться с автором статьи можно по адресу tdarugar@yahoo.com.

Оригинальный текст статьи можно посмотреть здесь: Abolish XML namespaces?