Основы XML — пространства имен. Область действия по умолчанию

Аннотация: В данном разделе описывается использование и декларация пространств имен. Даются основные характеристики RDF, XML-Data, Document Content Description (DCD), Schema for Object-Oriented XML (SOX), Document Definition Markup Language (DDML, ранее известный как XSchema).

Ранее мы описали некоторые недостатки определений DTD , они связаны:

1. синтаксис этих определений отличается от синтаксиса XML (конкретно, используется так называемая расширенная форма Бэкуса-Наура , Extended Backus Naur Form );
2. эти определения недостаточно выразительны;
3. так как каждый пользователь может создавать свои собственные теги, то вполне вероятна ситуация когда для обозначения различных вещей люди будут пользоваться одними и теми же именами элементов. Даже если значения элементов одинаковы, их возможное содержание может изменяться в зависимости от определения. Таким образом, нам необходим способ, позволяющий определять конкретные виды использования элемента, особенно, если в одном документе мы смешиваем различные виды словарей. Для решения проблемы консорциум W3C выпустил спецификацию, называемую XML Namespaces (пространством имен XML), позволяющую определить контекст элемента в пространстве имен.
4. существуют ситуации, когда необходимо скомбинировать документы XML из разных источников, соответствующих различным определениям DTD . Например, такая ситуация возникает при описании большого объема информации, если отдельных DTD недостаточно для охвата всего объема или они трудны для понимания. Возникает она и в системах электронной коммерции при попытках объединить данные вашего делового партнера с вашими. Так же может возникнуть ситуация когда необходимо просто добавить свои настройки к уже существующей DTD для того чтобы обмениваться некоторой информацией в стандартном формате. К сожалению, рекомендация XML не предоставляет способа совмещения нескольким DTD в одном документе без их модификации или создания нового DTD (используя внешние ссылки).

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

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

• Лучше организовывать словари для решения сложных проблем;
• Сохранять сильную типизацию данных при преобразованиях в XML и из него;
• Более точно и гибко описывать словари, чем это было возможно в случае DTD ;
• Читать правила словаря на языке XML, осуществляя доступ к его определениям без усложнения анализатора.

Смешение словарей

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

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

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

Пространства имен

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

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

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

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

• Ссылку на URI, описывающий использование элемента.
• Псевдоним, позволяющий понять, из какого пространства имен взят наш элемент. Этот псевдоним имеет форму префикса элемента (например, если псевдонимом для неясного элемента Book является слово catalog , то, элемент будет называться ).

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

Декларация пространства имен

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

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

Как видите, префикс ntb только что определен, но его уже можно использовать в имени ntb: notebook . В дальнейшем имена тегов и атрибутов, которые мы хотим отнести к пространству имен http://some.firm.com/2003/ntbml , снабжаются префиксом ntb, например:

Горелово

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

Элемент book взят из пространства имен catalog , а атрибут ISBN - из order .

Имя вместе с префиксом, например

называется расширенным, уточненным или квалифицированным именем (OName. Qualified Name ). Часть имени, записанная после двоеточия, называется локальной частью (local part ) имени.

Номенклатура названий Web-ресурсов может запутать. Универсальный указатель ресурса ( Uniform Resource Locator , URL ) указывает на ресурс в терминах протокола доступа и расположения в сети. Универсальный идентификатор ресурса (Uniform Resource Identifier, URI ) представляет собой уникальное имя некоторого ресурса. Смотрите на URI просто как на уникальную строку символов, идентифицирующую пространство имен.

По правилам SGML и XML, двоеточие может применяться в именах как обычный символ, поэтому имя с префиксом - это просто фокус, всякая программа, "не знающая" пространства имен, анализируя документ, рассматривает уточненное имя как обычное имя. Отсюда следует, в частности, что в объявлении типа документа (Document Type Declaration ) нельзя опускать префиксы имен.

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

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

Появление имени тега без префикса в документе, использующем пространство имен, означает, что имя принадлежит пространству имен по умолчанию (default namespace ).

Хорошо оформленный документ должен использовать пространства имен для всех своих элементов.

Префиксы, начинающиеся с символов xml с любым регистром букв, зарезервированы за самим языком XML. Префикс xmlns используется для связи другого, определяемого, префикса с идентификатором его пространства имен. Префикс xmlns не нужно определять, он введен рекомендацией "Namespaces in XML" и связан там с идентификатором пространства имен http://www.w3.ori/2000 /xmlns/ .

