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

Обзор наиболее важных усовершенствований по сравнению с XML Schema 1.0, а также подробное рассмотрение типов данных

Язык XML Schema получил широкое распространение в самых разных задачах, что, в частности, привело к большому числу запросов на тему новых возможностей. Наиболее популярные из них были реализованы в новом стандарте XML Schema 1.1, разработанном рабочей группой в W3C. В новой версии языка также устранены некоторые недостатки XML Schema 1.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 обсуждаются с 2001 года, когда этот язык стал официальной рекомендацией W3C. После этого рабочая группа W3C начала работать над следующей версией XML Schema. В 2005 году, после того как он получил широкое распространение и был интегрирован с другими стандартизованными языками, в частности XSLT, XQuery и WSDL, W3С организовала специальный семинар для обсуждения стандарта и получения достаточного числа отзывов от пользователей, которые должны были определить путь его дальнейшей эволюции. Благодаря этому семинару, а также другим запросам, сформулированным представителями XML-сообщества, был определен круг возможностей XML Schema 1.1.

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

  • W3C: Консорциум World Wide Web
  • WSDL: Язык описания Web-сервисов
  • XML: Расширяемый язык разметки
  • XSLT: Расширяемый язык стилевых преобразований

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

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

Проблемы с XML Schema 1.0

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

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

Ограничение модели содержимого

Элементы составных типов могут иметь разные модели содержимого. Модели содержимого элементов, которые могут включать дочерние узлы, могут быть одного из трех видов: <xs:sequence>, <xs:choice> или <xs:all>. При определении нового составного типа путем наложения ограничения на другой тип необходимо гарантировать, что модели содержимого обоих типов удовлетворяют ряду условий. Эти условия необходимы для гарантии того, что любое корректное содержимое производного типа является корректным по отношению и к базовому типу.

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

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

В листинге 1 приведен производный тип derived, в котором отсутствует необязательный элемент tns:a, присутствующий в базовом типе base. Очевидно, что это должно быть корректным ограничением, однако оно запрещено в XML Schema 1.0.

Листинг 1. Пример производного типа, в котором отсутствует необязательный элемент из базового типа
<complexType name="base">
  <complexContent>
    <sequence>
      <element ref="tns:a" minOccurs="0" maxOccurs="1"/>
      <choice minOccurs="0" maxOccurs="unbounded">
        <element ref="tns:b"/>
        <element ref="tns:c"/>
      </choice>
    </sequence>
  </complexContent>
</complexType>

<complexType name="derived">
  <complexContent>
    <restriction base="tns:base">
      <sequence>
        <choice minOccurs="0" maxOccurs="unbounded">
          <element ref="tns:b"/>
          <element ref="tns:c"/>
        </choice>
      </sequence>
    </restriction>
  </complexContent>
</complexType>

В XML Schema 1.1 вместо 25 условий используется простая формулировка, которая говорит о том, что "все, что разрешено в производном типе, обязано быть разрешено в базовом". Таким образом, приведенный выше пример представляет собой корректную схему с точки зрения XML Schema 1.1.

Совместные ограничения

Авторам XML-схем часто требуется формулировать правила, ограничивающие значения нескольких элементов или атрибутов, например: "значение min должно быть меньше или равно max" или "число дочерних элементов должно быть равно значению атрибута size". Подобные правила часто называют совместными ограничениями или соограничениями (co-constraints).

XML Schema 1.0 не предоставлял никаких средств поддержки соограничений, поэтому иногда приходилось писать фрагменты кода на Java™ или С для проверки XML-документов после их загрузки в память. Это усложняло сопровождение схем, а также снижало возможности их применения в различных средах (так называемую интероперабельность). В целях решения этой проблемы некоторые пользователи обращались к другим языкам проверки XML, например Schematron и Relax NG (см. раздел "Ресурсы"), но это также усложняло архитектуру схем, в которой ранее использовался только XSD.

XML Schema 1.1 предоставляет встроенные средства поддержки соограничений. В новых элементах <xs:assert> можно формулировать условия при помощи выражений XPath 2.0 (см. раздел "Ресурсы"). Пример приведен в листинге 2.

Листинг 2. Пример использования совместных ограничений в XML Schema 1.1
<xs:complexType name="intRange">
  <xs:attribute name="min" type="xs:int"/>
  <xs:attribute name="max" type="xs:int"/>
  <xs:assert test="@min <= @max"/>
</xs:complexType>

Эволюция схем

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

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

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

