Перевірка допустимості за допомогою Schematron, HTML, XML, DHTML, Інтернет-технології, статті

Чімезі Огбуджі

Schematron – це мова опису схеми, який можна використовувати для перевірки допустимості XML-документа. Припускаючи, що читач знайомий з XML 1.0, DTDs, XSLT і XPath, я зупинюся на питаннях перевірки допустимості за допомогою Schematron.

Навіщо потрібні схеми

Схеми XML потрібні для того, щоб передавати в комп’ютер структуру типу XML-документа. Розглянемо наступні два фрагменти XML-коду:


<vehicle name='Harley Davidson' type='motorcycle'>
   <wheel name='Front Tire'/>
   <wheel name='Rear Tire'/>
   <HeadLight name='Front Lamp' />
   <kickstand/>
</vehicle>

<vehicle name='Mitsubishi 3000 GT' type='motorcycle'>
   <wheel name='Front Right Tire'>
   <wheel name='Front Left Tire'>
   <wheel name='Rear Right Tire'>
   <wheel name='Rear Left Tire'>
   <HeadLight name='Front Right lamp'>
   <HeadLight name='Front Left lamp'>
   <SunRoof/>
</vehicle>

Будь-яка людина може легко зрозуміти ці два XML-приклад, проаналізувавши слова, які використовуються для опису їх компонентів. Він також може перевірити, чи відповідають ці документи набору правил, що визначають, як можуть використовуватися елементи vehicle. Наприклад, очевидно, що наступний XML-документ є неприпустимим:


<vehicle name='Harley Davidson' type='motorcycle'>
   <wheel name='Front Tire'/>
   <SunRoof/>
</vehicle>

Цілком зрозуміло, що у звичайного мотоцикла (motorcycle) – два колеса і немає даху з люком (sunroof). Тим не менш, для частини програмної логіки необхідна схема XML, за якою перевіряється допустимість конкретного XML-документа.

Перевірка допустимості – ключовий етап передбачуваної та ефективної обробки реальних XML-документів. Знання структури XML-документа позбавляє розробника від необхідності вводити в додаток додаткову логіку. Як тільки стає відомо, що документ належить певному класу, можна зробити ряд припущень про його структуру.

Опис типу документа (DTDs)

Опис типу документа (DTDs, Document Type Definitions) були першим стандартним механізмом, використовуваним для перевірки допустимості, і, за великим рахунком, залишаються їм до цього дня. Вони визначають роль і структуру XML-елементів та описуються за допомогою синтаксису, що відрізняється від застосовуваного в XML. Щодо перевірки допустимості вони покладаються на пост-обробку. Для простих схем XML – DTDs цілком достатньо. Однак, DTDs – це крок назад, якщо говорити про направлення розвитку XML-технологій: DTDs не підтримують простору імен і використовують синтаксис, відмінний від прийнятого в XML.

Найбільш серйозний недолік DTDs – відсутність підтримки простору імен, які є вкрай потужною стороною XML. Неможливість перевіряти визначений за допомогою DTD XML-документ, що містить простору імен, не дозволяє розробникам додатків використовувати простору імен в бізнес-логікою.

Більшість XML-технологій (RDF, XSLT і Xlink), а також мови опису схем (RELAX, XML Schema, SOX) представляються як XML. Це однаковість сприяє легкості у вивченні цих підходів. Це означає, що розробники можуть застосовувати існуючі інструментальні засоби XML. Таким чином, DTDs – це перешкода для програмістів, оскільки для того, щоб визначати свої схеми XML, вони повинні вивчити додатковий синтаксис. Але цим справа не закінчується – використання DTDs має більш серйозні обмеження.

DTDs в деякій мірі обмежені у виразності, отже, їх неможливо використовувати для перевірки допустимості деяких структур XML-документа. Наприклад, для наступного XML-документа:


<TennisMatch tournament='US Open'>

 <Competition type='Doubles' gender='Female'>

   <Player name='Venus Williams'/>

   <Player name='Serena Williams'/> ....

   <Player name='Martina Hingis'/>

   <Player name='Lindsey Davinport'/>

 </Competition>

