Schemarama

В этот раз мы возвращаемся к прежней рубрикации раздела, посвященного
технологиям программирования. Причиной этому стало весьма интересное событие, а
именно - обсуждение преимуществ различных подходов к описанию схем и языков
описания схем, состоявшееся в конце января-начале февраля в конференции на
XML.org. Данный материал
представляет собой обзор мнений, высказанных в ходе этого обсуждения. В статье
даны описания преимуществ как метода, основанного на правилах, так и
грамматического метода. Вниманию читателя предлагается "репортаж с места
событий", отражающий различные аспекты проблемы с точки зрения
разработчиков.

В течение последней недели XML-DEV служил ареной серии интересных и новаторских дискуссий относительно схем в целом, а также специфических языков описания схем. Перед вами обзор этой дискуссии, опубликованный на страницах XML-Deviant сайта XML.com.

Грамматика против правил

Большинство языков описания схем при определении ограничений схемы полагаются на регулярную грамматику, фундаментальную парадигму этих языков. Единственным исключением является Schematron, выпущенный Риком Джелиффом (Rick Jelliffe). Schematron отказывается от применения регулярной грамматики, заменяя ее системой, основанной на правилах и использующей выражения Xpath для определения утверждений, применяемых к документам. Более подробную информацию о происхождении Schematron можно найти в последнем из опубликованных на XML.com документов ( "Validating XML with Schematron"). Джелифф предположил, что критика различных парадигм может пролить свет на то, какая из них является наилучшей. Именно с этого предположения начался последний раунд дискуссии по схемам на XML-DEV. Джелифф сказал:

Я полагаю, сторонники различных парадигм схем (как основанных на грамматике, так и систем, основанных на правилах) стремятся обосновать полезность своих подходов. Когда у нас была только грамматика, этот вопрос был спорным. Сегодня мы имеем Schematron и другие основанные на правилах схемы, ... И я думаю, мы можем осмелиться приступить к критике грамматики-как-схемы (grammars-as-schemas). (Безусловно, это будет улица с двусторонним движением).

...Можем ли мы сделать высокоуровневые языки описания схем быстрее с помощью полного отказа от грамматической парадигмы и расматривать схему как систему упорядоченных логических утверждений?

XML не имеет внутренних ссылок, как в SGML, и разделителей, так зачем же ему нужно основанное на грамматике моделирование контента?

Комментарии Джелиффа вытекают из наблюдения сложностей или невозможности моделирования ряда ограничений с помощью регулярной грамматики. В качестве примера часто приводят смежные ограничения (если элемент имеет атрибут A, он должен иметь и атрибут B) и контекстно-зависимые модели контента (если элемент имеет родителя X, он должен иметь атрибут Y).

Далее Джелифф упомянул, что альтернативные подходы не рассматривались при проектировании W3C XML Schemas.

Насколько я знаю, решение использовать грамматику в XML Schema было принято абсолютно вслепую. Да и как еще оно могло быть принято, если не было проведено никакой дискуссии? Таким образом, практичность схем, основанных на грамматике ничем не лучше ручного плуга - да, конечно, с его помощью нам удается делать замечательные вещи, которые не могли бы делать без него, но ... Если мы знаем, что XML-документы - это графы, почему мы ведем себя так, будто они представляют собой деревья? Почему у нас есть языки описания схем, навязывающие нам древо-подобный синтаксис вместо того, чтобы служить слоем, освобождающим нас от этого?

Слова Джелиффа вызвали весьма различные отклики. Но, хотя большинство были большими приверженцами подхода, основанного на правилах, в целом и Schematron'а в частности, мало кто был согласен полностью отказаться от грамматики. Джеймс Кларк (James Clark), создатель недавно вышедшего языка описания схем TREX, в своем ответе отметил следующее:

Почему один вид схем должен быть лучше другого? Это также бессмысленно, как утверждать, что молоток лучше пилы. Все это зависит от проблемы, которую вы хотите решить.

