|
| ||||||||||||
| ||||||||||||
|
2003 г
Управление перечислениями в W3C XML-схемах
Автор: Энтони Коутс (Anthony Coates) ВведениеПри работе с ориентированным на данные XML часто требуется оперировать "управляемыми словарями", известными также как перечисляемые величины. Давайте рассмотрим следующий пример банковского обобщённого счёта:
В этом документе присутствуют два управляемых словаря. Первый - это словарь валют, трехсимвольный код валюты по ISO-4217 ("USD" - это доллар США). Второй - это правило округления (rounding) процентов: "up" (в сторону увеличения), "down" (в сторону уменьшения) и or "nearest" (ближайший). В нашем примере банк предпочитает округлять проценты в сторону уменьшения. Проблема, возникающая при проектировании этой схемы, заключается в том, что управление кодами валют ISO осуществляется вне нашего ведома. Эти коды могут быть изменены в любой момент времени, и если их встроили в схему, ее потребуется переиздавать всякий раз, как организация ISO меняет свои коды. А это может оказаться весьма накладным. Сказанное особенно справедливо в отношении предприятия, где любая модификация схемы, какой бы незначительной она ни была, может потребовать проведения полного тестирования приложения, использующего схему. В этой статье рассказывается, как можно управлять управляемыми словарями при использовании W3C XML-схемы (W3C XML Schemas), поскольку именно эта спецификация является основным форматом XML-схем для ориентированного на данные XML. Обратите внимание на то, что под "словарями" мы будем понимать перечисляемые списки значений элементов-атрибутов, что отлично от других контекстов, в которых "словари" - это наборы имен элементов XML. Шаг №1: монолитная схемаПрежде чем задуматься над тем, какой из управляемых словарей находится вне нашего контроля, первое, что необходимо сделать, это создать схему для обобщённых счётов, используя W3C XML-схему. В рамках этой статьи мы воспользуемся подмножеством трехсимвольных кодов валют ISO. Соответствующая схема будет иметь следующий вид:
Обратите внимание на два управляемых словаря (перечисления): простые типы iso3currency и roundingDirection - длина iso3currency явно установлена равной 3, чтобы избежать в будущем досадных опечаток при редактировании, когда потребуется корректировать список валют. Также стоит отметить, что значению факультативного атрибута version было задано значение "1.0". Дело в том, что при работе с ориентированными на данные XML-сообщениями, часто необходимо одновременно поддерживать многочисленные версии схемы сообщений, поскольку, по-видимому, невозможно одновременно "поднять" системы, использующие эту схему, до ее последней версии. Таким образом, крайне необходимо указать версию схемы, по которой проверялось на допустимость XML-сообщение. С учетом сказанного, мы обозначим нашу схему accountSummary-1.0.xsd, чтобы будущие версии не перезаписали текущую. Кроме того, для того, чтобы экземпляры сообщения четко идентифицировали свою версию схемы, к элементу accountSummary был добавлен атрибут version. Предполагается, что эти номера версии записываются как M.N, где M - это основной номер версии, а N - дополнительный. В результате, приведенный выше код для обобщённого счёта можно переписать следующим образом:
Шаг №2: изолирование изменчивых управляемых словарейПри работе с управляемыми словарями (перечислениями) в схемах, важно оценить степень изменчивости каждого словаря. Изменчивый словарь - это словарь, изменения которого, как предполагается, не связаны с выходом версий схемы. Стабильный словарь - это словарь, который меняется (если такое вообще происходит), только если появляются новые редакции схемы. Если изменчивые словари включены в схему, то это чревато возникновением проблем, поскольку они требуют выпуска дополнительных версий всех зависимых приложений. В нашем примере обобщённого счёта коды валют - это изменчивый словарь: они контролируются извне, международной организацией ISO, и ISO может добавлять или удалять валюты в любой момент времени. С другой стороны, набор правил округления {"up", "down", "nearest"}, вероятно, не будет меняться, поэтому он является стабильным словарем. Для человека, который осуществляет сопровождение приложения, оперирующего обобщёнными счётами, добавление нового правила округления означало бы написание, тестирование и внедрение новой версии этого приложения. Поэтому "политическое давление" привело бы к тому, что величины округления изменялись бы только как часть запланированного выхода редакции схемы. Таким образом, разумно оставить простой тип roundingDirection встроенным в эту схему. Тем не менее, вряд ли было бы допустимо переписывать приложение, чтобы отрабатывать изменение в наборе кодов валют, в противном случае это свидетельствовало бы о негибкости разработки. Поскольку эти коды управляются извне, их необходимо изолировать: создадим для них отдельную схему словаря. Схема словаря - это схема, которая содержит единственное определение простого типа с перечисляемыми величинами и больше ничего. Такая схема, обозначенная как iso3currency-1.0.xsd, будет иметь следующий вид:
Видно, словарь валют имеет свою собственную версию и, таким образом, период выхода очередной редакции. Эта схема словаря может быть включена в новую (1.1) версию основной схемы сообщения:
В соответствии с правилом обозначения, эта схема названа accountSummary-1.1.xsd. Обратите внимание на отсутствие кодов валют в основной схеме. Шаг №3: развязывание управляемых словарейСложность с accountSummary-1.1.xsd заключается в том, что она напрямую импортирует iso3currency-1.0.xsd. Так, при появлении новой версии схемы словаря валют ISO, по-прежнему требуется выпускать новую редакцию схемы обобщённого счёта. Необходим механизм развязывания версий схемы словаря от версий основной схемы. Простое решение - воспользоваться "проходной" схемой словаря, не имеющей версии:
У этой схемы, обозначенной как iso3currency.xsd, отсутствует атрибут version. Для завершения развязывания схем выпускается новая версия основной схемы, accountSummary-1.2.xsd, - единственное ее отличие от версии 1.1 состоит в том, что элемент <xsd:include> изменился с
на
чтобы включить не имеющую версии схему словаря валют. Так выполняется развязывание схем. Если организация ISO изменяет список кодов валют, выходит новая схема валют и корректируется iso3currency.xsd, чтобы она импортировала эту новую схему валют. Основная схема остается без изменений, поскольку она содержит iso3currency.xsd и не зависит от версии схемы словаря валют. Шаг №4: защита приложенийПодобное развязывание схем словарей не лишено сложностей. Во-первых, по мере того, как будут появляться новые версии схемы словарей валют, существующие файлы экземпляров сделаются недопустимыми, если в них содержатся коды валют, которые были удалены ISO. В некоторых случаях такая ситуация неприемлема, но для нашего примера это возможно. Если файл экземпляра ссылается на код валюты, который более не существует, он станет семантически недопустимым; ему также ничто не мешает оказаться синтаксически недопустимым. Тогда можно воспользоваться синтаксической недопустимостью, чтобы обнаруживать такие экземпляры и направлять их для специальной обработки, чтобы код основного приложения смог заниматься допустимыми кодами валют. Убрав обработку ошибок из основного приложения, можно сократить код основного приложения и упростить его сопровождение. Во-вторых, с учетом того, что коды валют могут менять в любой момент, необходимо обеспечить синхронизацию между кодами валют в схеме словаря валют и кодами валют, известным приложениям. Эту задачу можно решить двумя способами. В первом случае приложения могут воспользоваться схемой словаря как источником кодов валют. Если рассматривать схему словаря как XML-файл, быстрый SAX-парсер - это все, что требуется, чтобы вытащить элементы <xsd:enumeration>, содержащие допустимые величины. При втором подходе коды валют хранятся в центральной реляционной базе данных. Тогда приложения могут обращаться к ее таблице напрямую, а схема словаря может быть динамически генерироваться из этой же таблицы. Любой из описанных методов обеспечивает синхронность наборов допустимых величин по приложениям. Наконец, в-третьих, использование подобных схем словарей допустимо только в том случае, если изменения, вносимые в них, сводятся либо к добавлению перечисляемой величины, либо ее удалению. Структура схем словарей не должна изменяться ни при каких условиях. Если в схему словаря было бы добавлено новое определение простого или сложного типа или элемента, это могло изменить результаты проверки допустимости экземпляра по основной схеме и привести к сбою в работе базового приложения. Таким образом, необходимо "проверять на допустимость" схемы словарей, чтобы быть уверенным, что они содержат только одно определение простого типа с перечисляемыми величинами. Именно такую ситуацию описал Уилл Провост (Will Provost) в своей статье "Работа с метасхемой" ("Working with a Metaschema"). Очевидным решением было бы написание в качестве метасхемы схемы для схем словарей. На практике автор статьи не стал бы это делать. Известно, что существующая "Схема для схем" ("Schema for Schemas") не на все 100% верна при описании синтаксиса, и именно по этой причине редакторы схем используют ее в качестве справочного, а не нормативного руководства. По этой же причине, а также из-за того, что формат схемы словаря довольно простой, воспользуемся следующей схемой Schematron (Schematron schema):
Чтобы в среде Windows проверить на допустимость схему словаря по этой схеме Schematron, вы можете воспользоваться бесплатным валидатором от Topologi (free validator from Topologi). Касательно других платформ, смотрите список инструментальных средств в Справочнике ресурсов Schematron (Schematron Resource Directory). Более подробную информацию о Schematron можно найти в статье Чимези Огбуджи (Chimezie Ogbuji) "Проверка допустимости с помощью Schematron" ("Validating XML with Schematron"). Утверждения в Schematron выражаются с помощью выражений, значением которых должна быть true. Если их значением оказывается false, генерируется ошибка проверки допустимости по Schematron. При рассмотрении нашей схемы Schematron стоит отметить следующее:
ЗаключениеПоместив изменчивые управляемые словари (перечисления) в свои собственные схемы словарей, можно повысить управляемость W3C XML-схем. В этой статье было рассмотрено, как идентифицировать изменчивые управляемые словари, как отделять их от основной схемы, как развязывать версии и как проверять на допустимость схемы словарей. Разумеется, абсолютного рецепта - когда у управляемого словаря должна быть своя схема - нет. Поэтому применяя приведенные в этой статье рекомендации, всегда полагайтесь на здравый смысл и знание проблемной области. РесурсыФайл с примерами, приведенными в этой статье можно скачать в виде ZIP-архива (9 кБ). |
|
CITForum © 1997–2025