В качестве примера рассмотрим модель содержимого, сформулированную следующим образом: "может существовать один и только один элемент userName, а также любое число любых других элементов до или после userName". Пример модели приведен в листинге 3.

Листинг 3. Модель содержимого в XML Schema 1.0
<xs:sequence>
  <xs:any minOccurs="0" maxOccurs="unbounded" processContents="skip"/>
  <xs:element ref="tns:userName"/>
  <xs:any minOccurs="0" maxOccurs="unbounded" processContents="skip"/>
</xs:sequence>

Такое описание является некорректным с точки зрения XML Schema 1.0, так как при появлении элемента userName в документе не ясно, относится ли он к конструкции <xs:any> или к объявлению <xs:element>. Для решения этой проблемы некоторые разработчики вставляли специальные элементы-разделители между шаблонами и другими элементами. Это вполне рабочее решение, однако оно делает и схему, и документы XML весьма громоздкими. Кроме того, существует еще одна трудность: шаблон также допускает использование элемента userName, поэтому невозможно гарантировать, что данный элемент будет использован "один и только один" раз.

Фрагмент схемы в листинге 3 является корректным с точки зрения XML Schema 1.1 благодаря тому, что шаблоны были несколько ослаблены. Это означает, что если некий элемент удовлетворяет как объявлению элемента, так и шаблону, то преимущество отдается первому. Таким образом, решается проблема с нарушением UPA. Правило "один и только один userName, плюс что угодно" можно выразить при помощи отрицательного шаблона, показанного в листинге 4.

Листинг 4. Модель содержимого в XML Schema 1.1
<xs:sequence>
  <xs:any minOccurs="0" maxOccurs="unbounded"
          processContents="skip" notQName="tns:userName"/>
  <xs:element ref="tns:userName"/>
  <xs:any minOccurs="0" maxOccurs="unbounded"
          processContents="skip" notQName="tns:userName"/>
</xs:sequence>

Типы данных в XML Schema

Спецификация XML Schema состоит из двух частей: описания структуры документов (Structures) и типов данных (Datatypes, см. раздел "Ресурсы"). В этом разделе мы поговорим об изменениях в спецификации, которые коснулись типов данных. В будущих статьях мы уделим больше внимания изменениям в описании структур.

Соответствие типам модели данных в XQuery 1.0 и XPath

Система типов, использующаяся в XQuery 1.0, XPath 2.0, XSLT 2.0, а также в рекомендациях XQuery 1.0 и в модели данных XPath 2.0 (см. раздел "Ресурсы"), является расширением системы типов рекомендации XML Schema 1.0. Вдобавок к встроенным примитивным типам данных XML Schema 1.0, эти спецификации также определяют пять дополнительных типов в том же пространстве имен, а именно: anyAtomicType, untyped, untypedAtomic, dayTimeDuration и yearMonthDuration. В XML Schema 1.1 были добавлены три из этих типов (anyAtomicType, dayTimeDuration и yearMonthDuration) в целях приведения системы типов XSD к соответствию с системой типов в перечисленных выше стандартах.

Тип anyAtomicType

anyAtomicType – это специальный встроенный тип данных в XML Schema 1.1, определенный путем ограничения типа anySimpleType. Поскольку anyAtomicType является базовым по отношению ко всем примитивным типам данных, его множество значений и литералов является объединением соответствующих множеств всех примитивных типов. Этот момент лучше прояснить на следующем примере: XML-схема представлена в листинге 5, а документ XML – в листинге 6. В этом примере элемент типа anyAtomicType может содержать строки или целые числа. Его значения также могут быть приведены к другому типу, производному от anyAtomicType, при помощи xsi:type. Имейте в виду, что anyAtomicType не определяет никаких ограничивающих фасетов (constraining facet), поэтому он не может использоваться в качестве базового для простых типов, определенных пользователем.

Листинг 5. Пример использования anyAtomicType в схеме
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        targetNamespace="test" xmlns:pfx="test">
   <element name="root">
      <complexType>
         <sequence>
            <element name="elanyAtomicType" type="anyAtomicType"
                     maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
</schema>
Листинг 6. Пример документа, в котором встречаются элементы типа anyAtomicType
<pfx:root xmlns:pfx="test" xmlns:xs="http://www.w3.org/2001/XMLSchema"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <elanyAtomicType>Test</elanyAtomicType>
   <elanyAtomicType>12345</elanyAtomicType>
   <elanyAtomicType xsi:type="xs:string">Test</elanyAtomicType>
   <elanyAtomicType xsi:type="xs:integer">12345</elanyAtomicType>