Грамматика лучше, чем системы, основанные на правилах, по одним причинам. Системы, основанные на правилах, лучше грамматики по другим. Если что-либо можно просто выразить с помощью грамматики, возможно, это неплохая идея - использовать в этом случае именно грамматику, поскольку, помимо всего прочего, с ее помощью это может быть реализовано весьма эффективно. Если же это что-то не может быть выражено достаточно просто с помощью грамматики, тогда используйте систему, основанную на правилах.

Джо Инглиш (Joe English) также согласился с тем, что основанные на грамматике языки не должны изыматься из обращения.

Я думаю, что полезность схем, основанных на грамматике, уже всеми признана. И то, что существуют вещи, которых они не могут делать, вовсе не означает, что то, что они *могут* - бесполезно.

Суммируя основные различия между двумя парадигмами, Джелифф еще раз отметил, что системы, основанные на правилах, более выразительны.

Я не пытаюсь сказать, что Schematron намного мощнее, чем RELAX или TREX, поскольку они моделируют различные вещи. Я говорю о том, что структуры, которые могут моделироваться системами, основанными на правилах, лучше, чем те, что могут моделироваться системами, основанными на грамматике. Я не говорю сейчас о предшествовавшей им обработке контекста исключительно на основе правил: нет оснований для того, чтобы некий набор данных должен бы был формировать дерево, а не граф, и поэтому нет причин для того, чтобы некоторые данные или структура в одной части документа не могла бы ограничивать данные в другой его части каким-либо существенным образом.

Уникальной функциональной характеристикой Schematron является его ориентированный на пользователя подход, предоставляющий механизм обратной связи для каждого утверждения. Это дает возможность описывать в схеме различные модели и обеспечивает хорошую управляемость. Действительно, проведенное недавно сравнение шести языков описания схемы подчеркивает, насколько значительно Schematron отличается своим дизайном.

Итак, дискуссия перешла в область сравнения ряда языков описания схем. Рик Джелифф обосновал свою интерпретацию различий в подходах TREX, RELAX, XML Schemas и Schematron:

В основу созданного Мюрата-сан RELAX, как представляется, заложена необходимость начинать с необходимых web-документу свойств: легкости, модульности и способности функционировать даже в условиях, когда схема недоступна (в отсутствие PSVI). Я думаю, что основой TREX Джеймса Кларка является способность поддерживать множественность описаний, когда мы имеем достаточно мощный низкоуровневый язык схемы, в который легко переводятся остальные языки. Я полагаю, что базой W3C XML Schemas служит требование (хотя, возможно, и напрасное) некоторого уровня свойств и монолитности ввиду необходимости поддержки большого набора задач и гарантий отсутствия обработчиков отдельных элементов (допустимость всегда должна означать именно допустимость); но, как бы там ни было, обработчики монолитны, а схемы фрагментированы пространствами имен. В основе Schematron лежит необходимость моделирования сильносвязанных направленных отношений в наборах данных и игнорирования слабых, и в изменениях ограничений на протяжении всего существования документа, и в том, что предложения естественного языка могут быть более ясными, чем грамматика.

Обобщение, сделанное Джеймсом Кларком относительно преимуществ TREX по сравнению с W3C XML Schemas, также стоит того, чтобы прочитать его полностью. TREX, как и Schematron, представляет собой очень простой, хотя и мощный, язык описания схем.

Категории языков описания схем

Помимо различий между правилами и грамматикой, дискуссия охватывала и другие направления категоризирования языков описания схем, "послойно" рассматривая преимущества наиболее полезных свойств каждого из них.

Рик Джелифф разделил языки описания схем на две категории: "maps" (карты) и "routes" (маршруты).

Я думаю, что существует две категории схем, а, следовательно, и языков их описания: одна стремиться выразить, что истинно во всех данных данного типа во все моменты времени (например, для хранения и требований 80/20), а другая пытается выразить то, что отличает эту конкретную информацию в этот конкретный момент времени и в конкретном контексте от других данных того же типа. Одна старается обобщить различные варианты, другая стремиться найти абстракции для выражения этих вариантов.

