ПРОСТРАНСТВА ИМЕН И СХЕМЫ
Описанные в этой главе инструменты определения словарей XML — базовые правила оформления документов и DTD —содержатся в рекомендации W3C XML 1.0. Они являются основой XML и определяют основные возможности это¬го языка, позволяющие разработчикам приложений создавать языки разметки, описывая ими домены интересующих их проблем. Но часто, осваивая эти техно¬логии, особенно в области реальных приложений, мы испытываем потребность в дополнительной функциональности.
Перед тем как углубиться в эту главу, давайте рассмотрим некоторые недо¬статки доступных нам инструментов. После их краткого описания, разберем различные способы решения приведенных проблем. Некоторые из них вам уже знакомы, идентификация остальных поможет сэкономить время, затрачиваемое на поиски решения в сложных ситуациях.
Ранее мы описали некоторые недостатки определений DTD. В основном, они были связаны с тем, что синтаксис этих определений отличается от синтак¬сиса XML (конкретно, используется так называемая расширенная форма Бэкуса-Наура, Extended Backus Naur Form), и с тем, что эти определения выра¬зительны не в достаточной степени. Итак, сначала мы еще раз исследуем эти не¬достатки и рассмотрим способы их устранения. Это прольет свет и на другие проблемы, связанные с определением вашей собственной разметки.
Еще одна проблема, которая может быть поводом для беспокойства, — это то, что каждый пользователь может создавать свои собственные теги. Легко представить себе, что для обозначения различных вещей люди будут пользова¬ться одними и теми же именами элементов. Например, такой элемент, как mo¬nitor может иметь несколько значений, в зависимости от обстоятельств. Если вы пишете DTD для компьютерной периферии, то это понятие может означать экран, а в студии звукозаписи так часто называют микрофоны. В DTD для школы монитором можно назвать студента со специальными обязанностями, а на ядер¬ной силовой станции мониторы будут сообщать о сбоях в работе. Даже если значения элементов одинаковы, их возможное содержание может изменяться в зависимости от определения. Таким образом, нам необходим способ, позволяющий определять конкретные виды использования элемента, особенно, если в одном документе мы смешиваем различные виды словарей. Для решения проблемы консорциум W3C выпустил спецификацию, называемую XML Namespaces (пространством имен XML), позволяющую определить контекст элемента в пространстве имен.
Более того, существуют ситуации, когда нам необходимо скомбинировать документы XML из разных источников, соответствующих различным определениям DTD. Например, такая ситуация возникает при описании большого объема информации, если отдельных DTD недостаточно для охвата всего объема или они трудны для понимания. Возникает она и в системах электронной коммерции при попытках объединить данные вашего делового партнера с вашими. К сожалению, рекомендация XML не предоставляет способа совмещения нескольким DTD в одном документе без их модификации или создания нового DTD (используя внешние ссылки). По мере создания новых промышленных стандартных определений DTD увеличивается вероятность того, что кто-либо уже разработал DTD, относящееся к домену проблемы, решением которой вы занимаетесь. Если существующее DTD вам не подходит, то вместо того, чтобы создавать полностью новую версию, добавьте свои настройки к существующей, что позволит вам все-таки обмениваться некоторой информацией в стандартном формате. Однако, как мы уже показали, DTD не позволяет легко осуществить данную операцию.
Такие проблемы особенно заслуживают внимания, учитывая перспективы, открываемые языком XML в мире электронной коммерции, где различные пользователи и компании хотят использовать для обмена информацией знакомые друг другу форматы. Но "совместить" документы, прочитав DTD из кода, - непростая задача. Таким образом, нам необходимы способы поиска различий и сходств в конкурирующих словарях, которые помогут установить связь между ними.
Трудности при создании документа XML из нескольких источнике; каждый из которых записан в соответствии с различными определениями DTD или различными схемами, использующими одни и те же имена элементов, связаны со словарями данных — их построением и правилами.
В данной главе вы познакомитесь с двумя инструментами — пространствами имен и схемами XML. Пространства имен позволяют разработчикам XML разбивать сложную проблему на небольшие фрагменты и объединять несколько словарей в одном документе для полного ее описания. С помощью схем проектировщики словарей создают более точные определения, чем это было возможно в DTD, причем делают это, используя синтаксис XML.
Эти два инструмента помогают решать сложные задачи, возникающие при использовании XML. Пространства имен и схемы позволяют проектировщикам и программистам XML:
• Лучше организовывать словари для решения сложных проблем
• Сохранять сильную типизацию данных при преобразованиях в XML и из него
• Более точно и гибко описывать словари, чем это было возможно в случае DTD
• "Читать" правила словаря на языке XML, осуществляя доступ к его определениям без усложнения анализатора
Смешение словарей
Сегментация проблемы
При написании большой программы всегда есть смысл разбить глобальную проблему на несколько составных частей. Для этой цели языки программирования предлагают большое количество конструкций, в том числе модули, классы, компоненты, пакеты и функции. Проектирование словаря может представлять собой проблему приблизительно того же типа, что и написание программы. Необходимы способы сегментации большой проблемы на несколько словарей. Однако при этом настоящая проблема, которую мы должны решить, не связана с написанием индивидуальных определений DTD для нескольких словарей. Проблема заключается в интеграции этих отдельных DTD в теле одного документа.
Повторное использование
Описывая концепции окружающего нас мира, мы постоянно сталкиваемся с появлением общих конструкций. Помимо всего прочего, сложные конструкции создаются из простых строительных блоков — например цвет, форма, цена и размерность,— а эти простые компоненты определяются достаточно часто, так что неизбежно возникает множество имен элементов, для которых уже существуют определения и модели содержания.
Если вы или кто-либо другой уже создавали использующее эти элементы определение DTD, ваша задача сильно упростится, если вы сможете взять их оттуда (возможно, будет доступен даже код для обработки таких конструкций). В этом и заключается концепция повторного использования.
Если вы работаете на корпорацию, возможно, в ней уже существует набор определений DTD. Их использование существенно облегчит вашу работу, потому что они описывают проблему так, как ее понимают другие.
Если вы разрабатываете приложение, которое должно связываться с программами внешнего партнера, вам, практически, ничего не остается, кроме повторного использования существующих концепций. Имеющиеся определения DTD составляют общепринятый язык, на котором надо говорить, чтобы быть понятым. Если концепция уже существует, надо работать так, чтобы быть понятым в терминах этой концепции. Пользователи существующих определений предприняли много усилий, чтобы разработать и реализовать их.
Неясность и коллизии имен
Когда вы используете полезные для вас определения из DTD других разработчиков или комбинируете сегментированные DTD для создания документа, описывающего сложную проблему, если в ваших документах используются элементы с одинаковыми именами, вы рискуете столкнуться с проблемой неясности и коллизии имен.
Проблема еще больше обостряется при использовании экземпляров имен из нескольких DTD. В этом случае мы не знаем, какой элемент, на какое определение DTD ссылается, какая проблема правильно оформленных документов называется неясностью (ambiguity). Более того, если имена из документа требуют проверки допустимости, мы можем очень сильно "запутать" наше приложение. Это называется проблемой коллизии имен (name collision).
Пространства имен
Пространства имен (namespaces) XML являются решением проблемы неясности и коллизии имен.
Пространство имен представляет собой коллекцию имен, идентифицируемых по ссылке URI, которые используются документам XML в качестве имен типов элементов и атрибутов.
Иными словами, пространство имен представляет собой коллекцию имен, имеющую структуру. Это напоминает определение DTD, и, действительно, такое определение может быть пространством имен. Значит, в качестве URI можно использовать адрес DTD на вашем сервере.
Однако идентификатор URI не должен быть адресом URL (если вы не знаете, в чем заключается различие между ними, вскоре мы кратко опишем его). В данном случае пространство имен ссылается на имена, используемые в определении PubCatalog.dtd. Таким образом, если мы каким-либо способом связываем элемент Book с этим пространством имен, то любая ссылка на него в документе означает его использование.
Если DTD явным образом определяет структуру всего документа, пространство имен — ресурс, из которого можно извлекать необходимые нам определения. Это означает, что пространство имен не должно быть формальным описанием структуры, как DTD, и ограниченная область действия такого определения делает пространства имен широко применимыми в языке XML. Если пространство имен представляет собой DTD или схему, используемые нами определения должны быть согласованы с описанными в них структурой и синтаксисом. Мы можем, однако, использовать только те имена, которые хотим, а также применять пространства имен как способ различения видов использования элементов.
Итак, для того чтобы эффективно использовать пространства имен в документе, комбинирующем элементы из различных источников, нам надо определить:
• Ссылку на URI, описывающий использование элемента.
• Псевдоним, позволяющий понять, из какого пространства имен взят наш элемент. Этот псевдоним имеет форму префикса элемента (например, если псевдонимом для неясного элемента Book является слово catalog, то, элемент будет называться <catalog: Book>).
Использование и декларация пространств имен
Описав преимущества использования пространств имен в языке XML, рассмотрим теперь, как конкретно можно их использовать. Начнем мы с изучения методов декларации пространств имен в документе, затем опишем, каким образом их можно использовать.
Обычно простые описательные свойства часто моделируются в виде атрибутов, и пространства имен, фактически, декларируются в языке XML. Однако, с этим связаны некоторые проблемы, так что мы поэтапно рассмотрим, что именно можно определить, декларируя пространство имен в документе XML.