</pfx:root>

Тип yearMonthDuration

Тип duration, определенный в рекомендации типов данных XML Schema 1.0 (см. раздел "Ресурсы") служит для представления временных интервалов, поддерживающих частичное упорядочивание. Например, значения P30D и P1M являются несравнимыми, так как в месяце может быть от 28 до 31 дня. Для поддержки полного упорядочивания интервалов в XMl Schema 1.1 были введены два новых типа: yearMonthDuration и dayTimeDuration, являющихся ограничениями типа duration.

В XML Schema 1.1 тип yearMonthDuration был определен путем ограничения допустимых литералов duration. Теперь они могут включать только компоненты для представления года и месяца. Для этого используется регулярное выражение '-?P[0-9]+(Y([0-9]+M)?|M)'. Значениями компонентов для представления года и месяца могут быть любые беззнаковые целые числа, а знак минус можно использовать для представления отрицательных интервалов времени. Множество значений duration состоит из множества целых значений для числа месяцев и десятичных значений для числа секунд. Множество значений yearMonthDuration является подмножеством duration, в котором число секунд всегда равно нулю.

Положительный интервал в один год и шесть месяцев может быть представлен в виде следующих литералов типа yearMonthDuration P1Y6M и P18M, значением которых является 18 месяцев. Примерами корректных представлений типа yearMonthDuration могут служить P1Y2M, P12Y, -P20M, а некорректных - P-1Y, P1Y-1M и P1YM. Значения yearMonthDuration представляют собой полностью упорядоченное множество, т.е. можно сравнивать любые два значения (D1, D2) типа yearMonthDurations. Другими словами, либо D1 > D2, либо D1 < D2.

Пользовательские типы данных могут определяться путем ограничения yearMonthDuration. Для этого необходимо использовать ограничивающие фасеты, допускаемые типом duration. Тип yearMonthDuration сам является ограничением типа duration, поэтому его фундаментальный фасет ordered (упорядоченность) имеет значение partial (частичный), хотя на самом деле множество значений этого типа полностью упорядочено.

Тип dayTimeDuration

Как и yearMonthDuration, dayTimeDuration является типом, производным от duration. В его лексическом представлении могут использоваться только такие компоненты duration, как дни, часы, минуты и секунды. Это ограничение можно наложить при помощи регулярного выражения [^YM]*[DT].*. Значениями дней, часов и минут могут быть любые целые беззнаковые числа (тип xs:integer), а значениями секунд – любые значения xs:decimal. Кроме того, можно использовать знак "минус", который обозначает отрицательное значение типа dayTimeDuration. Множество значений типа dayTimeDuration определяется при помощи ограничения возможных значений duration, в частности, ограничены дробные части значений секунд, а число месяцев должно быть равно нулю.

Положительный интервал в один день, два часа, три минуты и 4.5 секунды соответствует следующему лексическому представлению типа dayTimeDuration: P1DT2H3M4.5S. Его значением является 93784.5 (1*24*60*60+2*60*60+3*60+4.5) секунд. Обратите внимание, что в литералах не обязательно указывать нулевые значения дней, часов, минут и секунд, однако хотя бы один из компонентов должен присутствовать. Если представление dayTimeDuration cостоит из одних дней, то можно опустить символ T. Примерами корректного представления dayTimeDuration могут служить P1D, PT25H, P22DT2H, PT1H99M5,5S, -PT20M, -PT60.60S, а некорректного - P-5D, P1D1M1H1S, PDT1M, P5H и P1DT. Аналогично yearMonthDuration тип dayTimeDuration является полностью упорядоченным.

Типы, производные от dayTimeDuration, могут указывать те же ограничивающие фасеты, что и типы, производные от duration Учтите, что значение фасета whitespace в типах yearMonthDuration и dayTimeDuration равно collapse и не может быть изменено.

В листинге 7 показан пример фрагмента, корректного с точки зрения XML Schema 1.1, в котором используются типы данных yearMonthDuration и dayTimeDuration.