Первый вид представляет собой карту, второй - маршрут. Первый вид подходит для автоматически генерируемых интерфейсов и для грубой проверки допустимости, второй необходим для ввода данных и отладки всех данных в целом. (Согласно существующему положению дел, я не уверен, что XML Schemas и DTD уделяют много или хоть сколько-нибудь внимания этой второй разновидности схем: возможно, TREX и RELAX делают что-то в этом направлении, и я надеюсь, что Schematron ближе к другому концу спектра).

Эрик Ван дер Влист (Eric van der Vlist) предположил, что существует четыре типа языков описания схем, с категориями, охватывающими структуры, типы данных, правила и семантику. Ван дер Влист заметил, что наилучшая их комбинация зависит от конкретного приложения, и нет одного самого лучшего языка описания схем.

Пытаясь уточнить категоризацию, предложенную Эриком Ван дер Влистом, Юч Огбуджи (Uche Ogbuji) сказал:

Я бы возможно переформулировал первую и третью категории Эрика как "структурные модели" и "структурные правила". Тонкость состоит в том, что первый вариант использует язык описания моделей (pattern language) и обработка представляет собой бинарный результат соответствия источника этим моделям. Последний вычисляет обобщенные выражения относительно источника, и результатом является действие. Одним из возможных наборов действий может быть принятие или отказ от источника соответственно его допустимости.

...Похоже, моя версия расположения предложенного Эриком такова:

• Структурные модели - DTD, TREX, RELAX, контентная модель Xschema
• Типы данных - типы данных XSchema, UML/XMI
• Структурные правила - Schematron
• Семантика - RDF(S)?, XMI?, UREP?, eCo?

Джеймс Кларк согласился, что послойное рассмотрение является полезным подходом к рассмотрению XML-приложений.

В SGML, проверка допустимости не четко отделена от проверки грамматической разборки (парсинга). Я полагаю, это было существенной проблемой в SGML: вы не могли работать с SGML-документом, пока не он был проверен на допустимость сложным парсером. XML изменил это положение вещей, введя понятие формальной правильности, отделившей проверку допустимости от проверки синтаксиса. У меня нет намерения углубляться в подробности этого разделения: ряд логически разделяемых задач были объединены в проверке допустимости. Например, для обслуживания атрибутов по умолчанию, объявленных во внешних DTD, требовались парсеры, проверяющие допустимость, тогда как непроверяющие допустимость парсеры были не нужны. От этого было больше проблем, чем пользы. Пользователи естественно хотят получать те же результаты вне зависимости от наличия проверки на допустимость, что означает, что им необходимы непроверяющие допустимость парсеры для выполнения всех действий, влияющих на набор данных и требующихся от проверяющих допустимость парсеров.

Дэн Брикли (Dan Brickley) также заметил, что Schematron является лидером в области отделения проверки допустимости от других аспектов определения схемы.

Как только у нас появится XML Query, многие приложения, которые, как некоторые надеялись, будут поддерживаться языками описания XML schema, будут гораздо проще реализовываться поверх обработчика запросов. По моему скромному мнению, Schematron проложил дорогу к этому. Все, что кто-то может описать для машины запросов, чтобы получить ответ, он может также предоставить и инструменту проверки допустимости данных для гарантии того, что его данные имеют правильную форму. Перегружать всем этим языки Schema, по моему скромному мнению, ошибочно, поскольку мы рискуем получить неразбериху в ограничениях основных структур основанного на XML формата данных и часто более строгих ограничений, которые мы хотим наложить при использовании формата данных в практических приложениях. Безусловно, все это применимо и к RDF.

Возможно, после нескольких лет построения XML-систем, настало время рационализировать среду XML, внеся в нее более ясный послойный технологический подход.

Смешение языков описания схем

Не до конца проникшись идеями метода, основанного исключительно на правилах, Эрик Ван дер Влист предположил, что наибольшую выгоду может принести комбинация обоих подходов.