</TennisMatch>


з DTD було б неможливо оголосити, що елемент Competition може мати тільки парне число елементів Player. Розглянемо ще один приклад:



<shortStory author='AUTHOR1'>
  <character name='CHARACTER1'/>
  <character name='CHARACTER2'>
</shortStory>

<anthology author='AUTHOR1'>
  <shortStory>
    <character name='CHARACTER1'/>
    <character name='CHARACTER2'>
  </shortStory>
</anthology>

Для подібного документа в DTD неможливо завдання наступного обмеження: елемент shortStory може містити атрибут author, Тільки якщо він не є спадкоємцем елемента antholog.

Ці недоліки DTD не залишилися непоміченими: зараз фахівці консорціуму W3C розробляють мову XML Schema (зараз він має статус робочої Рекомендації W3C), який володіє більшою виразністю і потужністю в порівнянні з DTDs. Мова XML Schema є XML-додатком і, очевидно, стане стандартним способом формального оголошення схем XML. Тим не менш, варто звернути увагу на RELAX (REgular LAnguage description for XML, Регулярний мова опису XML), альтернативний мову опису схеми, розроблений Мурата Макото (Murata Makoto). Технічний звіт про цю мову був представлений на розгляд Міжнародної організації стандартизації (International Standardization Organization). У попередніх статтях XML.com вже розповідалося про RELAX. Поки XML Schema не буде схвалений як стандарт опису схеми, використовуються інші альтернативи, такі як RELAX і Schematron (вони будуть застосовуватися і після того, як це станеться). На мою думку, Schematron – найбільш обіцяє з них.

Введення в Schematron

Створений Ріком Джеліффом (Rick Jelliffe), Schematron визначає правила та перевірки, які застосовуються до конкретного XML-документу. В Schematron реалізований унікальний підхід щодо схем в тому сенсі, що він зосереджується на перевірці допустимості конкретних документів, а не на оголошенні схеми (на відміну від інших мов опису схем).

Для опису цих правил і перевірок Schematron практично цілком покладається на моделі запитів XPath. Для обробки дуже складних XML-документів за допомогою всього лише підмножини XPath можна створювати потужні таблиці стилів XSLT.

Перш ніж заглибитися у вивчення Schematron, давайте подивимося, як легко використовувати XSLT для перевірки XML-документів. Повернемося до попереднього прикладу:


<shortStory author='AUTHOR1'>

  <character name='CHARACTER1'/>

  <character name='CHARACTER2'>
</shortStory>

<anthology author='AUTHOR1'>
  <shortStory>
    <character name='CHARACTER1'/>
    <character name='CHARACTER2'>
  </shortStory>
</anthology>

Можна створити шаблон, який буде повертати “Invalid XML” (“Неприпустимий XML”), якщо елемент shortStory має атрибут author, Коли він міститься в елементі anthology.


<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl=
 "http://www.w3.org/1999/XSL/Transform">
  <xsl:template match='shortStory'>
    <xsl:if test='../anthology and @author'>
      Invalid XML
    </xsl:if>
  </xsl:template>
</xsl:stylesheet>

Неважко придумати інші комбінації шаблонів, які перевірятимуть більш складні структури XML. По суті, саме так і працює Schematron. Він бере опис схеми Schematron (на XML), яке визначає обмеження. Таблиця стилів Schematron XSLT перетворює це в іншу таблицю стилів, перетворюючи за допомогою цієї результуючої таблиці стилів конкретний документ, а потім виконує перевірку допустимості цього документа.

Структура документа Schematron

XML-документ Schematron складається з елемента schema в просторі імен Schematron: http://www.ascc.net/xml/schematron. Елемент schema містить один або більше елементів pattern. Елементи pattern дозволяють користувачеві логічно групувати обмеження схеми. Ось кілька прикладів логічної угруповання: Text Only Elements (Тільки текстові елементи), Valid Root Element (Допустимий кореневої елемент), Check for ID Attribute (Атрибут перевірки ID).

