XML Schema 1.1: Часть 2. Введение

Использование совместных ограничений с помошью XPath 2.0

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

Нил Делима, разработчик, IBM

Нил Делима (Neil Delima) является штатным разработчиком в лаборатории IBM в Торонто. У него есть более чем семилетний опыт создания и тестирования XML-технологий в качестве члена команды разработчиков XML-процессоров. Он участвует в проекте Apache Xerces (создание XML-процессора на Java). Кроме того, он внес свой вклад в формирование наборов тестов W3C DOM и XML 1.1.



Сэнди Гао, разработчик, IBM

Сэнди (Шуди) Гао (Sandy (Shudi) Gao) является разработчиком программного обеспечения в лаборатории IBM в Торонто. Он участвует в проекте Apache Xerces c 2001 года, причем его вклад в поддержку XML Schema в Xerces был одним из ключевых. Сэнди принимает участие в рабочей группе XML Schema в W3C от имени IBM с 2003 года. Он внес весомый вклад в создание XML Schema 1.1 и является одним из редакторов спецификации, выпущенной в 2006 году. Кроме того, он представляет IBM в рабочей группе W3C SML.



Майкл Главассевич, разработчик, IBM

Майкл Главассевич (Michael Glavassevich) является членом группы разработки XML-парсеров в лаборатории IBM в Торонто. Последние пять лет он также является одним из основных разработчиков проекта Apache Xerces 2, одновременно работая над реализацией XML Schema, XInclude, JAXP 1.3/1.4 и DOM Level 3. Майкл представляет IBM в экспертной группе JAXP, которая разработала JAXP 1.4.



Халед Ноумен, разработчик, IBM

Халед Ноумен (Khaled Noaman) является членом группы разработки XML-парсеров в лаборатории IBM в Торонто. Он принимал участие в создании С++-парсера Apache Xerces на протяжении более чем пяти лет, за которые он реализовал многие возможности для поддержки конструкций XML Schema.



26.05.2010

Введение

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

Часто используемые аббревиатуры

  • DOM: объектная модель документа
  • HTML: язык разметки гипертекста
  • W3C: консорциум World Wide Web
  • XDM: модель данных XPath 2.0
  • XML: расширяемый язык разметки
  • XSLT: расширяемый язык стилевых преобразований

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

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

Немного истории

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

К сожалению, в XML Schema 1.0 невозможно описать подобные правила, поэтому приходится использовать один из следующих вариантов:

  • выполнять эти проверки в коде приложения, после валидации документа по схеме XML;
  • использовать стилевые страницы (также после валидации по схеме);
  • использовать альтернативный язык XML-схем, такой как RelaxNG или Schematron.

Призывы к появлению механизма для проверки совместных ограничений постоянно раздавались в сообществе XML Schema 1.0, поэтому рабочая группа по созданию XML Schema 1.1 предложила понятие контролирующих инструкций (assertions) и альтернативных типов (type alternatives) в XML Schema 1.1, чтобы позволить авторам схем описывать такие ограничения.

Контролирующие инструкции

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

Сценарии использования

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

  1. Описание правил, накладывающих ограничения на основе значений двух или более атрибутов. Для фрагмента XML, приведенного в листинге 1, можно задать правило на основе атрибутов width и height, говорящее о том, что высота (height) не может быть больше ширины (width).
    Листинг 1. Пример фрагмента XML, содержащего один элемент и два атрибута
    <dimension width="10" height="5"/>
  2. Описание правил, накладывающих ограничения на отношения между элементами и значениями атрибутов. В листинге 2 приведен пример элемента, имеющего один атрибут и два дочерних элемента. В этом случае можно сформулировать правило, говорящее о том, что значение атрибута должно быть равно числу дочерних элементов.
    Листинг 2. Пример элемента с одним атрибутом и двумя дочерними элементами
    <parent children="2">
      <child name="one"/>
      <child name="two"/>
    </parent>
  3. Описание правил, регламентирующих условия выбора атрибутов. Например, для элемента timer, показанного в листинге 3, можно задать правило, запрещающее одновременное наличие атрибутов time и iterations.
    Листинг 3. Элемент timer
    <timer time="30" iterations="2000"/>
  4. Описание правил объединения элементов и атрибутов в модель. Например, сформулировать правило, согласно которому содержимым элемента parent (листинг 4) должен являться либо элемент child, либо grandchild, причем оба элемента должны включать атрибуты name и dob.
    Листинг 4. Элемент parent
    <parent>
      <child name="abc" dob="1/1/1997"/>
      <grandchild name="xyz" dob="1/1/2007"/>
    </parent>
  5. Описание правил, накладывающих ограничения на текст внутри элементов с разнородным содержимым. Примером такого элемента может служить элемент parent в листинге 5. Для него можно задать правило, ограничивающее длину его текстового содержимого десятью символами.
    Листинг 5. Элемент parent с разнородным содержимым
    <parent>2 children
      <child>abc</child>
      <child>xyz</child>
    </parent>