Еще один префикс, xml, связан в той же рекомендации с идентификатором http://www.w3.org/XML/1998/namespace . Его тоже не надо определять в документе XML. Никакой другой префикс не может быть связан с этими идентификаторами.preserve предписывает сохранять пробельные символы в неприкосновенности. Это важно для некоторых текстов, например, программных кодов. Значение default оставляет пробельные символы на усмотрение программы-обработчика.

Область действия

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

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

Область действия по умолчанию

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

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

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

Квалифицированная область действия

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

Пространство имён (XML)

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

В декабре 2009 года третья редакция стандарта получила статус рекомендации.

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

XML-документ может содержать имена элементов и атрибутов из нескольких словарей XML. В каждом словаре задано своё пространство имён - так разрешается проблема неоднозначности имён элементов и атрибутов.

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

Объявление пространства имён

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

Например:

Xmlns="http://www.w3.org/1999/xhtml"

Однако следует обратить внимание, что URL в действительности не читается как адрес в сети, он обрабатывается XML парсером как простая строка. Например, по адресу http://www.w3.org/1999/xhtml на самом деле нет никакого кода, там находится просто справочник по пространству имён xhtml . Использование URL (таких как "http://www.w3.org/1999/xhtml") для идентификации пространства имён вместо простой строки (такой как «xhtml») уменьшает возможность совпадения идентификаторов у различных пространств имён. Идентификаторы пространств имён не обязаны быть правильными веб-адресами, хотя зачастую они ими являются.

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

Xmlns:xhtml="http://www.w3.org/1999/xhtml"

Пространство имён XML не требует, чтобы был определён его словарь, хотя существует сложившаяся практика помещать DTD или XML Schema , определяющие точную структуру данных в контексте конкретного пространства имён.

Ссылки

Wikimedia Foundation . 2010 .

Смотреть что такое "Пространство имён (XML)" в других словарях:

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

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

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

Пространство имён некоторое множество каким либо образом взаимосвязанных имён или терминов. Во избежание путаницы, именам в одном пространстве имён не дают более одного значения. Например, в пространстве имён улиц любого города названия улиц, как … Википедия

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

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

- (XPS) Расширение.xps MIME application/vnd.ms xpsdocument Разработан Microsoft Последний выпуск 1.4(stable) 1.6(experimental) Тип формата язык описания страниц Расширен из … Википедия

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

пространство имен - Совокупность имен, определенных URI (Uniform Resource Identifier универсальный идентификатор ресурса), позволяющая документам на языке XML из различных источников использовать одни и те же имена элементов в рамках одного документа без… … Справочник технического переводчика

Bладимир Энгельс, Oracle СНГ

Введение

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

• необходимо ли всем XML-схемам в проекте присваивать различные значения targetNamespace
• или нужно использовать единый targetNamespace для всех
• и можно ли некоторым XML-схемам не присваивать никакого targetNamespace?

Какой подход будет более оптимальный? Каким руководствам нужно следовать, начиная работу над SOA-проектами, в которых создается несколько XML-схем?

Точности ради, надо отметить, что имеется три проектных подхода при работе с несколькими XML-схемами:

1. гетерогенное пространство имен - каждой XML-схеме присваивается свой targetNamespace;
2. гомогенное пространство имен - всем XML-схемам присваивается единый targetNamespace;
3. пространство имен типа "хамелеон" - главной XML-схеме присваивается targetNamespace, а вспомогательным XML-схемам не присваивается никакого targetNamespace (XML-схемы без targetNamespace используют targetNamespace главной XML-схемы при объединении подобно хамелеону).

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

Пример: XML-модель данных компании

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

• Company.xsd
• Person.xsd
• Product.xsd

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

Гетерогенное пространство имен

Данный проектный подход предполагает использование для каждой XML-схемы своего targetNamespace. Ниже приводится три схемы, спроектированные с применением данного проектного подхода.

Product.xsd

targetNamespace="http://www.product.org" xmlns="http://www.product.org" elementFormDefault="unqualified"> xmlns:per="http://www.person.org" xmlns:pro="http://www.product.org">

Person.xsd

targetNamespace="http://www.person.org" xmlns="http://www.person.org" elementFormDefault="unqualified">

Company.xsd