Елементи pattern мають атрибут name. Вони також мають атрибут see, Який звертається до URL за користувальницької документацією по цій схемі.

Правила (Rules)

Елементи rule визначають сукупність обмежень, що накладаються на приватний контекст конкретного документа (наприклад, на елемент або сукупність елементів). Це дуже схоже на шаблони XSLT, які ініціюються по відношенню до вузла або групі вузлів, повернутих виразом XPath. У таблиці стилів XSLT, яку ми визначили вище:



<xsl:template match='shortStory'>

атрибут match змушує XSLT-процесор оцінювати вираз XPath shortStory, А потім піддавати обробці шаблон, що відноситься до елемента shortStory. Вміст елемента перевірки (rule) функціонує в межах контексту елементів, зіставлених за його атрибуту context.

Елементи перевірки можуть містити елементи assert і report. Ці елементи обробляються в залежності від оцінки XPath їх атрибута test. Єдина відмінність між ними полягає в тому, що елементи assert піддаються обробці, якщо вираз XPath видає брехню (false), а елементи report – Якщо отримано значення істина (true) (Загалом, елемент assert задуманий для визначення помилок; елемент report можна використовувати для повідомлення про позитивні властивості конкретного документа).

Механізм assert / report подібний елементу XSLT xsl:if з розглянутим вище таблиці стилів, – він також має атрибут test, Який визначає, обробляється чи в результуючому XML-дереві вміст елемента xsl:if.

Зверніть увагу на те, що вузол може бути тільки контекстом одного правила (Перше правило зіставлення, з яким стикається процесор) в межах моделі. Проте, вузол може багато раз зіставлятися в межах різних моделей. Таким чином, угруповання моделей мають величезне значення. Кожне зіставлення контекстного сайту може вважатися окремим обмеженням.

За допомогою цих елементів автори схем Schematron можуть забезпечувати функціональну (і зрозумілу людині) зворотний зв’язок щодо неприпустимих XML-документів. Завдяки зворотного зв’язку, яка визначається користувачем, унікальний підхід Schematron є більш потужним механізмом оголошення схем в порівнянні з іншими мовами опису схем.

Нарешті, елементи assert і report мають елемент name, Який застосовується для підстановки в вихідний потік імені елементу. Цей елемент name має факультативний атрибут path, Який повертає вузол, ім’я тега якого буде вставлено на місце елемента name. Якщо атрибут path не вказано, замість нього використовується ім’я поточного контекстного вузла. Цей елемент часто використовується елементами assert і report для ідентифікації імені тега елемента-порушника (offending element) в межах верифікаційного повідомлення.

Посилений XPath

Міць Schematron – у використанні виразів XPath. В результаті, до XML-документами можна звертатися із запитами по потужним моделям, забезпечуючи перевірку допустимості обмежень, які неможливо оголосити в DTDs. Давайте розглянемо виділені блоки моделі “Структурна перевірка допустимості” (Structural Validation) в RSS Schematron.


<?xml version="1.0"?>
<schema xmlns="http://www.ascc.net/xml/schematron">
 <pattern name="Structural Validation">
  <rule context="rss">
    <assert test="@version">
      An RSS version identifier should be supplied
    </assert>

Тут контекст правила (rule context) – елемент rss. Елемент assert за допомогою виразу XPath @version перевіряє присутність атрибута version. У випадку, якщо зіставляється елемент rss не має атрибута version, Обробляється вміст елемента assert, Тобто, у вихідний таблиці стилів створюється текстове повідомлення, що повідомляє користувача про необхідність ідентифікатора version.


<report test="@version != 0.91">
  This Schematron validator is for RSS 0.91 only
</report>

У цьому прикладі вміст елемента report обробляється тільки тоді, коли вираз test видає значення істина. В цьому випадку, Schematron перевіряє номер версії відмінний від 0.91.


<assert test="count(channel) = 1">
  An RSS element can only contain a single channel element
</assert>