Листинг 7. Пример использования типов yearMonthDuration и dayTimeDuration в XML Schema
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        targetNamespace="test" xmlns:pfx="test">
   <simpleType name="ymdBase">
      <restriction  base="yearMonthDuration">
         <minInclusive value="P1Y6M"/>
      </restriction>
   </simpleType>
   <simpleType name="ymdDerived">
      <restriction  base="ymdBase">
         <minInclusive value="P19M"/>
      </restriction>
   </simpleType>

   <simpleType name="dtdBase">
      <restriction  base="dayTimeDuration">
         <maxInclusive value="-P2DT2H"/>
      </restriction>
   </simpleType>
   <simpleType name="dtdDerived">
      <restriction  base="dtdBase">
         <maxInclusive value="-P51H"/>
      </restriction>
   </simpleType>

   <element name="root">
      <complexType>
         <sequence>
            <element name="elYearMonthDuration" type="ymdDerived"/>
            <element name="elDayTimeDuration" type="dtdDerived"/>
         </sequence>
      </complexType>
   </element>
</schema>

В листинге 7 продемонстрирован пример корректного использования типов yearMonthDuration и dayTimeDuration в XML Schema 1.1. Простой тип ymdDerived сужает область значений базового типа ymdBase, который в свою очередь ограничивает встроенный тип yearMonthDuration при помощи фасета minInclusive. Поскольку область значений yearMonthDuration является полностью упорядоченной, значение P19M производного типа ymdDerived больше, чем значение P1Y6M базового типа ymdBase, а значит, ограничение корректно. Аналогичным образом простой тип dtdDerived сужает область значений базового типа dtdBase, который в свою очередь ограничивает встроенный тип dayTimeDuration, используя фасет maxInclusive. В этом случае отрицательный интервал -P51H производного типа dtdDerived является меньшим по отношению к интервалу -P2DT2H базового типа. Элемент root содержит дочерние элементы elYearMonthDuration и elDayTimeDuration типов ymdDerived и dtdDerived соответственно.

Тип precisionDecimal

В XML Schema 1.1 был введен новый тип precisionDecimal для представления десятичных чисел с плавающей точкой в соответствии со стандартом IEEE-754. Он отличается от типа decimal тем, что указывается не только численное значение десятичных чисел, но и арифметическая точность представления. К значениям precisiontDecimal также относятся "положительная бесконечность" (+INF), "отрицательная бесконечность" (-INF), и NaN (not a number), говорящее о том, что данные не являются числом. Кроме того, различаются положительные и отрицательные нули (+0 и -0).

К допустимым литералам типа precisionDecimal относятся все записи десятичных чисел (с точкой или без нее), записи в научной (экспоненциальной) нотации, а также характерные строки 'INF', '+INF', '-INF', и 'NaN'.

Пользовательские типы, определяемые путем ограничения precisionDecimal, могут использовать все фасеты decimal. Кроме того, были введены два дополнительных ограничивающих фасета maxScale и minScale, которые позволяют сужать область значений типа precisionDecimal. При помощи фасета maxScale можно определить верхнюю, а при помощи minScale - нижнюю границу точности значений типа precisionDecimal.

В листинге 8 показано определение нового типа price, который допускает все значения в интервале от -999,999.99 до 999,999.99.

Листинг 8. Пример использования типа precisionDecimal в XML Schema
<xs:simpleType name='price'>
  <xs:restriction base='xs:precisionDecimal'>
    <xs:totalDigits value='8'/>
    <xs:minScale value='2'/>
    <xs:maxScale value='2'/>
  </xs:restriction>
</xs:simpleType>

При работе с NaN важно помнить, что его нельзя сравнивать с любым другим значением, в том числе и с самим собой. Таким образом, использование NaN при задании ограничивающего фасета (minInclusive, maxInclusive, minExclusive или maxExclusive) приведет к пустой области значений результирующего типа данных.

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

Часовые пояса и разница во времени

В XML Schema 1.0 типы данных, связанные с date, time и dateTime, включали в себя необязательный компонент для указания часовых поясов в формате (('+' | '-') hh ':' mm) | 'Z'. В результате добавления значения этого компонента к времени по Гринвичу (UTC) получается дата и время в указанном часовом поясе.

Несмотря на то, что в типах данных XML Schema 1.0 используются часовые сдвиги (timezone offset), для их описания применяется термин "часовой пояс" (timezone), что приводит к определенной путанице, поскольку это различные понятия. Часовой пояс описывает конкретную область на карте (например, Тихоокеанский пояс), в то время как часовой сдвиг определяет разницу в часах и минутах между определенным часовым поясом и временем UTC (например, 11:00-05:00). В спецификации XML Schema 1.1 эта проблема была устранена, и теперь термины timezone и timezone offset различаются, как положено.

Корректировочные секунды

