41475 (661643), страница 3
Текст из файла (страница 3)
var bookNode = doc. documentElement
Проте як же буде виглядати сам документ, що містить схему, зсередини? По-перше, він буде містити теги XML, що повідомляють, що це схема, на зразок:
... вміст схеми
Кожний пункт усередині схеми об'являється потім індивідуально, причому особливості кожного елемента розшифровуються за допомогою вкладених тегів, наприклад:
визначає елемент як здатний містити тільки текстові дані.
Подібні схеми можуть виявитися дуже важкі для читання, але вони легко піддаються розборові за допомогою інструментів XML. Іншими словами, вам не буде потрібно спеціальний редактор для роботи з документом XML Schema, як у випадку DTD.
У випадку правил на базі XML для форматів комерційних даних можна використовувати для відображення однієї схеми на другу вмонтовані функціональні можливості перетворення XML - розширювана мова таблиць стилів (Extensible Stylesheet Language, XSL).
На загальному рівні BizTalk Framework потребує, щоб видавці XML Schema притримувалися визначених рекомендацій. Так, тегам пропонується давати осмислені імена зі зрозумілим нескороченим написанням; ці імена повинні відповідати функціональному призначенню інформації, а не її місцю в приватній структурі даних (наприклад, “PartLocation” замість “PartFieldFourteen”), а інформація, що міститься в тегу, не повинна потребувати спеціального, відмінного від XML, декодування (наприклад, позначення валюти грошової суми повинно зберігатися у виді елемента XML, а не приєднуватися до суми як у “$30US”).
Необхідними складовими BizTalk Framework є спеціальні, загальні для всіх галузей теги XML. Ці теги покликані звільнити розроблювачів від турбот із приводу трьох найважливіших проблем взаємодії додатків. По-перше, від того, як дані передаються з одного додатка в інший; по-друге, від того, як “викликати” інший додаток - відправлення додатку даних у форматі XML повинно бути достатньо; по-третє, від того, у якому порядку повинні випливати елементи даних.
Один із тегів визначає код, за допомогою якого XML програма, що приймає дані у форматі, може встановити, що за схема BizTalk використовується. За допомогою інших тегів додаток може з'ясувати, хто є відправником даних, що відправник від нього хоче і кому дані повинні бути потім передані.
Для забезпечення сумісності документ BizTalk повинний починатися і, відповідно, закінчуватися тегом BizTalk, щоб одержувач знав, що він вступив у сектор BizTalk. Тег MsgType задає простір імен XML (вашу конкретну схему), що визначає припустимі елементи документа. Тому що ваша схема використовує формат даних XML, то тип даних, котрими ви наповняєте свій документ, буде легко встановити. Нарешті, ви можете також вставити блок маршрутних документів, наприклад:
locationType=”DUNS” process=”” path=”” handle=”3”/> locationType=”DUNS” process=”” path=”” handle=”23CF15”/> BizTalk Framework нічого не говорить про те, які дані повинні входити в чотирьох атрибута тегів і, вона просто встановлює призначення кожного з них. Теги location ідентифікують мережний вузол (можливо, за допомогою URL), куди направляється документ, у той час як теги process і handle визначають додаток і конкретний примірник (наприклад, номер транзакции), до якого відносяться дані. Тег path служить свого роду вмістилищем, де проміжні сервери можуть берегти відомості про дату й іншу інформацію, щоб маршрут (і за допомогою розширення зворотний маршрут) був видимий усім серверам уздовж шляху. Бізнес-модель BIZTALK Microsoft випустить серверний продукт для регулювання обміну BizTalk-сумісними повідомленнями XML між партнерами по бізнесу (бета-версія наприкінці осені 1999 року; готовий продукт повинний вийти після Windows 2000). Як це виглядає Інструкції в схемах складають набір правил, використовуючи який, програма-клієнт буде робити висновок про те, коректний документ або ні. Схема даних, наприклад, може виглядати таким чином: Якщо ми включимо приведені правила всередину XML- документа, програма-клієнт зможе використовувати їх для перевірки. Тобто, вона тепер зможе визначити, що правильним буде бути такий фрагмент: My computer My family My dog , а некоректним цей: My family My dog Sharik Всі конструкції мови схем описуються правилами "XML DTD for XML-Data-Schema". Область схеми даних Створюючи схеми даних, ми визначаємо в документі спеціальний елемент, ;, усередині якого містяться описи правил: Якщо використовувати окремий простір імен, то повний XML-документ, що містить у собі схему даних, буде виглядати в такий спосіб: Опис елементів Для визначення класу елемента, до якого надалі будуть застосовуватися інструкції, що описують його вміст і структуру, призначений спеціальний елемент схеми elementType, Елемент містить інформацію про черговий випуск часопису Назва елемента задається атрибутом id. Всі подальші інструкції, що ставляться до описуваного класу, визначають його внутрішню структуру і набір припустимих даних, містяться всередині блока, заданого тегами і . Як очевидно з приклада, при визначенні класу елемента, можна також використовувати коментар до нього, що заключають у тэги <descript> Атрибути елемента Для того, щоб в описі елемента визначити його атрибути й описати властивості цих атрибутів ми повинні використовувати елемент attribute: У даному прикладі елементу визначається атрибут src, значенням якого може бути будь-яка послідовність дозволених символів: Подібно DTD, схеми даних дозволяють встановлювати обмеження на значення і засіб використання атрибутів. Для цього в дескрипторі необхідно використовувати параметр atttype. Наприклад, якщо ми хочемо зазначити, що значення атрибута повинно використовуватися програмою-аналізатором як унікальний ідентифікатор, то нам необхідно створити таке правило: Якщо ж потрібно задати список можливих значень атрибута, то приклад будет виглядати в такий спосіб: Модель вмісту елемента Під моделлю вмісту в схемі даних розуміють опис усіх припустимих об'єктів XML- документа, використання котрих усередині даного елемента є коректним. Модель вмісту визначається інструкціями, розташованими всередині блока . Для цього правила коректним буде бути такий фрагмент документа: Психи і маніяки в Інтернет Вкладені елементи описуються за допомогою інструкції element, у якій параметром type указується клас об'єкта - посилання на його визначення: Якщо потрібно зазначити режим використання вкладеного елемента, то треба визначити параметр occurs: Можливі значення цього параметра такі: REQUIRED - елемент повинний бути обов'язково визначений OPTIONAL - використання елемента не є обов’язковим ZEROORMORE - вкладений елемент може зустрічатися декілька разів або жодного разу ONEORMORE - елемент повинний зустрічатися хоча б один раз Приклади правильних XML-документів, що використовують приведену вище схему: Навіщо він потрібний, XML? Іван Петров Що таке XML потрібний чи він нам або Навіщо він потрібний, XML? Що таке XML Крім елементів, вмістом XML-документа можуть також бути звичайним текстом і областями CDATA. Для позначення типів вмісту поточного елемента в схемах використовуються такі інструкції: - вказує на те, що вмістом елемента є тільки вільна текстова інформація (секція PCDATA) : - вказує на те, що вмістом елемента повинні бути тільки елементи, без тексту, незаключенного ні в один елемент: - будь-яке сполучення елементів і тексту - порожній елемент Приклад: Що в імені твоєму? Розширювана мова розмітки (Extensible Markup Language, XML) дозволяє вам створювати свої власні теги, документувати їх за допомогою визначень типів документів (Document Type Definition, DTD) або схеми XML і потім без проблем обмінюватися даними з іншими джерелами. Все це добре, але може виявитися, що інші використовують ті ж самі, що і ви, імена для елементів і атрибутів, але при цьому спираються на інші DTD. Це прямий шлях до проблем. Щоб уникнути подібних конфліктів W3C розробив концепцію просторів імен і ключового слова xmlns. Завдяки їм в одному документі можуть використовуватися імена елементів і атрибутів, що інакше вступили б у конфлікт один з одним. Тепер же вони різняться різними префіксами простору імен і визначаються по різноманітним DTD або схемах. От, наприклад, фрагмент коду XML із використанням просторів імен: “http://www.knowknew.com/ books.dtd” xmlns:storeb= “http://www.amazon.com/schema”> Network Magazine “Data Communications”> У визначенні DTD магазина А назва книги є піделементом часопису. У схемі магазина Б назва є атрибутом часопису. Завдяки розрізненню імен за допомогою різних префіксів просторів імен вони можуть застосовуватися разом. Місцезнаходження DTD і схеми вказується в даному прикладі за допомогою URL, але воно може також визначатися за допомогою Uniform Resource Name (URN, див. RFC 2141) або Uniform Resource Identifier (URI, див. RFC 2396). Використання для опису даних (Intelligent Enterprise, August 03, 1999, Volume 2, Number 11) Однією з особливостей XML, що привертає увагу промисловості, є можливість опису структур даних і даних, що зберігаються. З використанням XML можна визначити нові теги спеціально для опису еквівалента таблиць і стовпчиків (або сутностей і атрибутів) у структурі реляційної бази даних. Ще більш істотно те, що теги для набору стовпчиків або атрибутів можуть зв'язуватися з тегами для їхньої батьківської таблиці або сутності. Хоча теговая структура здається гарним механізмом для опису і розуміння структури бази даних, спосіб організації даних потребує як ніколи раніше суворої дисципліни. XML не забороняє мати повторювані групи, жахливі структури даних і т.д. OMG сформувала набір тегов, названий XML Metadata Interchange (XMI), із метою надання можливості опису в стандартних термінах структури даних про дані ("метаданих"). Цей стандарт буде корисний для обміну метаданими між CASE-засобами і для опису "репозиторія метаданих" у проектах сховищ даних. Рухаючись у тому ж напрямку, група компаній ( щовключає, зокрема, IBM і Oracle) знаходиться в процесі визначення Common Warehouse Metadata Interchange (CWMI), підмножини XMI для підтримки сховищ даних. Це означає, що є два підходи до опису структури бази даних на XML: По-перше, прикладну базу даних може описувати DTD XML-документа. У цьому випадку операційні дані бази даних можуть бути розміщені між наборами описаних тегів. Таке DTD може, наприклад, генеруватися одним CASE-засобом, а читатися іншим, забезпечуючи засіб передачі структури даних. По-друге, можна розмістити самі визначення таблиці і стовпчиків між тегами XMI, визначеними на більш високому рівні абстракції. Цей підхід трохи більш хитрий, оскільки метамодель XMI дуже абстрактна, але використання метамоделі XMI дозволяє описувати набагато більше, чим таблиці і стовпчики. Проте зауважимо, що проблема визначення репозиторія метаданих або обміну метаданими між CASE-засобами не пов'язаний із використанням XML або якогось іншої мови. Проблемою є структура і семантика бази даних. Важливе питання полягає не в тому, як буде представлятися універсальний репозиторій метаданих. (Можна легко уявити репозиторий у виді набору реляционных таблиць або діаграм сутність/зв'язок.) Питання полягає в тому, що знаходиться в репозиториї і що це означає? Які об'єкти є істотними і повинні бути описані? Це набагато складіша тема, і вона усе ще знаходиться в стадії обговорення. Наявність нової мови не вносить істотний внесок у це обговорення. Насправді при наявності розуміння, що XML є гарним засобом для опису структури бази даних, найбільше очевидним висновком є те, що використання цієї мови накладає велику відповідальність на адміністраторів даних із приводу коректності визначення даних. XML не забезпечує таку коректність; XML усього лише реєструє будь-який проект даних, що надходить від розробника. Поява XML підвищує важливість моделювання і проектування даних. 19
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