namespace="http://www.person.org" schemaLocation="Person.xsd"/> namespace="http://www.product.org" schemaLocation="Product.xsd"/> type="per:PersonType" maxOccurs="unbounded"/> type="pro:ProductType" maxOccurs="unbounded"/>

Обратите внимание, что в схемах используется три различных пространства имен:

Http://www.product.org http://www.person.org http://www.company.org

Гомогенное пространство имен

Данный проектный подход предполагает использование единого targetNamespace для всех XML-схем. Ниже приводится три схемы, спроектированные с применением данного проектного подхода.

Product.xsd

targetNamespace="http://www.company.org" xmlns="http://www.product.org" elementFormDefault="qualified">

Person.xsd

targetNamespace="http://www.company.org" xmlns="http://www.person.org" elementFormDefault="qualified">

Company.xsd

targetNamespace="http://www.company.org" xmlns="http://www.company.org" elementFormDefault="qualified"> schemaLocation="Person.xsd"/> schemaLocation="Product.xsd"/> type="PersonType" maxOccurs="unbounded"/> type="ProductType" maxOccurs="unbounded"/>

Обратите внимание, что во всех трех схемах используется единое пространств имен:

Http://www.company.org

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

Пространство имен типа "хамелеон"

Данный проектный подход предполагает использование targetNamespace только для главной XML-схемы, а вспомогательным XML-схемам не присваивается никакого targetNamespace. Ниже приводится три схемы, спроектированные с применением данного проектного подхода. В данном примере XML-схема Company.xsd является главной, XML-схемы Product.xsd и Person.xsd - вспомогательные.

Product.xsd (нет targetNamespace)

Person.xsd (нет targetNamespace)

Company.xsd

targetNamespace="http://www.company.org" xmlns="http://www.company.org" elementFormDefault="qualified"> schemaLocation="Person.xsd"/> schemaLocation="Product.xsd"/> type="PersonType" maxOccurs="unbounded"/> type="ProductType" maxOccurs="unbounded"/> >

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

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

"Эффект хамелеона..." - этот термин ввел Генри Томпсон (Henry Thompson).

Влияние проектных подходов на XML-документы

Выше было продемонстрировано, как могли бы быть спроектированы XML-схемы с применением трех проектных подходов. Теперь обратимся к XML-документам. Отличается ли создание XML-документов, в зависимости от применения того или иного проектного подхода? Все вышеприведенные XML-схемы были спроектированы с требованием явного указания пространств имен в XML-документах (на что указывает: elementFormDefault="qualified"). Если бы они использовали вместо этого elementFormDefault="unqualified", то XML-документ для всех трех случаев имел бы следующую форму:

John Doe 123-45-6789 Widget

Как же будут выглядеть XML-документы для наших трех подходов проектирования?

Company.xml (для версии с гетерогенным пространством имен в targetNamespace)

John Doe 123-45-6789 Widget

Обратите внимание на следующее:

• необходимо иметь декларацию namespace для кадого пространства имен;
• все элементы должны быть уникально квалифицированы (явно или через пространство имен "по-умолчанию").

Company.xml (для версии с гомогенным пространством имен в targetNamespace)

John Doe 123-45-6789 Widget

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

Company.xml (для версии с пространством имен типа "хамелеон" в targetNamespace)

John Doe 123-45-6789 Widget

Обе XML-схемы без определения targetNamespace приняли targetNamespace XML-схемы Company.xsd (подобно хамелеон-эффекту). Таким образом, все компоненты принадлежат одному targetNamespace, и в XML-документах для данной ситуации также можно воспользоваться преимуществом использования пространства имен "по-умолчанию".

- применяемый только в гомогенном пространстве имен и в пространстве имен типа "хамелеон"

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

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

Пример. Рассмотрим опять вышеприведенную XML-схему Company.xsd. Предположим, что она использует элемент ProductType из Product.xsd. Дополнительно, во время использования необходимо расширить элемент ProductType и включить в него элемент ID (идентификатор продукта). Приведем пример, как это можно сделать, используя элемент :

Теперь элемент В XML-документе должен содержать оба элемента и , то есть:

John Doe 123-45-6789 Widget 1001-01-00

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

Пространство имен "по-умолчанию" и проектный подход типа "хамелеон"

Если XML-схема предполагает использование елемнта в рамках проетного подхода типа "хамелеон" (используя схемы без определения targetNamespace), то главная схема должна объявлять пространство имен из targetNamespace также как пространство имен "по-умолчанию".

