За пределами W3C XML Schema

Постоянные посетители Клуба знатоков знают, что самые последние новости по
технологиям Хранилищ данных, OLAP и XML регулярно освещаются в разделе "Новости
технологий". Так, 1 марта этого года мы рассказали о будущем языка XML:
"Сегодня" и "завтра" языка XML: обновления XML 1.0, и каким будет XML 2.0.
Продолжая разговор о развитии XML, мы решили осветить некоторые аспекты
процесса проверки допустимости XML-документов. Именно об этом пойдет речь в
статье Уилла Провоста - об использовании XPath и XSLT в качестве альтернативы
W3C XML Schema.

Для проверки допустимости документа как части потока приложения можно написать W3C XML Schema. Это вполне естественный подход, хотя W3C XML Schema - всего лишь часть концепции проверки допустимости. В этой статье мы рассмотрим несколько уровней процесса проверки достоверности, который начинается с проверки допустимости схемы (schema), но также использует XPath и XSLT для установления ограничений на содержимое (контент) документа, которые оказываются слишком сложными или даже неприемлемыми для W3C XML Schema.

Мы можем говорить о схеме и как о выразительной (expressive), и как о предписывающей (prescriptive): она описывает желаемую структуру и интерпретацию типа документа и одновременно накладывает ограничения на допустимое содержимое. Тем не менее, существует предвзятое отношение к этой выразительности: W3C XML Schema придает особое значение "моделям содержания" ("content models"), которые хороши для описания структуры документа, но непригодны для определения многочисленных моделей ограничения (constraint patterns).

Именно здесь на помощь и приходят XPath и XSLT: мы убедимся в том, что подход, основанный на трансформации, позволяет накладывать множество удобных и полезных ограничений, и, кроме того, во многом лучше подходит для решения задачи проверки допустимости. (На самом деле, возможно описание проверки схемы, представляющей собой ничто иное, как особый вид трансформации - см. van der Vlist.)

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

Ограничения - простые модели

Рассмотрим два примера, реализация каждого из которых затруднительна в W3C XML Schema. Первая задача - это схема домашней стереосистемы. Она требует две конфигурации для усиления звука, а затем допускает произвольное количество источников звука, следующих один за другим. В заключение приведен список громкоговорителей. (Для простоты мы опустили информацию о типе данных и сосредоточили внимание исключительно на структуре. В "Белых бумагах" приведены более подробные и полностью рабочие примеры, а также код.)

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

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

Таким образом, для анализа дерева документа в целом требуется одна простая модель. W3C XML Schema делает акцент на непосредственных связях между элементами и атрибутами, родителями и детьми. Более прямой подход к чистой проверке допустимости - начать из области видимости документа и оттуда расставить утверждения (assertions), углубляясь так глубоко, насколько это необходимо для выражения ограничения. Как мы увидим в дальнейшем, XPath гораздо лучше подходит для абстрактного анализа дерева, нежели W3C XML Schema.

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

Опираясь на значение этого атрибута, другие атрибуты и элементы могут либо быть, либо не быть значащими. Таким образом, в свете W3C XML Schema все эти атрибуты и элементы должны считаться факультативными, а это ослабляет предписывающую характеристику схемы. Для W3C XML Schema это чрезвычайно трудная задача, поскольку ничто в Рекомендации W3C XML Schema не предусматривает проверку допустимости структуры, основанной на значениях в конкретном документе (instance document).

<?xml version="1.0" encoding="UTF-8" ?>

<xs:schema version="1.0"
 xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:complexType name="CreditTransaction"
  abstract="true">
   <xs:sequence>
    <xs:element name="SignatureVerifiedBy" type="xs:string"
     minOccurs="0" />
    <xs:element name="VisuallyIdentifiedBy"
     type="xs:string" minOccurs="0" />
    <xs:element name="DigitalSignature" type="xs:string"
     minOccurs="0" />
   </xs:sequence>
  <xs:attribute name="Means">
   <xs:simpleType>
    <xs:restriction base="xs:string">
     <xs:enumeration value="In person" />
     <xs:enumeration value="Internet" />
     <xs:enumeration value="Phone" />
     <xs:enumeration value="Fax" />
     <xs:enumeration value="Mail" />
    </xs:restriction>
   </xs:simpleType>
  </xs:attribute>
 </xs:complexType>

 <xs:complexType name="Sale">
  <xs:complexContent>
   <xs:extension base="CreditTransaction">
    <xs:sequence>
     <xs:element name="Item" type="xs:string" />
     <xs:element name="Price" type="xs:decimal" />
    </xs:sequence>
   </xs:extension>
  </xs:complexContent>
 </xs:complexType>

 <xs:element name="Sales">
  <xs:complexType>
   <xs:sequence>
    <xs:element name="Sale" type="Sale"
     maxOccurs="unbounded" />
   </xs:sequence>
  </xs:complexType>
 </xs:element>

</xs:schema>

для кредитных транзакций - пример системы со слабыми типами. Определяются различные механизмы аутентификации действующего субъекта, а Means выполнения транзакции - это наш атрибут "type". Другие механизмы потребуют иные комбинации аутентификаций.

Пример со стереосистемой в первую очередь предназначен для того, чтобы показать, что эта схема не может делать: как мы смогли бы выразить, что, если Means означает "Лично, в присутствии" ("In person"), то требуются оба элемента SignatureVerifiedBy и VisuallyIdentifiedBy, а для продаж через Интернет необходим элемент DigitalSignature?

XPath как язык ограничений - выбор того, что не должно существовать

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

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