Для решения этих и других задач можно воспользоваться контролирующими инструкциями, поддерживаемыми в XML Schema 1.1. Они напоминают инструкции, предлагаемые в других языках описания схем, например Schematron и RelaxNG.

На момент написания этой статьи контролирующие инструкции можно было использовать для простых и сложных типов. Частью инструкций, относящихся к определенному типу, является предикат, представляющий собой выражение XPath.

Контролирующие инструкции в сложных типах

В XML Schema 1.1 определения сложных типов могут включать набор контролирующих инструкций, представляющий собой последовательность дочерних элементов <xs:assert>, причем порядок следования этих элементов роли не играет. Данные инструкции накладывают ограничения на существование элементов, атрибутов, а также на их значения. Каждый элемент <xs:assert> содержит атрибуты test, значением которого является выражение XPath, и annotations.

Результатом вычисления выражения XPath, являющегося значением атрибута test элемента xs:assert, должно быть либо true, либо false. В выражениях можно использовать специальную переменную $value для ссылки на содержимое проверяемого элемента или атрибута. Вычисление выражений осуществляется в контексте родительской вершины. Сами выражения должны быть корректными в соответствии со спецификацией XPath 2.0 или, по крайней мере, соответствовать минимальному подмножеству XPath, определенному в спецификации XML Schema 1.1.

Если заданное выражение XPath оказывается некорректным, то выдается ошибка типа xpath-valid. Если некорректно задан элемент xs:assert, то процессор просигнализирует об ошибке типа as-props-correct. В том случае, если результатом вычисления выражения является true, причем в процессе вычисления не возникает динамических ошибок или ошибок типизации, то элемент считается локально-корректным. Если же результатом является false, то выдается ошибка общего типа cvc-assertion.

В листинге 6 приведен пример сложного типа с контролирующей инструкцией, ограничивающей значения двух атрибутов. Выражение в инструкции равно true, если значение атрибута height меньше, чем значение атрибута width. В противном случае результатом будет false.

Листинг 6. Инструкция, контролирующая соотношение @height < @width для сложного типа
<xs:element name="dimension">
  <xs:complexType>
    <xs:attribute name="height" type="xs:int"/>
    <xs:attribute name="width" type="xs:int"/>
    <xs:assert test="@height < @width"/>
  </xs:complexType>
</xs:element>

В примере, приведенном выше, элемент xs:assert находится непосредственно внутри xs:complexType. При определении нового типа с простым или сложным содержимым (xs:simpleContent или xs:complexContent соответственно) элемент xs:assert можно было бы поместить внутрь xs:restriction или xs:extension. Для того чтобы элемент был признан корректным, выражения во всех контролирующих инструкциях должны быть истинными. При этом проверяются выражения, определенные как в самом сложном типе, так и в его родительских типах.

В листинге 7 определены два сложных типа - baseType и derivedType, каждый со своей контролирующей инструкцией. Инструкция в типе baseType контролирует наличие в элементе атрибута mustUnderstand. Инструкция в типе derivedType контролирует, что значением данного атрибута является YES в том случае, если присутствует хотя бы один дочерний элемент body, в противном случае значением атрибута должно быть NO. Таким образом, к типу derivedType относятся две контролирующие инструкции: своя собственная и определенная в родительском типе baseType. Следовательно, элемент message будет признан корректным только в том случае, если его содержимое будет удовлетворять определению complexType, а также если выражения обеих контролирующих инструкций будут истинными.

Листинг 7. Пример контролирующей инструкции в сложном типе со сложной моделью содержимого
<xs:complexType name="baseType">
  <xs:sequence>
   <xs:element name="body" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="mustUnderstand" type="xs:string"/>
  <xs:assert test="@mustUnderstand"/>
</xs:complexType>

