Для проверки допустимости документа как части потока приложения можно написать 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. Первая задача - это схема домашней стереосистемы. Она требует две конфигурации для усиления звука, а затем допускает произвольное количество источников звука, следующих один за другим. В заключение приведен список громкоговорителей. (Для простоты мы опустили информацию о типе данных и сосредоточили внимание исключительно на структуре. В "Белых бумагах" приведены более подробные и полностью рабочие примеры, а также код.)
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema version="1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Stereo"><xs:complexType>
<xs:sequence>
<xs:choice>
<xs:sequence>
<xs:element name="Amplifier" />
<xs:element name="Receiver" />
</xs:sequence>
<xs:element name="Tuner" />
</xs:choice>
<xs:element name="CDPlayer" minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="Turntable" minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="CassetteDeck" minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="QuadraphonicDiscPlayer"
minOccurs="0"
maxOccurs="unbounded" />
<xs:element name="Speaker" minOccurs="2"
maxOccurs="6" />
</xs:sequence>
</xs:complexType></xs:element>
</xs: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>
XPath никогда не существовал сам по себе; он воспринимался как удобный и простой язык, применяемый для различных целей, включая трансформации, синтаксический анализ и даже разработку схем. Теперь нам необходимо применить этот язык выражений для выполнения проверки допустимости. XSLT формирует процесс проверки допустимости в виде трансформации, результат которой будет состоять из сообщений об ошибках или будет пустым.
Структура xsl:transform довольно проста:
Давайте посмотрим, как можно решить с помощью 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:
Если вы желаете третью линию защиты - это код приложения. Ясно, что 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 и другие Спецификации