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

Автор попытался провести исследование, которое позволит скомпилировать некий профиль 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-схемы нашли реальное практическое применение. Есть ли согласие во мнениях касательно наиболее часто используемых конструкций? Существуют ли особенности, которых проектировщики стараются избегать?

Для этого были собраны данных из 1400 схем, полученных от множества консорциумов. Цель состояла в том, чтобы выяснить, существует ли единый профиль 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-схемы

1414 рассмотренных схем показали очевидное стремление к упрощению. По крайней мере, где-то треть из них имела всего шесть структурных средств. И лишь в десяти и менее процентов случаев можно было наблюдать 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.