<xs:complexType name="derivedType">
  <xs:complexContent>
    <xs:restriction base="baseType">
      <xs:sequence>
        <xs:element name="body" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="mustUnderstand" type="xs:string"/>
      <xs:assert test="( @mustUnderstand eq 'YES' and fn:count(./body) > 0 )
                       or ( @mustUnderstand eq 'NO' )"/>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

<xs:element name="message" type="derivedType"/>

При определении сложного типа с простой моделью содержимого можно задавать два типа контролирующих инструкций. Инструкции первого типа работают как свойства (facets) и накладывают ограничения на тип простого содержимого (например, можно указать, что значение должно быть кратно 7). Инструкции второго типа относятся ко всему элементу в целом, включая его атрибуты. С точки зрения синтаксиса модели элементов xs:simpleContent/xs:restriction эти типы инструкций неразличимы, поэтому для инструкций второго типа был добавлен новый элемент xs:assertion. Он будет обсуждаться в следующем разделе, посвященном контролирующим инструкциям в простых типах.

Контролирующие инструкции в простых типах

В XML Schema 1.1 определения простых типов, подобно сложным, могут содержать инструкции xs:assertion внутри элементов xs:restriction, дочерних по отношению к xs:simpleType. Контролирующие инструкции в простых типах похожи на ограничивающие свойства. Набор таких инструкций аналогичен множеству ограничивающих свойств, которые сужают область допустимых значений простого типа, накладывая на них ограничения при помощи выражений XPath, содержащихся в атрибуте test.

Как и в случае со сложными типами, инструкции представляют собой упорядоченную последовательность элементов xs:assertion внутри определения типа. Порядок следования инструкции значения не имеет, поскольку элемент или атрибут признается корректным, только если все выражения во всех инструкциях являются истинными. Набор контролирующих инструкций для простого типа включает в себя как собственные инструкции, так и инструкции, определенные в родительском типе.

Значением атрибута test элемента xs:assertion является выражение на языке XPath 2.0 или его подмножестве, определенном в спецификации XML Schema 1.1. Значением этих выражений может быть либо true, либо false. Вычисление выражения производится в контексте родительской вершины. Элемент или атрибут считается корректным, только если он удовлетворяет всем контролирующим инструкциям (другими словами, все выражения в атрибутах test в каждом элементе xs:assertion являются истинными и не происходит динамических ошибок, а также ошибок типизации).

В листинге 8 приведен пример элемента с простым содержимым, для которого определена контролирующая инструкция, проверяющая, что значение элемента кратно 10.

Листинг 8. Пример элемента с простой моделью содержимого, значениями которого могут быть только числа, кратные 10
<xs:element name="message">
 <xs:simpleType>
   <xs:restriction base="xs:int">
     <xs:assertion test="($value mod 10) = 0"/>
  </xs:restriction>
 </xs:simpleType>
</xs:element>

Значение элемента простого производного типа, полученного путем ограничения другого простого типа, считается корректным, если оно удовлетворяет всем ограничивающим свойствам производного типа, а также всем контролирующим инструкциям производного и базового типов. Строковое значение в листинге 9 корректно только в том случае, если оно содержит от 3 до 25 символов и заканчивается на "xyz".

Листинг 9. Контролирующие инструкции в определении производного типа
<xs:simpleType name="base">
  <xs:restriction base="xs:string">
    <xs:maxLength value="25"/>
    <xs:assertion test="fn:ends-with($value, 'xyz')"/>
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name="derived">
  <xs:restriction base="base">
    <xs:assertion test="fn:string-length($value) > 3 "/>
  </xs:restriction>
</xs:simpleType>

Формирование сообщений об ошибках

Как упоминалось выше, в контролирующих инструкциях XML Schema 1.1 могут использоваться любые выражения XPath 2.0. Подобные выражения могут быть сколь угодно сложными, поэтому очень важно формировать понятные сообщения об ошибке при отрицательном результате проверки.

Коды ошибок схем

В соответствии со спецификацией схемы необходимо выдавать код ошибки, описывающий нарушенное ограничение. Например, код ошибки cvc-attribute.3 указывает на то, что нарушено ограничение локальной корректности атрибута (Attribute Locally Valid). Другими словами, значение атрибута является некорректным по отношению к его типу.

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

Подход, принятый в Schematron

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

Листинг 10. Пример правила в Schematron
<report test="@min > @max">
  On element "<sch:value-of select="local-name(.)"/>", value of the
  "min" attribute "<sch:value-of select="@min"/>" can not be greater
  than that of the "max" attribute "<sch:value-of select="@max"/>".
