3.1 Целевое пространство имен и неквалифицированные локальные элементы и атрибуты

В новой версии схемы заказа на покупку, po1.xsd, мы явно объявим целевое пространство имен и определим, что локально заданные элементы и атрибуты должны быть не квалифицированными. Целевым пространством имен в po1.xsd является http://www.example.com/PO1. Это указано в значении атрибута targetNamespace.

Квалификация локальных элементов и атрибутов глобально задается парой атрибутов elementFormDefault и attributeFormDefault в элементе schema. Также она может быть определена отдельно для каждого локального объявления, посредством атрибута form. Значения представленных атрибутов  могут быть установлены unqualified или qualified, что дает возможность задать локально объявленным элементам и атрибутам наличие или отсутствие.

В po1.xsd мы глобально определим квалификацию элементов и атрибутов, устанавливая значения elementFormDefault  и attributeFormDefault как  unqualified. В принципе, устанавливать их значения не требуется, поскольку данные значения соответствуют значениям по умолчанию для этих атрибутов. Мы приводим их здесь лишь для того, чтобы выделить различия между данным и другими случаями, которые опишем позже.

Схема заказа на покупку с целевым пространством имен, po1.xsd

<schema xmlns=”http://www.w3.org/2001/XMLSchema”
         xmlns:po=”http://www.example.com/PO1”
         targetNamespace=”http://www.example.com/PO1”
         elementFormDefault=”unqualified”
		 attributeFormDefault=”unqualified”>

 <element name=”purchaseOrder” type=”po:PurchaseOrderType”/>
 <element name=”comment”       type=”string”/>

 <complexType name=”PurchaseOrderType”>
  <sequence>
   <element name=”shipTo” type=”po:USAddress”/> 
   <element name=”billTo” type=”po:USAddress”/> 
   <element ref=”po:comment” minOccurs=”0”/>
   <!-- etc. -->
  </sequence>
  <!-- etc. -->
 </complexType>

 <complexType name=”USAddress”>
  <sequence>
   <element name=”name” type=”string”/>
   <element name=”street” type=”string”/>
   <!-- etc. -->
  </sequence>
 </complexType>

 <!-- etc. -->

</schema>

Для того, чтобы увидеть, как целевое пространство имен этой схемы заполняется, мы исследуем каждое объявление и определений типа элементов. Начнем с конца схемы. Во-первых, определим тип с именем USAddress. Он состоит из элементов name, street и т.д. Следствие такого определения типов состоит в том, что тип USAddress включен в целевое пространство имен схемы. Далее, мы определяем тип с именем PurchaseOrderType. Он состоит из элементов shipTo, billTo, comment и т.д. PurchaseOrderType также включен в целевое пространство имен схемы. Обратите внимание, что ссылки типов в объявлениях трех элементов имеют префикс (po:USAddress, po:USAddress и po:comment), а префикс связан с пространством имен http://www.example.com/PO1. Это тоже самое пространство имен, что  и целевое пространство имен схемы. Таким образом обработчик схемы будет знать, что в пределах данной схемы стоит за определением типа USAddress и объявлением элемента comment. Аналогичным образом можно обратиться к типам в другой схеме с иным целевым пространством имен. Следовательно, имеется возможность повторного использования определений и объявлений между схемами.

В начале схемы po1.xsd, мы объявляем элементы purchaseOrder и comment. Они включены в целевое пространство имен схемы. Для элемента типа purchaseOrder префикс установлен точно так же, как и для USAddress. Напротив, тип string элемента comment не имеет префикса. Схема po1.xsd содержит объявление пространства имен по умолчанию http://www.w3.org/2001/XMLSchema. Поэтому такие типы как string и элементы element и complexType, которые связаны с этим же пространством имен не имеют префиксов. Фактически, это самостоятельное целевое пространство имен XML Schema, и обработчик po1.xsd будет видеть его принадлежащим  схемы XML Schema. Другими словами, это «схема для схем», которая используется для определения типа string и объявление элемента с именем element.

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

Заказ на покупку с неквалифицированными локальными элементами и атрибутами, po1.xml

<?xml version=”1.0”?>
<apo:purchaseOrder xmlns:apo=”http://www.example.com/PO1”
             orderDate=”1999-10-20”>
  <shipTo country=”US”>
    <name>Alice Smith</name>
    <street>123 Maple Street</street>
    <!-- etc. -->
  </shipTo>
  <billTo country=”US”>
    <name>Robert Smith</name>
    <street>8 Oak Avenue</street>
    <!-- etc. -->
  </billTo>
  <apo:comment>Hurry, my lawn is going wild!</apo:comment>
  <!-- etc -->
</apo:purchaseOrder>

В экземпляре документа объявлено одно пространство имен http://www.example.com/PO1, которое связано с префиксом apo:. Этот префикс используется для квалификации двух элементов в документе, а именно purchaseOrder и comment. Пространство имен то же самое, что и целевое пространство имен схемы в po1.xsd. Поэтому обработчик документа будет знать, что смотреть в схеме при объявлении purchaseOrder и comment. Фактически, целевое пространство имен названо точно так же, поскольку оно находится в том же целевом пространстве имен, что и элементы purchaseOrder и comment. Следовательно, целевые пространства имен в схеме управляют проверкой правильности соответствующих пространств имен в примере.

Префикс apo: применен к глобальным элементам purchaseOrder и comment. Кроме того, elementFormDefault и attributeFormDefault требуют, чтобы префикс не применялся ни к каким локально объявленным элементам, таким как shipTo, billTo, name и street, а также не  применялся ни к каким атрибутам (которые были объявлены локально). purchaseOrder и comment это  глобальные элементы, т.к. они объявлены в контексте схемы в целом, а не в пределах контекста определенного типа. Объявление purchaseOrder является дочерним от элемента schema  в po1.xsd, тогда как объявление shipTo является дочерним от элементаPurchaseOrderType.

Когда не требуется, чтобы локальные элементы и атрибуты были квалифицированными, автор экземпляра документа может требовать определенного знания о деталях схемы, чтобы создать схему, соответствующую экземплярам документов. Более точно, если автор уверен, что только корневой элемент (такой как purchaseOrder) является глобальным, то просто квалифицирует только корневой элемент. Возможно, автор может знать, что все элементы объявлены глобально. Следовательно, все элементы в экземпляре документа должны иметь префикс. При этом можно использовать преимущество объявления пространства имен по умолчанию. (Мы рассмотрим этот подход в Разделе 3.3.) С другой стороны, если нет никакого единообразного шаблона глобальных и локальных объявлений, автор будет нуждаться в детальном знании схемы для применения корректных префиксов к глобальным элементам и атрибутам.