В этом случае вопрос состоит в том, что выбирать. Интуитивно следует выбирать то, что допустимо. Однако, если немного подумать, то нетрудно понять, что проверка допустимости - это процесс выбрасывания недопустимых данных. Таким образом, наша цель - выразить ограничения как утверждения о моделях с неприемлемым содержанием. Другими словами, весь фокус состоит в том, чтобы выбрать то, что не должно существовать. Например, следующее выражение XPath - Stereo[count (CDPlayer | Turntable | CassetteDeck | QuadraphonicDiscPlayer) = 0] - выбирало бы любую стереосистему без источников звука, но возвращало бы пустой набор узлов для допустимого документа. Именно такую форму и должно принимать наше утверждение.

XSLT - трансформация в качестве проверки допустимости

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

Структура xsl:transform довольно проста:

1. Имеется один шаблон, который отменяет правила встроенного XMLT-шаблона для подавления всех автоматических выходных данных, допуская вместе с тем видимость каждого узла документа.
2. Для каждого ограничения имеется один шаблон, чей атрибут match является выражением XPath, описывающим данные, которые были бы недопустимы по этому ограничению. При каждом нарушении ограничения каждый такой шаблон будет один раз подвергнут обработке и выдаст результат в виде предупреждения или сообщения об ошибке. (Мы будем использовать метод вывода text для этих примеров; заметьте, на практике, возможно, будет либо определяться XML-словарь выходных данных для проверки допустимости, либо использоваться существующий. Для более подробной информации см. "Белые бумаги".)

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

1. Для, самое меньшее, одного квадрафонического источника звука, должно быть не менее четырех громкоговорителей.
2. Стереосистема должна иметь, по крайней мере, один источник звука.

Перейдем ко второму уровню процесса проверки допустимости: применению верификационной XMLT-трансформации (validating XSLT transform) к конкретному документу. В соответствие с подходом, изложенным выше, эта трансформация определяет шаблон для каждого из двух ограничений и в каждом случае выдает соответствующее сообщение об ошибке:

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

ERROR: Quadraphonic sound source without enough speakers (ОШИБКА: Квадрафонический источник звука без достаточного количества громкоговорителей).

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

ERROR: In-person sales must have verified signature and visual ID (ОШИБКА: Личные продажи должны иметь установленную подпись и быть визуально подтверждены).

Преимущества и ограничения XPath/XSLT

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

• Структурный анализ дерева в целом, как в примере со стереосистемой.
• Схемы со слабым описанием типов, как в примере продаж.
• Более совершенный контроль над использованием подтипов - скажем, базовые типы А и В связаны, но подтип А2 должен видеть только экземпляры В2, а не В1 или В3 и т.д.
• Одиночные значения, основанные на числовых или строковых вычислениях - число, которое должно быть кратно трем, строка должна вести список значений в определенном порядке.
• Связи между допустимыми одиночными значениями - контрольная сумма длинного списка значений или правило, ограничивающее общее число присутствия обычного символа.
• Ограничения, которые охватывают многочисленные документы - например, динамическое перечисление, где во втором документе перечислены допустимые значения и, таким образом, не могут быть жестко закодированы в схему.

Если вы желаете третью линию защиты - это код приложения. Ясно, что XPath и XSLT не могут сделать то, что может этот код; в особенности, это касается вычислительных возможностей, которые существенно ограничены. XPath имеет некоторые математические функции, а XSLT - конструкции и переменные управления потоками - их можно использовать для выполнения простых вычислений, таких как сумма продуктов. Но это - жалкое подобие тех возможностей, которые предоставляют современные языки программирования. И все же, то, что можно сделать с помощью XPath/XSLT, требует всего нескольких строк простого кода. Мы надеемся, что использование этого уровня не создаст дополнительных проблем. Интеграция XPath и XSLT на уровне кода также предлагает большие преимущества и может сгладить границу между описанными второй и третьей линией.

К сожалению, XPath все еще не охватывает типы XML Schema. Например, было бы удобно использовать Xpath для выбора всех рейсов в плане маршрута для того, чтобы гарантировать, что они действительно последовательные. В Xpath 1.0 нет типа date, как в XML Schema, так что для выполнения этого утверждения потребовалось бы или использовать некую причудливую обработку XPath/XSLT, либо передавать его в код приложения. Среди требований к Xpath 2.0 (XPath 2.0 Requirements) - расширение модели типов Xpath, направленное на включение встроенных типов XML Schema.

Постскриптум - схожие подходы и инструментальные средства

Итак, мы рассмотрели многоуровневую структуру проверки допустимости, опираясь только на стандарты W3C. Помимо указанной технологии, существует еще один популярный подход, основанный на преобразовании - Schematron, инструментальное средство с отрытым кодом, которое определяет ограничения на своем собственном языке. Его словарь упрощает структуру XSLT, рассмотренную выше, а для выражения ограничений опирается на Xpath. Он также допускает как "положительные", так и "отрицательные" утверждения. Основное различие заключается в том, что схема Schematron должна быть предварительно скомпилирована, или, если вы желаете, "предварительно трансформирована", в верифицирующую таблицу стилей (stylesheet), которая создается один раз и является истинным прототипом использованных здесь чистых XSLT-преобразований. (Чтобы познакомится с основами Schematron, см. Ogbuji.)

Рекомендуемая литература

W3C и другие Спецификации

1. Расширяемый язык разметки (XML) 1.0, 2-ое издание.
2. Пространства имен в XML 1.0.
3. XML Schema 1.0 - издано в трех частях:
   • Часть 0 - Для начинающих;
   • Часть 1 - Структура;
   • Часть 2 - Типы данных.
4. XPath 1.0.
5. XML язык таблицы стилей для преобразования 1.0 (XSLT).
6. XPath 2.0 -- Требования.
7. XSLT 2.0 -- Требования.
8. Schematron.
9. RELAX NG.

Автор: Уилл Провост (Will Provost)