</report>

Фрагмент XML, приведенный в листинге 11, нарушает это правило.

Листинг 11. Фрагмент XML, нарушающий правило в листинге 10
<range min="30" max="10"/>

В результате будет выдано сообщение: On element "range", value of the "min" attribute "30" can not be greater than that of the "max" attribute "10" (значение 30 атрибута "min" в элементе "range" не может превышать значение атрибута "max", равное 10).

Этот подход обладает важными преимуществами:

  1. Он позволяет ассоциировать удобочитаемые сообщения об ошибках с правилами проверки, что облегчает поиск ошибок.
  2. В сообщениях можно также использовать XPath для доступа к проверяемым данным, чтобы предоставить больше информации о причинах нарушения правила. В примере, приведенном выше, значения range, 30 и 10 получены динамически и могут варьироваться в зависимости от элемента.

Поддержка локализации

Правила проверки могут применяться в системах, использующих разные местные настройки, поэтому пользователи будут ожидать сообщений на соответствующих языках. Для локализации сообщений в Schematron используются атрибуты diagnostics и xml:lang. Пример приведен в листинге 12.

Листинг 12. Пример локализованного сообщения в Schematron
<sch:pattern>
  <sch:rule context="person">
    <sch:assert test="name" diagnostics="d1 d2">
      A person must have a name.
    </sch:assert>
  </sch:rule>
</sch:pattern>

<sch:diagnostics>
  <sch:diagnostic id="d1" xml:lang="en">
    A person must have a name.
  </sch:diagnostic>
  <sch:diagnostic id="d2" xml:lang="fr">
    Une personne doit avoir un nom.
  </sch:diagnostic>
</sch:diagnostics>

Процессоры Schematron могут выбирать нужный элемент diagnostic в зависимости от требуемого языка.

Подход, принятый в SML

У подхода, реализованного в Schematron, есть недостатки с точки зрения локализации. В частности, правила должны обновляться при добавлении новых языков. При этом необходимо добавлять как новый элемент diagnostic, так и новый идентификатор в атрибут diagnostics.

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

Язык моделирования сервисов (Service Modeling Language – SML) использует Schematron в качестве одного из механизмов валидации. В этом языке было введено понятие идентификатора местоположения (location ID, см. листинг 13), позволяющее использовать стратегии управления ресурсами, в частности ту, которая применяется в средах Java.

Листинг 13. Пример использования идентификатора местоположения (location ID) в SML
<sch:assert test="name" sml:locid="person:nameRequired">
  A person must have a name.
</sch:assert>

Типом атрибута locid является QName. Его пространство имен может использоваться для поиска пакета свойств (в котором могут, в частности, содержаться все сообщения об ошибках, относящихся к конкретному человеку), а локальное имя – для идентификации сообщения, которое должно быть показано при нарушении соответствующего правила. В листингах 14 и 15 показаны примеры сообщений на английском и французском языках.

Листинг 14. Пример сообщения на английском
nameRequired = A person must have a name.
Листинг 15. Пример сообщения на французском
nameRequired = Une personne doit avoir un nom.

Формирование сообщений об ошибках для контролирующих инструкций

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

Листинг 16. Формирование сообщений об ошибках при помощи аннотаций
<xs:complexType name="rangeType">
  <xs:attribute name="min" type="xs:int"/>
  <xs:attribute name="max" type="xs:int"/>
  <xs:assert test="@min <= @max">
    <xs:annotation>
      <xs:appinfo>
        Value of the "min" attribute can not be greater than that of the "max"
        attribute.
      </xs:appinfo>
      <xs:documentation>
        When this assertion fails, the content of the above "appinfo" is used
        to produce the error message.
      </xs:documentation>
    </xs:annotation>
  </xs:assert>
</xs:complexType>

Альтернативные типы

В XML Schema 1.1. появился механизм альтернативных типов, позволяющий авторам схем указывать варианты замены типа при объявлении элемента.

Взгляд на условное присвоение типа

В XML Schema 1.0 в качестве механизма подстановки типа использовался xsi:type. Этот элемент указывался непосредственно в узле документа данных с целью замены объявленного типа на его производный тип. Этот механизм работает хорошо, если словарь типов элементов XML проектируется специально для использования вместе со схемой и требуется, чтобы экземпляры типов, определенных словарем, использовали xsi:type для подстановки типов. Однако если приходится создавать схему XML для словаря, в котором используется собственный подход к подстановке типов, то xsi:type работать не будет. В этом случае типы элементов выбираются в соответствии с исходным механизмом. Одним из таких примеров является формат синдицирования Atom, представляющий собой XML-язык для описания новостных Web-лент.

