Профилирование XML-схемы

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

XML-схеме уже пять лет, из «новорожденного младенца» эта спецификация превратилась в довольно энергичного «юношу». Что же нам известно о нем? С самого начала было ясно, что явление это сложное. И действительно, исходные дебаты том, стоит ли сделать эту спецификацию Рекомендации, уже выявили проблему. (См. материалы  «Последнее слово» (Last Word) and «Опрос разработчиков XML-схем» (Questionnaire)Этот богатый инструментарий поставил перед разработчиками задачу выбора тех функций, которые им нужно (или не нужно) использовать. Если проанализировать, что фактически было реализовано, то можно дать какие-то рекомендации.

Автор попытался провести исследование, которое позволит скомпилировать некий профиль XML-схемы, основанный на известном на сегодняшний день опыте.

История вопроса

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

Концепция профиля XML-схемы обсуждалась уже несколько лет. В 2004-м году консорциум Web Services Interoperability сформировал рабочую группу для исследования идеи формального профиля XML-схемы. В результате консорциум W3C вынужден был провести симпозиум по пользовательскому опыту использования XML-схемы 1.0 (XML Schema 1.0 User Experiences), где данные из множества источников были объединены в один план действий. Недавно появился проект документа, где представлены шаблоны XML-схемы для привязки данных.

Кроме того, многие отраслевые консорциумы разработали руководства или шаблоны для разработки библиотек схем, согласно своему профилю. Изучив как формально, так и неформально многие из них, можно сделать вывод о допустимости или недопустимости тех или иных  возможностей XML-схемы. Появились и инструменты, помогающие в разработке профилей схем. Schematron  используется для добавления дополнительных ограничений, помимо тех, что уже есть в схеме. Mindreef's SOAPScope Server содержит подробно разработанную поддержку для создания настраиваемых профилей схем, предлагая стандартный список ограничений, которые налагаются в различных тестовых случаях. Однако сложно сказать, является ли этот профиль пригодным для межотраслевого использования.

Достоинства и недостатки

Первый шаг на пути изучения профиля – анализ схемы как таковой. Плюсы и минусы многих методов разработки схем нам, фактически, уже известны. Они описаны на вебсайте Best Practices Роджера Костелло (Roger Costello), который проделал огромную работу по сбору комментариев и мнений разработчиков, а также по объединению и анализу преимуществ и недостатков многих критериев проектирования. Разработчики схем уже несколько лет обращаются к его сайту.

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

Чем занимаются проектировщики схем?

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

Для этого были собраны данных из 1 400 схем, полученных от множества консорциумов. Цель состояла в том, чтобы выяснить, существует ли единый профиль xml-схемы, отражающий согласие практиков.

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

Источники

Рассматривались схемы следующих организаций:

• The Open Applications Group (OAGi)
• The Open Travel Alliance (OTA)
• Human Resources XML (HR-XML)
• Chemical Industry Data Exchange (CIDX)
• IMS Global Learning Consortium (IMS)
• Association for Retail Technology Standards (ARTS)
• Mortgage Industry Standards Maintenance Organization (MISMO)
• World Wide Web Consortium (W3C, including mathML)
• Global Justice XML
• ACORD

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

Инструментальная поддержка

Во многих зарекомендовавших себя инструментах поддержка XML-схемы обеспечивается на высоком уровне. В частности, интегрированные среды разработки (IDE) для редактирования схем предлагают достаточно средств поддержки даже для проблемных конструкций, таких как xsd:union. Проблема инструментальной поддержки может проявляться в двух формах:

• если принято решение не поддерживать выбранные конструкции схемы. Это усложняет формирование профиля.
• «специализированные» инструменты часто предлагают поддержку только для самых общих конструкций схем, в их первичном виде. По мере развития инструмента могут добавляться дополнительные конструкции. Автор данной публикации ведет блог, связанный с поддержкой xml-схем, где содержатся ссылки на несколько инструментов генерирования кода и опубликованных заявок на поддержку.

Результаты: Профиль XML-схемы

1 414 рассмотренных схем показали очевидное стремление к упрощению. По крайней мере, где-то треть из них имела всего шесть структурных средств. И лишь в десяти и менее процентов случаев можно было наблюдать 17 средств. Многие из неиспользуемых конструкций применяются только в очень специфических случаях.

Кроме упрощения, характерна эксплицитность схем. Она выражается в очень четком и ясном задании имен в отсутствии моделей со смешанным содержимым и абстрактными типами, в предпочтении конструкции xsd:sequence перед xsd:all.

Редко используемые конструкции (встречающиеся в схемах реже, чем в 10% случаев)

Перечисленные ниже функции либо не встречались вообще, либо использовались крайне редко.

• xsd:all: использование композитора xsd:all. Предпочтительно применять вместо него xsd:choice или xsd:sequence;
• финализация (finalizing): использование атрибутов @final или @finalDefault. Ни одна из протестированных схем не содержала таких атрибутов. Как правило, в схемах используются разрешающие конструкции, а не отменяющие (как эта);
• substitutionGroup: позволяет подставлять одни элементы в другие. В рассмотренных схемах такая возможность не использовалась, хотя является обычным механизмом расширения. Вероятно, ее отсутствие обусловлено характером рассмотренных схем. Схемы открытых стандартных отраслевых консорциумов могут обойтись и без нее, однако при внедрении организации могут использовать substitutionGroups для расширяемости;
• уникальность (Uniqueness): использование элемента unique требует, чтобы его содержимое отличалось от остальных элементов в пределах его области видимости. Казалось бы, это удобно, ведь потребность в уникальных идентификаторах вполне естественна. Однако, как выяснилось, в большинстве случаев для таких элементов используются строковые данные. Возможно, уникальность используется на бизнес-уровне передачи данных между системами;
• квалифицированные атрибуты (qualified attributes): использование конструкции attributeFormDefault="qualified". Она не применяется практически ни в одной схеме, хотя многие разработчики используют квалифицированные элементы;
• ключи (keys): использование элементов key и keyref;
• переопределение: использование элемента redefine для определения существующего компонента. Эта функция практически не поддерживается в инструментах. Можно сказать, что ее избегают.
• nillable: использование атрибута @nillable, обуславливающие использование xsi:nil в экземпляре, указывающее, что содержимое имеет значение null;
• block: использование атрибута @block для запрета производных;ограничение
• complexType: ограничение модели типом complexType. Несколько лет назад, в HR-XML, эту функцию рассматривали как возможность использовать генерализованный тип данных, который ограничивается в зависимости от контекста его применения. Однако эта конструкция оказалась громоздкой и плохо поддерживалась;
• абстрактные типы (аbstract types): использование конструкции abstract="true" на элементах или типах;
• mixed: установка атрибута mixed="true" позволяет комбинировать данные и дочерние элементы в одном месте. Разработчики схем четко разделили эти концепции на определенные типы;
• группы (groops): использование xsd:group позволяет определять группу для дальнейшего повторного использования. Однако такие элементы чаще всего употребляются с конструкцией "@ref", а не добавляются в группы;
• фиксированные значения (fixed values): использование атрибута @fixed на элементах, атрибутах или простых типах;
• отказ от использования  @targetnamespace: возможно, в дальнейшем связывании схем не будут использоваться конструкции @targetNamespace. Однако в большинстве протестированных схем они применялись. Более того, в некоторых руководствах их использование считается обязательным;
• отказ от объявления области имен по умолчанию (default namespace): отсутствие "@xmlns" областей имен по умолчанию. Возможно, в дальнейшем это ограничение войдет в силу. Однако в проанализированных схемах такие области имен применялись повсеместно;
• области имен по умолчанию не должны совпадать с @targetnamespace: такая ситуация возникает, когда области имен по умолчанию не соответствуют @targetNamespace. Однако в большинстве схем они имеют одно и то же значение. Это еще раз свидетельствует о тенденции к упрощению.

Часто используемые конструкции (встречаются, по крайней мере, в трети из рассмотренных схем)

Наиболее часто используемые конструкции XML-схем. Здесь также доминирует упрощение. Лучше всего начать проектирование схемы с этого набора.

• квалифицированные элементы пространства имен: использование конструкции elementFormDefault="qualified" для эксплицитности пространства имен элемента;
• xsd:sequence: использование элемента xsd:sequence. Это наиболее часто используемый композитор. Он рекомендуется вместо конструкции xsd:all, поскольку устраняет двусмысленные модели и дочерние элементы следуют в определенном порядке;
• расширение complexType : создание типа, которые расширяет другой тип, – одна из главных возможностей повторного использования и расширяемости;
• анонимные типы (anonymous types): используются в тех случаях, когда создаваемые типы имеют локальный масштаб и, следовательно, у них отсутствует атрибут @name. Это бывает очень часто. В инструментальных средствах анонимные типы не приветствуются, но практически везде есть их поддержка;
• ограничение simpleType : производное от simpleType, ограничивающее базовый тип;
• перечисления (enumerations): перечень значений  - одна из наиболее часто встречающихся конструкций.

Проблемы с инструментальной поддержкой

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

• attributeGroup: группировка атрибутов по имени для повторного использования; конструкция похожа на xsd:group. Эта конструкция встречалась в тестируемых схемах чаще, чем используется на практике. Во-первых, одна организация использовала ее очень часто, а многие другие – избегали. Во-вторых, в анализе учитывался xsd:attributeGroup как для объявлений, так и для повторного использования конструкции @ref. Поэтому, фактически, частота примененияattributeGroups может быть существенно меньше. В большинстве инструментов поддержка этой конструкции не слишком осложнена, но просто не имеет высокого приоритета;
• xsd:choice: использование композитора xsd:choice.Некоторые поставщики инструментов озабочены применением этой функции, поскольку ее сложно отобразить в виде программной конструкции. Однако используют ее часто;
• значения по умолчанию (default values): объявление значений по умолчанию для данных в XML-сущности. О них говорилось здесь;
• xsd:union: использование конструкции xsd:union для комбинирования типов в декларации. Эта функция XML-схемы реже всего поддерживается программными инструментами;
• шаблоны (pattern): Использование регулярных выражений, в частности, для подстановки строк;
• другие фасеты (facets): к ним относятся фасеты, отличные от шаблонов и перечислений, в том числе: minInclusive, maxInclusive, maxInclusive, minExclusive, whitespace, fractionDigits, length, minLength, maxLength . Поддержка в инструментах может различаться;
• списковые типы (list types): использование элемента xsd:list. Эта функция встречается только в 10% схем из тестовой выборки. Иногда не поддерживается программным инструментом, что может быть причиной проблем. Программисты часто жалуются на сложности с обработкой и синтаксическим анализом списковых типов. Предпочитают перечисления или отдельные типы данных.

Замечание по поводу групповых символов (wildcards)

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

Заключение

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

Приложение: данные

Данные, в представленных ниже таблицах, отражают результаты исследования. Они взяты с соответствующих сайтов (большинство из которых перечислено здесь). Рис. 1 – это итоговые результаты. На рис. 2 показано, какое количество схем содержит ту или иную конструкцию, а на рис. 3 – число раз, когда эта функция была встречена в той или иной схеме.

Рис. 1. Итоговые показатели

Рис. 2. Количество схем, где используются перечисленные конструкции

Рис. 3. Как часто встречаются данные конструкции

Замечания к рисункам

Несколько дублированных схемы не использовались в анализе, такие как схемы схем (XMLSchema.xsd), которые обычно распространяются со многими библиотеками. Ассоциация ACORD предлагает для своих схем отмену пространства имен.  В данном исследовании использовались только именованные версии. В тестовых файлах организаций  HR-XML и OAGi анализировались версии разработчиков или неавтономные версии.  И хотя в OAGi-схемах не применялись substitutionGroups, но проектирование глобальных элементов все-таки предполагает использование подстановок в качестве возможности расширения. Набор схем W3C включает mathML.

Автор: Пол Киль (Paul Kiel)