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. Напротив, тип элемента comment, string, не имеет префикса. Схема 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 является дочерним от элемента complexType, который определяет PurchaseOrderType.

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

 

Используются технологии uCoz