Именно здесь на помощь и приходят XPath и XSLT: мы убедимся в том, что
подход, основанный на трансформации, позволяет накладывать множество удобных и
полезных ограничений, и, кроме того, во многом лучше подходит для решения задачи
проверки допустимости. (На самом деле, возможно описание проверки схемы,
представляющей собой ничто иное, как особый вид трансформации - см. van
der Vlist.)
В начале мы изучим простые модели ограничения, которые недостаточно хорошо
поддерживаются W3C XML Schema, затем попытаемся разработать трансформационный
подход для решения этих задач.
Рассмотрим два примера, реализация каждого из которых затруднительна в W3C
XML Schema. Первая задача - это схема домашней стереосистемы. Она требует две
конфигурации для усиления звука, а затем допускает произвольное количество
источников звука, следующих один за другим. В заключение приведен список
громкоговорителей. (Для простоты мы опустили информацию о типе данных и
сосредоточили внимание исключительно на структуре. В "Белых бумагах" приведены более подробные и полностью рабочие
примеры, а также код.)
Мы располагаем ограничениями наличия (occurrence constraints), которые
требуют, по крайней мере, два громкоговорителя, однако, давайте предположим,
что, чтобы система с квадрафоническим источником звука была допустимой,
необходимо иметь не менее четырех громкоговорителей. Тогда следующий документ
является допустимым по приведенной выше схеме, но, с учетом наших более общих
задач, он некорректен:
<?xml version="1.0" encoding="UTF-8"
?>
<Stereo
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="Stereo.xsd">
<Amplifier>Mondo
Electronics</Amplifier>
<Receiver>Mondo
Electronics</Receiver>
<QuadraphonicDiscPlayer>CSI
Labs</QuadraphonicDiscPlayer>
<Speaker>Moltman</Speaker>
<Speaker>Moltman</Speaker>
</Stereo>
Мы могли бы разбить всю модель содержания в 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?
Очевидно, что для того, чтобы разработать комплексную структуру проверки
допустимости XML-документа, необходимо нечто большее, чем просто задание
ограничений содержания - а только это и может предложить W3C XML Schema. Мы
нуждаемся в двух составляющих: нам нужен язык для определения ограничений, и
механизм, с помощью которого мы сможем их накладывать на данный
XML-документ.
Возвращаясь к приведенным выше примерам, можно сделать вывод, то наш язык
ограничений должен позволять выражать ограничения любой области видимости -
самое меньшее, до области видимости документа - и любой сложности. Он должен
разрешать выбор, по крайней мере, основного узла посредством тега или имени
атрибута, а также допускать распознавание модели, подсчет тестов существования и
узлов, и поддерживать простые числовые, строковые и булевы выражения для
сравнения значений. Совершенно очевидно, что XPath идеально подходит для этого.
Он опирается на выражения, допускает произвольно сложные ограничения. Он может
осуществлять простую математическую и строковую обработки, кроме того, приложив
совсем немного усилий, вы сможете выполнять некоторые довольно сложные
арифметические операции. Но самое главное - это то, что выражения XPath могут
оценивать множества узлов, предусматривая выбор всех узлов, отвечающих
определенным критериям.
В этом случае вопрос состоит в том, что выбирать. Интуитивно следует выбирать
то, что допустимо. Однако, если немного подумать, то нетрудно понять, что
проверка допустимости - это процесс выбрасывания недопустимых данных. Таким
образом, наша цель - выразить ограничения как утверждения о моделях с
неприемлемым содержанием. Другими словами, весь фокус состоит в том, чтобы
выбрать то, что не должно существовать. Например, следующее выражение XPath
- Stereo[count (CDPlayer | Turntable | CassetteDeck | QuadraphonicDiscPlayer) =
0] - выбирало бы любую стереосистему без источников звука, но возвращало
бы пустой набор узлов для допустимого документа. Именно такую форму и должно
принимать наше утверждение.
XPath никогда не существовал сам по себе; он воспринимался как удобный и
простой язык, применяемый для различных целей, включая трансформации,
синтаксический анализ и даже разработку схем. Теперь нам необходимо применить
этот язык выражений для выполнения проверки допустимости. XSLT
формирует процесс проверки допустимости в виде трансформации, результат которой
будет состоять из сообщений об ошибках или будет пустым.
Структура xsl:transform довольно проста:
- Имеется один шаблон, который отменяет правила встроенного XMLT-шаблона для
подавления всех автоматических выходных данных, допуская вместе с тем видимость
каждого узла документа.
- Для каждого ограничения имеется один шаблон, чей атрибут match
является выражением XPath, описывающим данные, которые были бы недопустимы по
этому ограничению. При каждом нарушении ограничения каждый такой шаблон будет
один раз подвергнут обработке и выдаст результат в виде предупреждения или
сообщения об ошибке. (Мы будем использовать метод вывода text для
этих примеров; заметьте, на практике, возможно, будет либо определяться
XML-словарь выходных данных для проверки допустимости, либо использоваться
существующий. Для более подробной информации см. "Белые бумаги".)
Давайте посмотрим, как можно решить с помощью XSLT задачи, о которых
говорилось выше. Для начала установим два ограничения, которые не распознаются
схемой стереосистемы:
- Для, самое меньшее, одного квадрафонического источника звука, должно быть не
менее четырех громкоговорителей.
- Стереосистема должна иметь, по крайней мере, один источник звука.
Перейдем ко второму уровню процесса проверки допустимости: применению
верификационной XMLT-трансформации (validating XSLT transform) к конкретному
документу. В соответствие с подходом, изложенным выше, эта трансформация
определяет шаблон для каждого из двух ограничений и в каждом случае выдает
соответствующее сообщение об ошибке:
<?xml
version="1.0" encoding="UTF-8"?>
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
<xsl:output
method="text" />
<xsl:strip-space elements="*"
/>
<xsl:template match="text ()" />
<xsl:template
match="Stereo[QuadraphonicDiscPlayer]
[count (Speaker) < 4]"
>
<xsl:text>ERROR: Quadraphonic sound source
without enough
speakers.
</xsl:text>
</xsl:template>
<xsl:template
match="Stereo[count (CDPlayer | Turntable
| CassetteDeck |
QuadraphonicDiscPlayer) = 0]">
<xsl:text>ERROR: Stereo system must
have at least
one sound
source.
</xsl:text>
</xsl:template>
</xsl:transform>
Взгляните на конкретный документ,
приведенный выше, - он не должен считаться допустимым. Хот, приведенный выше, -
он не должен считаться допустимым. Хотя он все еще проверяется по этой схеме,
верификационная трансформация "заваливает" его. Примерный результат
трансформирования конкретного документа с использованием приведенного
преобразования имеет следующий вид:
ERROR: Quadraphonic sound source without enough speakers (ОШИБКА:
Квадрафонический источник звука без достаточного количества
громкоговорителей).
Теперь давайте вернемся к нашей транзакционной модели со слабо определенными
типами. Мы описали верификационную трансформацию, чтобы установить, что для
подтверждения, например, личных транзакций необходимо проверить подпись и
установить личность по фотографии. Тогда, если одна из записей о продажах не
содержит этих двух обязательных пунктов, документ кандидата не выполнит верификационную трансформацию и
выдаст следующий результат:
ERROR: In-person sales must have verified signature and visual ID (ОШИБКА:
Личные продажи должны иметь установленную подпись и быть визуально
подтверждены).
Итак, мы убедились, что 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 и другие Спецификации
- Расширяемый
язык разметки (XML) 1.0, 2-ое издание.
- Пространства имен в XML 1.0.
- XML Schema 1.0 - издано в трех частях:
- XPath
1.0.
- XML язык
таблицы стилей для преобразования 1.0 (XSLT).
- XPath
2.0 -- Требования.
- XSLT
2.0 -- Требования.
- Schematron.
- RELAX NG.
Уилл Провост