В Atom элементы c текстовым содержимым могут включать атрибут type. Если он присутствует, то его значением должна быть строка text, html или xhtml, определяющая тип содержимого элемента. Поскольку значением атрибута не является xsi:type, невозможно создать схему, описывающую Atom средствами XML Schema 1.0. Кроме того, сложные условия выбора типа элемента, например @height < @width (сравнение значений двух атрибутов), также нельзя реализовать при помощи xsi:type.

Механизм альтернативных типов был создан с целью устранения недостатков xsi:type. Он позволяет авторам схем указывать варианты подстановки типа при объявлении элементов. При этом тип выбирается в результате вычисления выражения XPath. В следующем разделе использование данного механизма будет продемонстрировано на примере ленты Atom.

Механизм альтернативных типов

Объявления элементов в XML Schema 1.1 могут включать таблицу типов, содержащую последовательность альтернативных типов, а также определение типа по умолчанию (который также является альтернативным типом). В схемах альтернативные типы представлены в виде элементов xs:alternative внутри объявления самого элемента. Каждый из них содержит атрибут test, содержащий выражение XPath, определение типа и атрибут annotations.

Значением атрибута test элемента xs:alternative является выражение XPath, результатом вычисления которого может быть true или false. Подобные выражения ограничены подмножеством XPath, а именно, в них можно использовать только оси для выборки атрибутов. Другими словами, в каждом выражении можно получить доступ только к атрибутам текущего элемента. Необходимо отметить, что модель данных XDM, создаваемая для вычисления выражения, не включает никакую информацию о типе. Это было сделано для того, чтобы избежать ситуации, при которой процессору схем пришлось бы каким-то образом угадать типы атрибутов для того, чтобы определить тип элемента. Таким образом, типы атрибутов неизвестны до момента определения типа элемента.

В последнем элементе xs:alternative можно не указывать атрибут test. Если такой элемент присутствует, то этот тип является типом по умолчанию. Если же такого xs:alternative нет, то типом по умолчанию считается тип, заданный в самом элементе.

Значение атрибута type в элементах xs:alternative задает определение альтернативного типа в схеме. Если выражение XPath является истинным, то данный альтернативный тип выбирается вместо типа, объявленного в самом элементе. Альтернативный тип должен быть либо производным по отношению к объявленному, либо равняться специальному простому типу xs:error, у которого не может быть корректных экземпляров. Тип xs:error может использоваться для того, чтобы отметить элементы, удовлетворяющие определенному условию как некорректные.

Если объявление элемента включает альтернативные типы, то они вычисляются в порядке их следования в схеме. При этом выбирается первый из типов, чье выражение XPath оказалось истинным. Если таковых нет, то в качестве типа элемента выбирается тип по умолчанию.

Теперь, когда вы узнали о том, как работает механизм альтернативных типов, обратите внимание на пример в листинге 17, в котором он используется в схеме для Atom. Как было упомянуто в предыдущем разделе, элементы, содержащие текстовые конструкции, могут включать атрибут type, в котором задается формат содержимого. Во фрагменте ниже показан пример объявления элемента title в Atom.

Листинг 17. Пример использования альтернативных типов в XML Schema
<xs:element name="title" type="xs:anyType">
  <xs:alternative test="@type='text'" type="xs:string"/>
  <xs:alternative test="@type='html'" type="htmlContentType"/>
  <xs:alternative test="@type='xhtml'" type="xhtmlContentType"/>
  <xs:alternative test="@type" type="xs:error"/>
  <xs:alternative type="xs:string"/>
</xs:element>

Объявление элемента title имеет базовый тип xs:anyType, а также включает пять альтернативных типов. Их условия проверяются в порядке их перечисления, пока одно из них не окажется истинным (если все окажутся ложными, то будет выбран тип по умолчанию). Выражения в первых трех альтернативных типах проверяют значение атрибута type (text, html или xhtml). Если ни одно из них не соответствует атрибуту type, то результатом всех трех первых выражений XPath будет false. Выражение в последнем альтернативном типе проверяет наличие атрибута type. Если процессор схем дошел до этого места (и атрибут type присутствует), то это означает, что используется неразрешенный спецификацией Atom тип. В этом случае для элемента выбирается тип xs:error, чтобы просигнализировать о его некорректности. Если же ни одно из выражений XPath не окажется истинным, то для элемента выбирается тип по умолчанию, т.е. xs:string.

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

