| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
За пределами W3C XML Schema Для проверки допустимости документа как части потока приложения можно написать Именно здесь на помощь и приходят XPath и XSLT: мы убедимся в том, что подход, основанный на трансформации, позволяет накладывать множество удобных и полезных ограничений, и, кроме того, во многом лучше подходит для решения задачи проверки допустимости. (На самом деле, возможно описание проверки схемы, представляющей собой ничто иное, как особый вид трансформации - см. В начале мы изучим простые модели ограничения, которые недостаточно хорошо поддерживаются W3C XML Schema, затем попытаемся разработать трансформационный подход для решения этих задач. Ограничения - простые модели Рассмотрим два примера, реализация каждого из которых затруднительна в W3C XML Schema. Первая задача - это схема домашней стереосистемы. Она требует две конфигурации для усиления звука, а затем допускает произвольное количество источников звука, следующих один за другим. В заключение приведен список громкоговорителей. (Для простоты мы опустили информацию о типе данных и сосредоточили внимание исключительно на структуре. В "
<?xml version="1.0" encoding="UTF-8" ?> Мы располагаем ограничениями наличия (occurrence constraints), которые требуют, по крайней мере, два громкоговорителя, однако, давайте предположим, что, чтобы система с квадрафоническим источником звука была допустимой, необходимо иметь не менее четырех громкоговорителей. Тогда следующий документ является допустимым по приведенной выше схеме, но, с учетом наших более общих задач, он некорректен:
<?xml version="1.0" encoding="UTF-8" ?> Мы могли бы разбить всю модель содержания в xs:choice между двумя типами систем, одна из которых включала бы квадрафоническую характеристику, но такое решение выглядит довольно уродливо. А практике эта же самая модель может накладываться на множество более разнообразных типов, во всевозможных комбинациях, и модель, которая перечисляет все допустимые конфигурации, быстро становится громоздкой - ее трудно читать и поддерживать. Таким образом, для анализа дерева документа в целом требуется одна простая модель. W3C XML Schema делает акцент на непосредственных связях между элементами и атрибутами, родителями и детьми. Более прямой подход к чистой проверке допустимости - начать из области видимости документа и оттуда расставить утверждения (assertions), углубляясь так глубоко, насколько это необходимо для выражения ограничения. Как мы увидим в дальнейшем, XPath гораздо лучше подходит для абстрактного анализа дерева, нежели W3C XML Schema. Вторая задача. Представьте схемы со слабо определенными типами. В общем, использование слабых типов в XML-документах не приветствуется, хотя вовсе необязательно, что эта модель подвернется в случае необходимости. Вместо создания многочисленных подтипов для выражения специализации используется один сложный тип, который включает атрибут "type" - обычно перечень с одним возможным значением для каждого псевдоподтипа. Опираясь на значение этого атрибута, другие атрибуты и элементы могут либо быть, либо не быть значащими. Таким образом, в свете W3C XML Schema все эти атрибуты и элементы должны считаться факультативными, а это ослабляет предписывающую характеристику схемы. Для W3C XML Schema это чрезвычайно трудная задача, поскольку ничто в Рекомендации W3C XML Schema не предусматривает проверку допустимости структуры, основанной на значениях в конкретном документе (instance document).
Пример со стереосистемой в первую очередь предназначен для того, чтобы показать, что эта схема не может делать: как мы смогли бы выразить, что, если Means означает "Лично, в присутствии" ("In person"), то требуются оба элемента SignatureVerifiedBy и VisuallyIdentifiedBy, а для продаж через Интернет необходим элемент DigitalSignature? XPath как язык ограничений - выбор того, что не должно существовать Очевидно, что для того, чтобы разработать комплексную структуру проверки допустимости XML-документа, необходимо нечто большее, чем просто задание ограничений содержания - а только это и может предложить W3C XML Schema. Мы нуждаемся в двух составляющих: нам нужен язык для определения ограничений, и механизм, с помощью которого мы сможем их накладывать на данный XML-документ. Возвращаясь к приведенным выше примерам, можно сделать вывод, то наш язык ограничений должен позволять выражать ограничения любой области видимости - самое меньшее, до области видимости документа - и любой сложности. Он должен разрешать выбор, по крайней мере, основного узла посредством тега или имени атрибута, а также допускать распознавание модели, подсчет тестов существования и узлов, и поддерживать простые числовые, строковые и булевы выражения для сравнения значений. Совершенно очевидно, что XPath идеально подходит для этого. Он опирается на выражения, допускает произвольно сложные ограничения. Он может осуществлять простую математическую и строковую обработки, кроме того, приложив совсем немного усилий, вы сможете выполнять некоторые довольно сложные арифметические операции. Но самое главное - это то, что выражения XPath могут оценивать множества узлов, предусматривая выбор всех узлов, отвечающих определенным критериям. В этом случае вопрос состоит в том, что выбирать. Интуитивно следует выбирать то, что допустимо. Однако, если немного подумать, то нетрудно понять, что проверка допустимости - это процесс выбрасывания недопустимых данных. Таким образом, наша цель - выразить ограничения как утверждения о моделях с неприемлемым содержанием. Другими словами, весь фокус состоит в том, чтобы выбрать то, что не должно существовать. Например, следующее выражение XPath - Stereo[count (CDPlayer | Turntable | CassetteDeck | QuadraphonicDiscPlayer) = 0] - выбирало бы любую стереосистему без источников звука, но возвращало бы пустой набор узлов для допустимого документа. Именно такую форму и должно принимать наше утверждение. XSLT - трансформация в качестве проверки допустимости XPath никогда не существовал сам по себе; он воспринимался как удобный и простой язык, применяемый для различных целей, включая трансформации, синтаксический анализ и даже разработку схем. Теперь нам необходимо применить этот язык выражений для выполнения проверки допустимости. Структура xsl:transform довольно проста:
Давайте посмотрим, как можно решить с помощью XSLT задачи, о которых говорилось выше. Для начала установим два ограничения, которые не распознаются
Перейдем ко второму уровню процесса проверки допустимости: применению верификационной XMLT-трансформации (validating XSLT transform) к конкретному документу. В соответствие с подходом, изложенным выше, эта трансформация определяет шаблон для каждого из двух ограничений и в каждом случае выдает соответствующее сообщение об ошибке:
<?xml version="1.0" encoding="UTF-8"?> Взгляните на 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:
Если вы желаете третью линию защиты - это код приложения. Ясно, что XPath и XSLT не могут сделать то, что может этот код; в особенности, это касается вычислительных возможностей, которые существенно ограничены. XPath имеет некоторые математические функции, а XSLT - конструкции и переменные управления потоками - их можно использовать для выполнения простых вычислений, таких как сумма продуктов. Но это - жалкое подобие тех возможностей, которые предоставляют современные языки программирования. И все же, то, что можно сделать с помощью XPath/XSLT, требует всего нескольких строк простого кода. Мы надеемся, что использование этого уровня не создаст дополнительных проблем. Интеграция XPath и XSLT на уровне кода также предлагает большие преимущества и может сгладить границу между описанными второй и третьей линией. К сожалению, XPath все еще не охватывает типы XML Schema. Например, было бы удобно использовать Xpath для выбора всех рейсов в плане маршрута для того, чтобы гарантировать, что они действительно последовательные. В Xpath 1.0 нет типа date, как в XML Schema, так что для выполнения этого утверждения потребовалось бы или использовать некую причудливую обработку XPath/XSLT, либо передавать его в код приложения. Среди требований к Xpath 2.0 ( Постскриптум - схожие подходы и инструментальные средства Итак, мы рассмотрели многоуровневую структуру проверки допустимости, опираясь только на стандарты W3C. Помимо указанной технологии, существует еще один популярный подход, основанный на преобразовании - "Рекомендуемая литература" W3C и другие Спецификации
|
|
| ||||||||||||||||
|