А це більш складне обмеження. Воно перевіряє, чи має контекстний вузол (в даному випадку /rss) Тільки один елемент channel. Вираз test використовує функцію XPath count, Одну з багатьох потужних функцій XPath, доступних в Schematron.


<rule context="title|description|link">
  <assert test="parent::channel or parent::image
      or parent::item or parent::textinput">
    A <name/> element can only be contained with a
    channel, image, item or textinput element.
  </assert>
  <report test="child::*">
    A <name/> element cannot contain sub-elements,
  &nb
    remove any additional markup
  </report>
</rule>

Контекстний вузол елемента rule в цьому прикладі – елемент title, description, Або link. Елемент assert контролює, що батько контекстного вузла – channel, image, item, Або textinput. Для перевірки використовується осьової специфікатор (axis specifier) ​​parent.

Елемент report забезпечує, що ні елемент title, description, Ні link не містять дочірнього елемента. Для цього використовується осьової специфікатор child.


rule context="image">
 ...
  <assert test="count(width) = count(height)">
    Width and Height elements should be balanced
  </assert>
</rule>

Ось ще один приклад використання функції count для установки обмеження. І ще один випадок, коли DTD не зміг би висловити це обмеження для перевірки допустимості.


<rule context="width">
  <assert test="preceding::height or following::height">
    A width should be accompanied by a height
  </assert>
</rule>

Нарешті, з цього прикладу просто видно, що Schematron може перевіряти. Елемент assert використовує осьові специфікатори XPath preceding і following для того, щоб встановити, супроводжує чи елемент height елемент width у разі появи останнього. І знову Schematron вдається до потужних функцій XPath для опису обмежень, що накладаються на схему.

Запускаючи схему Schematron

Після того як схема Schematron визначена, таблиця стилів Schematron XSLT використовується для перетворення цієї схеми в верифікуються таблицю стилів. Потім з метою перевірки допустимості ця таблиця стилів може застосовуватися до XML-документами. Існує ряд таких таблиць Schematron, кожна з яких має певну функціональністю. Ви можете познайомитися з цими таблицями стилів, заглянувши на web-сайт Schematron.

Schematron-basics генерує таблицю стилів, яка просто повертає текстовий вихід Schematron (текст складається з елементів assert і report). Як видно з назви, це найпростіша таблиця стилів.

Schematron-message генерує верифікуються таблицю стилів, яку можна використовувати XSLT-процесором, який знає, як обробляти елементи xml:message і посилати їх в стандартний висновок. Ця таблиця використовується головним чином спільно з інтерактивними редакторами, такими як Emacs та XED, для перевірки допустимості конкретного XML-документа під час його редагування.

Schematron-report і schematron-pretty генерують веріфіціруют таблиці стилів, які формують форматовані повідомлення HTML. Schematron-report створює вихід у вигляді двох кадрів. Перший кадр містить пов’язані гіперпосиланням повідомлення про помилку, організовані моделлю. Нижній кадр відображає фрагменти-порушники у вихідному XML, що відповідають обраному повідомленням про помилку. Ця таблиця стилів дозволяє інтерактивно аналізувати помилки перевірки допустимості конкретного XML-документа, вона особливо зручна, коли початковий XML великий для того, щоб його переглядати окремо.

Нарешті, schematron-xml генерує XML-повідомлення про перевірку допустимості. Ці елементи мають атрибут location, Що містить висловлювання XPath, які оцінюють елементи-порушники. Ця таблиця стилів Schematron дозволяє користувачам включати перевірку допустимості Schematron в існуючу логіку XML-додатків.

Крім прикладу RSS Schematron є ще кілька широко використовуваних схем XML, написаних на Schematron, наприклад, схема представлена ​​на ресурсі Дена Конноллі (Dan Connolly) Web Content Accessibility Checking Service. Це сервіс, який, використовуючи приклад WAI, перевіряє Web-сторінки у відповідність з Інструкціями по доступності Web-вмісту (Web Content Accessibility Guidelines).

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


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

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

Ваш отзыв

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

*

*