Я не думаю, что было бы практично проектировать словарь только с использованием правил, поскольку пришлось бы написать множество правил только для простой структуры и если бы вы забыли бы хоть одно из них, в вашей проверке допустимости появился бы существенный изъян.

С другой стороны, инструменты, основанные на правилах, гораздо более гибки, чем типы данных или структурные языки описания схем (structure schema languages).

Одновременное их использование позволило бы сохранить лучшее из обоих и было возможно в "обоих направлениях":

1. Использование этой схемы и проверка этих правил, но при этом и
2. если это правило истинно - использовать эту схему

Затем он описал простую издательскую систему, созданную на базе этих принципов.

Джеймс Кларк рассуждал о том, как модели Schematron могут быть встроены в схему TREX.

Относительно TREX я могу предположить по меньшей мере несколько способов его интеграции с чем-то наподобие Schematron. Например, вы могли бы добавить к Schematron элемент <validate>, который встречался бы в качестве дочернего для <rule> в точности как <assert> и <report>. Семантикой было бы утверждение, что это дерево берет свое начало в контекстном узле, соответствующем модели TREX в элементе <validate>. Более продуманной возможностью было бы создание элемента верхнего уровня (т.е. дочернего для элемента схемы), определяющего названные модели TREX, затем добавление функции расширения XPath, тестирующей дерево, берущего свое начало из текущего узла, на соответствие конкретно названной модели; возможно, вам потребовалось бы еще несколько способов для создания необходимых сообщений о локализации ошибки относительно причин его несоответствия.

Кохсьюк Кавагучи (Kohsuke Kawaguchi) привел простой пример, демонстрирующий интеграцию Schematron-RELAX. Преобразование, реализованное в различных видах механизмов ограничений в рамках схемы Schematron, возможно и рассматривается также и для будущих версий Schematron. Дэн Брикли придумал ему прозвище "Schemarama".

Интересно, что, несмотря на то, что большое число обсуждений, имевших место за последние 18 месяцев, были сосредоточены вокруг удобства и полезности отдельных языков описания схем, в будущем, как ни странно, отводится серьезное место объединению языков и механизмов ограничений.

Производительность и показатели работы

Рик Джелифф добавил еще одно направление к обсуждению относительной эффективности различных реализаций языка описания схем.

...мне пришло в голову, что, возможно, существуют некоторые базовые вопросы, которые мы (те, кто реализуют схему, или проектировщики языка) можем задать и которые могут дать преимущество на начальном этапе отсутствия контрольных точек для оценки производительности:

- Есть ли какие-либо невинные на вид структуры, которые "взрываются" (или могут "взорваться") (возможно, это аналогично вопросу о том, нет ли каких-либо конструкций, падение производительности при применении которых происходит в большей мере, чем при использовании O(n)) и каковы обходные пути (например, в случае XML Schemas, для выявления несвязанных частиц в несвязанных группах выбора)?

- Как на применение схемы влияет невысокая скорость сети или недоступность сайтов (например, использование локального кэширования для предоставления пользовательских опций с целью улучшения насколько возможно проверки на допустимость даже в отсутствие некоторых компонент, и др.)?

В дополнение к предоставлению разработчикам необходимой обратной связи наилучшим образом, этот анализ может выделить ряд связанных между собой проблем для одной парадигмы схемы. И хотя некоторые из аспектов этой дискуссии могут показаться весьма загадочными для непосвященных и, возможно, не имеющими непосредственной связи со сложными в реализации нынешними системами, тем не менее, все еще остается ряд важных уроков, которые следует заучить. Например, относительно реляционных баз данных разработчики с трудом разобрались, что определенный запрос и конструкция схемы может создать эксплуатационные и даже еще более серьезные проблемы. XML все еще пребывает во младенчестве, и многие из аналогичных проблем все еще предстоит изучить. Исследования некоторых теоретических обоснований наших инструментов имеют важное значение для выделения и документирования

Автор: Лей Додд