За межами W3C XML Schema, HTML, XML, DHTML, Інтернет-технології, статті

Уїлл Провост

Для перевірки допустимості документа як частини потоку програми можна написати W3C XML Schema. Це цілком природний підхід, хоча W3C XML Schema – всього лише частина концепції перевірки допустимості. У цій статті ми розглянемо кілька рівнів процесу перевірки достовірності, який починається з перевірки допустимості схеми (schema), але також використовує XPath і XSLT для встановлення обмежень на вміст (контент) документа, які виявляються занадто складними або навіть неприйнятними для W3C XML Schema.

розпорядчої (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), які вимагають, принаймні, два гучномовця, однак, давайте припустимо, що, щоб система з квадрафоніческім джерелом звуку була допустимої, необхідно мати не менше чотирьох гучномовців. Тоді наступний документ є допустимим за наведеною вище схемою, але, з урахуванням наших більш загальних задач, він некоректний:


&lt?xml version=”1.0″ encoding=”UTF-8″ ?>
&ltStereo
 xmlns:xsi=”www.w3.org/2001/XMLSchema-instance”
 xsi:noNamespaceSchemaLocation=”Stereo.xsd”>
 &ltAmplifier>Mondo Electronics&lt/Amplifier>
 &ltReceiver>Mondo Electronics&lt/Receiver>
 &ltQuadraphonicDiscPlayer>CSI Labs&lt/QuadraphonicDiscPlayer>
 &ltSpeaker>Moltman&lt/Speaker>
 &ltSpeaker>Moltman&lt/Speaker>
&lt/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=”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) до конкретного документу. У відповідність з підходом, викладеним вище, ця трансформація визначає шаблон для кожного з двох обмежень і в кожному випадку видає відповідне повідомлення про помилку:


<?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

Отже, ми переконалися, що 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 і інші Специфікації

  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.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*