Как избежать коллизии имен при использовании подхода типа "хамелеон"

Коллизия имен

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

Предположим, существует две XML-схемы без указания targetNamespace:

1.xsd A B 2.xsd A C

XML-схема 1.xsd определяет элементы A и B без указания пространства имен.
XML-схема 2.xsd определяет элементы A и C без указания пространства имен.
Теперь, если XML-схема 3.xsd включает в себя () две указанные XML-схемы без указания пространства имен, возникает коллизия имен для элемента A, поскольку он объявлен два раза:

3.xsd targetNamespace="http://www.example.org"

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

Стандартным механизмом исключения коллизий имен как раз и является применение пространств имен. Если бы в приведенном выше примере компоненты XML-схем 1.xsd и 2.xsd находились бы в различных пространствах имен и они были бы импортированы в XML-схему 3.xsd, то коллизии имен не возникло. [Заметьте, что два компонента могут иметь одинаковое имя, если компоненты принадлежат различным пространствам имен.]

А как же разрешить проблему коллизии имен при использовании пространств имен типа "хамелеон"?

Решение проблемы коллизии имен с применением проксирующих XML-схем

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

Приведем пример демонстрирующий данный проектный подход:

1-proxy.xsd targetNamespace="http://www.1-proxy.org" 2-proxy.xsd targetNamespace="http://www.2-proxy.org" main.xsd targetNamespace="http://www.main.org"

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

Таким образом, данный проектный подход регламентирует трехступенчатый процесс:

• создать хамелеон-схемы;
• создать проксирующие XML-схемы для каждой хамелеон-схемы;
• импортировать () проксирующие XML-схемы в главную.

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

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

1-fixed.xsd targetNamespace="http://www.1-fixed.org" A B 2-fixed.xsd targetNamespace="http://www.2-fixed.org" A C main.xsd targetNamespace="http://www.main.org"

Двухступенчатый процесс дает тот же результат, что и трехступенчатый. В данном примере компоненты уже не являются "хамелеонами", и элементы A, B и C жестко привязанны к соответствующим пространствам имен с начала жизненного цикла компонентов. Обратная сторона данного подхода - если в main.xsd понадобится внести изменения в определения компонентов с использованием , то это будет невозможно. Кроме того, проектировщик главной XML-схемы вынужден использовать пространства имен, определенные кем-то другим. Эти компоненты являются статичными, неизменяемыми и с фиксированным пространством имен.

Средства, облегчающих использование хамелеон-компонентов

Описание проблемы идентификации хамелеон-компонентов

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

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

1.xsd A B

Далее мы определяем главную XML-схему main.xsd, которая включает () вспомогательную XML-схему "хамелеон" 1.xsd, а также сама содержит определение элемента с именем A (поскольку он находится в другом символьном окружении - внутри элемента , это не приведет к коллизии имен).

Main.xsd targetNamespace="http://www.example.org" ...

Предположим, в процессе трансформации нам необходимо четко идентифицировать хамелеон-компонент A, независимо от того, к какому пространству имен они, возможно, будут принадлежать в будущем. Как нам отличить хамелеон-компонент A от локально определенного в XML-схеме компонента A?

Идентификация хамелеон-компонентов

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

Вопрос: что произойдет, если из-за проблем сети, XML-процессор не сможет получить доступ к XML-схеме, содержащей необходимые определения?

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

Практика использования пространств имен XML в проектах

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

Теперь осталось ответить на главный вопрос: какой подход лучше, и в каком случае?

Если в проекте используется XML-схема, созданная и контролируемая кем-то другим, то необходимо использовать импортирование () данной XML-схемы, то есть использовать проектный подход с гетерогенным пространством имен. Копировать такие компоненты в пространство имен проекта - не очень удачная идея по двум причинам:

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

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

Используйте пространство имен типа "хамелеон":

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

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

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

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

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

Префиксы пространств имен XML. Примеры использования пространств имен в XML и XSLT

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

<префикс:элемент xmlns:префикс="URI"> ...

Как видно с примера, префиксы пространств имен задаются как атрибуты с именами, которые начинаются последовательностью xmlns. Если говорить об XSLT, то там чаще всего используется префикс xsl. На практике все это выглядит следующим образом.

...

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

...

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

any content ...

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

Any text ...

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

...

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

Any content Any content Any content Any content ...

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

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

Any content Any content Any content Any content ...

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

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