Управління перерахуваннями в w3c xml-схемах

При роботі з орієнтованим на дані XML часто потрібно оперувати "керованими словниками", відомими також як перераховуються величини. Давайте розглянемо наступний приклад банківського узагальненого рахунку:

У цьому документі присутні два керованих словника. Перший - це словник валют, трехсімвольний код валюти по ISO-4217 ( "USD" - це долар США). Другий - це правило округлення (rounding) відсотків: "up" (в бік збільшення), "down" (в сторону зменшення) і "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: ізолювання мінливих керованих словників

Проте, навряд чи було б припустимо переписувати додаток, щоб відпрацьовувати зміна в наборі кодів валют, в іншому випадку це свідчило б про негнучкості розробки. Оскільки ці коди управляються ззовні, їх необхідно ізолювати: створимо для них окрему схему словника. Схема словника - це схема, яка містить єдине визначення простого типу з переліком величинами і більше нічого. Така схема, позначена як iso3currency-1.0.xsd. матиме такий вигляд:

Відповідно до правила позначення, ця схема названа accountSummary-1.1.xsd. Зверніть увагу на відсутність кодів валют в основній схемі.

Крок 3: розв'язання керованих словників

Складність з accountSummary-1.1.xsd полягає в тому, що вона безпосередньо імпортує iso3currency-1.0.xsd. Так, при появі нової версії схеми словника валют ISO, як і раніше потрібно випускати нову редакцію схеми узагальненого рахунку. Потрібен механізм розв'язання версій схеми словника від версій основної схеми. Просте рішення - скористатися "прохідний" схемою словника, що не має версії:

У цієї схеми, позначеної як iso3currency.xsd. відсутня атрибут version. Для завершення розв'язання схем випускається нова версія основний схеми, accountSummary-1.2.xsd. - єдине її відмінність від версії 1.1 полягає в тому, що елемент змінився з

щоб включити не має версії схему словника валют. Так виконується розв'язання схем. Якщо організація ISO змінює список кодів валют, виходить нова схема валют і коригується iso3currency.xsd. щоб вона імпортувала цю нову схему валют. Основна схема залишається без змін, оскільки вона містить iso3currency.xsd і не залежить від версії схеми словника валют.

Крок 4: захист додатків

Подібне розв'язання схем словників не позбавлене складнощів. По-перше, у міру того, як будуть з'являтися нові версії схеми словників валют, існуючі файли примірників стануть неприпустимими, якщо в них містяться коди валют, які були видалені ISO. У деяких випадках така ситуація неприйнятна, але для нашого прикладу це можливо. Якщо файл примірника посилається на код валюти, який вже не існує, він стане семантично неприпустимим; йому також ніщо не заважає виявитися синтаксично неприпустимим. Тоді можна скористатися синтаксичної неприпустимістю, щоб виявляти такі екземпляри і направляти їх для спеціальної обробки, щоб код основного додатка зміг займатися допустимими кодами валют. Прибравши обробку помилок з основного додатка, можна скоротити код основного додатки і спростити його супровід.

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

Нарешті, по-третє, використання подібних схем словників допустимо тільки в тому випадку, якщо зміни, що вносяться до них, зводяться або до додавання перераховується величини, або її видалення.

Структура схем словників не повинна змінюватися ні за яких умов. Якщо в схему словника було б додано нове визначення простого або складного типу або елемента, це могло змінити результати перевірки допустимості примірника по основній схемі і привести до збою в роботі базового програми. Таким чином, необхідно "перевіряти на допустимість" схеми словників, щоб бути впевненим, що вони містять тільки одне визначення простого типу з переліком величинами. Саме таку ситуацію описав Уїлл Провост (Will Provost) в своїй статті "Робота з метасхемой" ( "Working with a Metaschema").

Щоб в середовищі Windows перевірити на допустимість схему словника за цією схемою Schematron, ви можете скористатися безкоштовним валідатором від Topologi (free validator from Topologi). Відносно інших платформ, дивіться список інструментальних засобів в Довіднику ресурсів Schematron (Schematron Resource Directory). Більш детальну інформацію про Schematron можна знайти в статті Чімезі Огбуджі (Chimezie Ogbuji) "Перевірка допустимості за допомогою Schematron" ( "Validating XML with Schematron").

Твердження в Schematron виражаються за допомогою виразів, значенням яких повинна бути true. Якщо їх значенням виявляється false. генерується помилка перевірки допустимості по Schematron. При розгляді нашої схеми Schematron варто відзначити наступне:

Зверніть увагу на правило для контексту schema. Воно містить твердження, які застосовуються до елементу в схемі словника. Перше твердження контролює, що єдине, що міститься в схемі, це визначення . Друге твердження контролює, що є присутнім тільки одне визначення .

Правило для контексту simpleType стверджує, що, по-перше, у повинен бути атрибут name, а, по-друге, повинен містити і може включати . але більше ніяких інших елементів.

Правило для контексту restriction стверджує, що > Має містити одну або більше перераховуються величин.

Правило для контексту enumeration стверджує, що перераховуються величини повинні бути унікальні. Щоб перевірити це, використовується ключ Schematron (еквівалентний ключу XSLT). Вираз key ( 'enumerationsByValue', @value) повертає список елементів з таким самим значенням, як і перевіряється на допустимість елемент. Якщо ці величини унікальні, то в цьому списку буде присутній тільки один елемент . той, який перевіряється на допустимість.

висновок

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

Файл з прикладами, наведеними в цій статті можна скачати у вигляді ZIP-архіву (9 кБ).

Схожі статті