Листинг 18. Фрагмент документа XML, для которого применяется механизм альтернативных типов
<!-- Выбирается первый альтернативный тип: xs:string -->
<title type="text">My News</title>

<!-- Выбирается третий альтернативный тип: xhtmlContentType -->
<title type="xhtml" xmlns:xhtml="http://www.w3.org/1999/xhtml">My
 <xhtml:em>News</xhtml:em>!</title>

<!-- Выбирается тип по умолчанию: xs:string -->
<title>My News</title>

<!-- Выбирается четвертый альтернативный тип: xs:error. Данный элемент некорректен. -->
<title type="unknown">Oops! Error.</title>

Заключение

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

Ресурсы

Научиться

  • Оригинал статьи: "XML Schema 1.1, Part 2: An Introduction to XML Schema 1.1" (Нил Делима, Сэнди Гао, Майкл Главассевич, Халед Ноумен, developerWorks, январь 2009 г.).(EN)
  • Прочитайте первую статью серии: "XML Schema 1.1, часть 1: введение" (Нил Делима, Сэнди Гао, Майкл Главассевич, Халед Ноумен, developerWorks, декабрь 2008 г.), в которой приводится обзор наиболее важных усовершенствований по сравнению с XML Schema 1.0, а также подробное рассмотрение типов данных.
  • Спецификация XML 1.0: прочитайте о XML, в частности о том, как с его помощью можно передавать, получать и обрабатывать документы SGML в Web. (EN)
  • XML Schema, часть 1: Структуры (вторая редакция): узнайте больше о языке XML Schema, стандартизированном W3C, в частности о том, как в нем описываются структуры и ограничения на содержимое документов XML 1.0, в том числе тех, в которых используются средства XML для работы с пространствами имен. В данной части спецификации используется материал из второй части под названием "XML Schema, часть 2: Типы данных". (EN)
  • XML Schema, часть 2: Типы данных (вторая редакция): получите всю необходимую информацию о типах данных, используемых в языке XML Schema. (EN)
  • Язык определения XML Schema от W3C (XSD) 1.1, часть 1: Структуры: ознакомьтесь с последней версией спецификации языка XML Schema, стандартизованного W3C. (EN)
  • Язык определения XML Schema от W3C (XSD) 1.1, часть 1: Типы данных: получите дополнительную информацию о новых типах данных, которые появились в языке XML Schema. (EN)
  • XQuery 1.0: узнайте больше о языке XML Query, который позволяет писать запросы к любым данным, хранящимся в формате XML. (EN)
  • Язык XML Path 2.0: узнайте больше о языке XPath. (EN)
  • Узнайте больше о моделировании сложных систем и сервисов при помощи языка SML (Service Modeling Language). (EN)
  • Преобразования XSL (XSLT) 2.0: ознакомьтесь со спецификацией, описывающей синтаксис и семантику языка XSLT 2.0. (EN)
  • Модель данных XQuery 1.0 и XPath 2.0 (XDM): прочитайте спецификацию W3C, в которой описывается модель данных в языках XPath 2.0, XSLT 2.0 и XQuery. (EN)
  • Получите дополнительную информацию о формате синдицирования Atom, служащем для распространения Web-контента и метаданных в формате XML. (EN)
  • Прочитайте о языке Schematron, который позволяет устанавливать ограничения на присутствие или отсутствие определенных образцов (паттернов) в документах XML. (EN)
  • Познакомьтесь с RELAX NG – еще одним языком описания XML-схем. (EN)
  • Сертификация по XML корпорации IBM: узнайте, как стать сертифицированным разработчиком IBM в области XML и связанных с ним технологий. (EN)
  • Технические мероприятия и Web-трансляции developerWorks: в этих разделах можно получить самую актуальную информацию о современных технологиях. (EN)
  • Обратитесь к магазину технической литературы, в котором представлены книги на данную и другие темы. (EN)
  • Трансляции developerWorks: слушайте интересные интервью и обсуждения вопросов, актуальных для разработчиков программного обеспечения. (EN)

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=XML
ArticleID=492205
ArticleTitle=XML Schema 1.1: Часть 2. Введение
publish-date=05262010