Корректировочными (leap seconds) называют секунды, которые добавляются к последним дням в марте, июне, октябре и декабре. Это приводит к тому, что последняя минута в последних днях этих месяцев длится более 60 секунд. Это делается для того, чтобы поддерживать время UTC в пределах 0.9 секунд от астрономического.

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

Простые типы и фасеты, определяемые XML-процессорами

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

Примитивные типы, определяемые реализацией

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

Производители процессоров обязаны следовать следующим правилам:

  • anyAtomicType должен быть базовым типом;
  • необходимо определить набор ограничивающих фасетов, а также что они означают (при этом фасет whiteSpace должен присутствовать);
  • необходимо определить механизм для обращения к новому типу внутри пространств имен, отличных от http://www.w3.org/2001/XMLSchema (пространства имен, контролируемого W3C);
  • следует определить множество корректных литералов, область значений, а также лексическое отображения для нового типа;
  • необходимо определить отношение равенства;
  • необходимо определить значения фундаментальных фасетов.

Предположим, что, будучи разработчиками XML-процессора, мы хотим определить специальный тип date для представления дат в формате день-месяц-год, но с использованием разделителей, отличных от дефисов (-). В соответствии с перечисленными выше правилами, необходимо использовать anyAtomicType в качестве базового, а также определить новое пространство имен, например "http://www.example.com/XMLSchema-primitiveTypes". Предположим, что данные должны отображаться в формате день, разделитель, месяц, разделитель, год. Представления дней, месяцев и годов и лексическом пространстве типа date будут совпадать с представлениями этих компонентов в XML Schema 1.1. Наконец, желательно, чтобы разделителем был один из трех символов: точка (.), дефис (-) или косая черта (/).

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

  • ordered: partial (тип упорядоченности : частичная)
  • bounded: false (ограниченность : нет)
  • cardinality: countably infinite (мощность : счетно-бесконечная)
  • numeric: false (численный : нет)

Следуя правилам, нам также придется включить фасет whiteSpace. Ему будет присвоено значение "collapsed", которое будет действовать для date и его производных типов. Спецификация XML Schema 1.1 позволяет определить дополнительные ограничивающие фасеты и их значения, такие как:

  • pattern
  • enumeration
  • maxInclusive
  • maxExclusive
  • minInclusive
  • minExclusive
  • assertions
  • dateSeparator (определяется реализацией)

Согласно нашему определению, строки "2008-11-01", "2008.11.01" и "2008/11/01" представляют собой корректные лексические представления дат. Значением всех трех представлений является первое ноября 2008 года.

Фасеты, определяемые реализацией

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

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

Ниже приведены некоторые из действий, которые следует выполнить при определении нового фасета:

  • определить свойства фасета;
  • определить поведение фасета;
  • определить механизм ссылки на новый фасет в пространствах имен, отличных от http://www.w3.org/2001/XMLSchema (пространства имен, контролируемого W3C);
  • определить примитивные типы данных, к которым применим данный фасет.

В листинге 9 приведен пример того, как производители XML-процессора могут определить фасет dateSeparator, который ограничивает значения символов-разделителей, используемых в области значений date и производных от него типов.

Листинг 9. Пример фасета, определяемого реализацией
<dateSeparator
    fixed = boolean : false
    id  = ID
    value = '-' | '.' | '/'

    ...   >
  (необязательное содержимое элемента)
    ...
</dateSeparator>

Определение фасета может включать описание дополнительных атрибутов (кроме fixed, id, и value) в пространстве имен, отличном от пространства имен схемы. Каждый производный тип данных может затем ограничивать область значений date, применяя фасет dateSeparator.

Далее рассмотрим пример использования типа данных и его фасета, определенных XML-процессором. В листинге 10 показано определение нового типа specialDate, в представлении которого в качестве разделителя может использоваться только косая черта. Данное ограничение накладывается при помощи фасета dateSeparator.

Листинг 10. Пример объявления производного типа при помощи фасета, определяемого реализацией
<xs:simpleType name="specialDate">
  <xs:restriction base="xyz:date">
    <xyz:dateSeparator value="/" />
  <xs:restriction>
</xs:simpleType>

Теперь представление "2008/11/01" является корректным, а "2008-11-01" и "2008.11.01" – нет.

Заключение

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

Ресурсы

Научиться

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

Обсудить

Комментарии

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=492204
ArticleTitle=XML Schema 1.1: Часть 1.Введение
publish-date=05262010