Стандарт XML

Стандарт XML. Призначення та структура. Відмінності від HTML.
Що таке XML?
XML (eXtensible Markup Language) -  це  розширювана  мова  розмітки  тексту,
запропонована W3C у 1996 році. Це мова, яка повною мірою   визначає  логічну
структуру  документа.  Задача  XML  полягає  в  тому,  щоб   дані:   тексти,
зображення  або  інші  частини  Web-документа   могли   бути   визначені   і
структуровані незалежно від  платформи , що їх  відтворює,  постачальника  і
його програмного забезпечення, наприклад Web-браузерів.
При створенні документів із використанням  XML,  ви  можете  використовувати
ваші власні елементи і  структури  для  розмітки  вмісту  ваших  документів.
Можливо визначити DTD (a Document Type Definition), тобто   визначення  типу
документа. DTD визначає те, що можна назвати  "граматикою"  документа  -  це
список  різноманітних  елементів  і  їхніх  утворень  для   використання   у
визначених документах, у чомусь  це  нагадує  використання  CSS,  тобто   ви
можете зробити посилання на DTD, що знаходиться або в  мережі  або  написати
його безпосередньо у вашому документі.
Таким чином, вміст документа, його структура, типи використвуваних  у  ньому
елементів і його видгляд  визначаться  окремо,  тобто   незалежно  один  від
одного.
Чому XML?
Потрібно сказати, що XML корисний для  автоматизованих  програмних  засобів,
що  шукають  у  Web.  Недосконалість  HTML  призвела  до  того,  що   мережа
перетворилася в мішанину тексту,  повну  різноманітних  елементів  і  тегів,
часто використовуваних, що називається Pro Forma і нічого не значущих.
XML має величезний потенціал  для  удосконалення  гіпертекста.  Наприклад  у
HTML для створення зв'язку  використовується  елемент  A,  XML  же  дозволяє
створити не просто посилання, а наприклад, двонаправлений зв'язок.
Перспектива XML полягає в тому, що  він  буде  використовуватися  для  опису
інших мов розмітки,  наприклад,  JavaScript,  що  використовується  в  HTML-
документах.
XML розроблений для того, щоб спростити і полегшити використання  SGML,  при
цьому зберігши його великі можливості по створенню, поширенню  і  публікації
Web-документів мережі.

   Вступ

Незважаючи  на  те,  що  XML  дуже  молода  (W3C   затвердила   специфікацію
"Extensible Markup Language(XML) 1.0" на початку лютого  1998  г)  і  окремі
компоненти  цієї  мови  знаходяться  ще  в  стадії  доробки,  уже   сьогодні
з'являються нові мови, створені  на  основі  XML,  виникають  численні  Web-
сервери, що використовують цю технологію для організації   інформації  ,  що
зберігається на них.

Для чого потрібна нова мова розмітки?

Мова розмітки  документів  -  це  набір  спеціальних  інструкцій,  називаних
тегами,  призначених  для  формування  в  документах  якоїсь   структури   і
визначення відношень між  різноманітними  елементами  цієї  структури.  Теги
мови,  або,  як  їх  іноді  називають,  управляючі  дескриптори,   у   таких
документах  якимось  чином  кодуються,  виділяються  щодо  основного  вмісту
документа і служать у якості інструкцій для броузера.
Всю  красу  XML  можна  зрозуміти  тільки  при  порівнянні  його   з   HTML.
Формалізована у RFC 1866 у 1995  році,  HTML  є  найбільш  популярною  мовою
розмітки у всьому світі. Термін «розмітка»  стосовно  до  документа  означає
звичайно усе, що не відноситься до його інформаційного наповнення.
У ранню пору свого розвитку мова HTML підносилася  як  засіб  масштабованого
форматування документів,  яку   можна  було  б  використовувати  для  обміну
інформацією практично на будь-якій платформі. У  основі  HTML  лежить  украй
проста ідея: ви визначаєте нескладну мову, що описує структуру документа,  і
чекаєте, коли компанії розроблять програмні засоби, спроможні подавати  такі
документи в різноманітних  операційних  середовищах  з  урахуванням  обраних
користувачем  параметрів.  За  допомогою  HTML  можна  було   б   створювати
матеріали,  що  допускають  представлення  в  будь-якому   візуальному   або
звуковому форматі.
Проте поступово ставало ясно, що ця ідея, незважаючи на свою  простоту,  йде
врозріз з  узвичаєною  практикою  видавничих  систем.  Традиційний  механізм
підготування публікацій передбачає, що  графічні  дизайнери  і  компоновщики
повинні брати до уваги специфічні  особливості  презентаційного  середовища,
включаючи розмір листа, якість друку, палітру кольорів і т.п. Виявилося,  що
переключитися з такого методу на більш простий, при якому  автор  відповідає
лише за вміст і  логічну  структуру  документа,  перекладаючи  презентаційні
обов'язки на користувацькі програми, досить важко.
У  файлі  HTML  у  його  вихідному  виді  теги  форматування  перемішані  зі
звичайним  текстом.  Головною  особливістю  розмітки   HTML   є,   звичайно,
можливість вставки посилань на зовнішні документи або на  внутрішні  розділи
того ж самого документа.
HTML процвітав не тільки  як  адаптована  мова  розмітки,  але  й  у  якості
проміжного програмного забезпечення. Завдяки своїй дешевизні  і  поширеності
браузери Web являють собою відмінних клієнтів; за посередництвом  HTML  вони
можуть спілкуватися з найрізноманітнішими серверами.
Проте  HTML  стикнувся  з  певними  труднощами.  Його  обмежені   можливості
форматування намагалися перебороти за допомогою CSS, ініціативи TrueDoc  від
Bitstream і звісно ж множини специфічних  розширень  для  браузера;  а  його
обмежені можливості в якості проміжного ПО - за  допомогою  Java,  Active  і
т.п. Проте все це не усуває його фундаментальні недоліки.
По суті, HTML - це технологія представлення інформації, вона описує  те,  як
браузер повинний скомпонувати текст і графік на сторінці. У результаті  «те,
що ви бачите, - це усе, що ви  одержуєте».  Немає  ніякого  способу  описати
дані незалежно від відображення цих даних (за винятком  надзвичайно  слабкої
системи ключових слів у заголовку сторінки Web). "Байдужність" до  структури
документа призводить до того,  що  пошук  або  аналіз  інформації  усередині
нього нічим не буде відрізнятися від роботи із  суцільним,  не  розбитим  на
елементи текстовим  файлом.  Це  головна  причина,  чому  так  важко  знайти
потрібну інформацію за допомогою механізму пошуку.
Клієнт не має ніяких менше прийнятних засобів витягу даних із  сторінки  Web
для подальшої роботи з ними. Далі,  на  будь-який  конкретній  сторінці  Web
клієнт одержує тільки одне представлення конкретної множини даних.
Припустимо, що ви переглядаєте список аукціонів eBay, упорядкований по  даті
відкриття  торгів.  Якщо  ви  захочете  глянути  на  той  же   список,   але
відсортований  по  даті  закриття  торгів,  то  вашому  браузеру  прийдеться
посилати новий  запит  серверу.  У  свою  чергу  серверу  прийдеться  наново
відправляти  повну  сторінку  HTML  із  списком   аукціонів.   Такого   роду
маніпулювання даними веде до значного збільшення числа звертань до  серверів
Web і утруднює, таким чином, їх подальше масштабирование.
Інша проблема з HTML у тому, що це «плоска» мова,  тобто  автори  не  можуть
використовувати її для надання інформації про  ієрархію  даних.  Далі,  вона
непослідовна  і  тому  утрудняє  розбір  тексту  програмним   забезпеченням.
Наприклад, хоча більшість відкриваючих тегів, (такі, як <B>  або  <H1>)  має
відповідні закриваючі теги, деякі (наприклад, <P>) їх не мають.
Істотним недоліком HTML можна назвати обмеженість набору  його  тегов.  DTD-
правила  для  HTML  визначають  фіксований  набір  дескрипторів  і  тому   в
розробника немає можливості вводити власні, спеціальні теги.
Простим рішенням для  деяких  із  перерахованих  проблем  було  би  введення
додаткових тегів HTML, таких,  як  <NAME>,  <DATE>  або  <PRICE>.  З  їхньою
допомогою клієнт міг би визначити, що собою являють дані, і  відображати  їх
по-різному або експортувати по запиту користувача. Якщо  ж  ви  вирішите  не
чекати зміни стандарту, то майте  на  увазі,  що  ви  створюєте  щось  своє,
нестандартне і тим самим відмовляєтеся від однієї з головних переваг HTML.
Тому в 1996 році члени  робочої  групи  Консорціуму  World  Wide  Web  (W3C)
повернулися до розгляду стандартної  узагальненої  мови  розмітки  (Standard
Generalized Markup Language, SGML), сильно спрощеним нащадком якого є  HTML.
Запропонована у 1974 році Чарльзом Голдфарбом, SGML являє собою  метамову  -
систему для опису інших мов. Ця мова  призначена  для  створення  інших  мов
розмітки, він визначає припустимий набір тегів, їхні  атрибути  і  внутрішню
структуру документа. При всіх своїх можливостях  вона  занадто  складна  для
більшості браузеров Web: одна специфікацій SGML займає понад 500 сторінок.
Спростивши  SGML  для  використання   з   Web,   група   запропонувала   XML
(рекомендація W3C по статусу на лютий 1998 року).  XML  –  підмножина  SGML,
причому любий дійсний документ XML є дійсним документом SGML. І, як і  SGML,
XML - це метамова, що визначає інші мови  розмітки  для  специфічних  цілей.
Наприклад,  мова  синхронізованої   інтеграції   мультимедіа   (Synchronized
Multimedia Integration Language, SMIL) базується на XML.
Консорціум W3C, закликаючи до використання  XML  у  Web,  фактично  пропонує
кожному сконструювати особисту мову  для  своїх  гіпертекстових  документів,
причому для різних документів це будуть різні мови.
XML  дозволяє  визначити  формальний  синтаксис  мови,   наприклад   правила
вкладення елементів.  Семантику  можна,  звичайно,  описувати  на  звичайній
англійській мові.
XML використовується для розмітки стандартних документів багато в  чому  так
само, як HTML. Проте XML  перевершує  його  при  роботі  зі  структурованими
даними, такими, як результати  запиту,  метаінформація  про  вузол  Web  або
елементи і типи схеми.
Документ XML виглядає багато в чому схожим на HTML. Він також складається  з
текстових фрагментів, анотованих вкладеними в кутові  дужки  тегами.  Проте,
на  відміну  від  HTML,  зміст  тега  залежить  від   регістра,   а   кожний
відкриваючий тег повинний в усіх випадках мати парний закриваючий тег.
XML (Extensible Markup Language)-э те мова розмітки, що  описує  цілий  клас
об'єктів даних, називаних  XML-  документами.  Ця  мова  використовується  в
якості засобу для опису грамматики інших  мов  і  контролю  за  правильністю
впорядкування документів. XML  не  містить  ніяких  тегів,  призначених  для
розмітки, а  просто  визначає  порядок  їх  створення.  Таким  чином,  якщо,
наприклад,  ми  вважаємо,  що  для  позначення  елемента  rose  у  документі
необхідно  використовувати   тег   <flower>;,   то   XML   дозволяє   вільно
використовувати обумовлений  нами  тег  і  ми  можемо  включати  в  документ
фрагменти, подібні такому:
<flower>rose</flower>
Таким  чином,  у  розробників  з'являється  унікальна  можливість  визначати
власні команди, що дозволяють  їм  найбільш  ефективно  визначати  дані,  що
зберігаються в документі. Автор  документа  створює  його  структуру,  будує
необхідні  зв'язки   між   елементами,   використовуючи   ті   команди,   що
задовольняють його вимогам і домагається такого типу розмітки, що  необхідно
йому для виконання операцій перегляду, пошуку, аналізу документа.
Ще одною з очевидних переваг XML  є  можливість  використання  її  в  якості
універсальної мови запитів до сховищ інформації.  Сьогодні  в  глибинах  W3C
знаходиться на розгляді робочий варіант  стандарту  XML-QL  (або  XQL),  що,
можливо, у майбутньому складе серйозну  конкуренцію  SQL.  Крім  того,  XML-
документи можуть виступати в якості унікального засобу збереження даних,  що
містить у собі одночасно засоби для розбору інформації  й  представлення  її
на стороні клієнта.  У  цій  області  одним  із  перспективних  напрямків  є
інтеграція Java і XML - технологій, що дозволяє  використовувати  міць  обох
технологій при  побудові  машинно-незалежних  додатків,  що  використовують,
крім того, універсальний формат даних при обміні інформацією.
XML  дозволяє  також  здійснювати  контроль   за   коректністю   даних,   що
зберігаються  в  документах,  робити  перевірки  ієрархічних   співвідношень
усередині  документа  і   встановлювати   єдиний   стандарт   на   структуру
документів, умістом яких можуть бути самі різноманітні дані. Це означає,  що
його можна використовувати при побудові  складних  інформаційних  систем,  у
котрих  дуже  важливим  є  питання  обміну  інформацією  між  різноманітними
додатками, що  працюють  в  одній  системі.  Створюючи  структуру  механізму
обміну інформації на самому  початку  роботи  над  проектом,  менеджер  може
позбути себе в майбутньому від багатьох проблем, пов'язаних із  несумісністю
використовуваних різноманітними компонентами системи форматів даних.
На  основі  XML  уже  сьогодні  створені  такі  відомі  спеціалізовані  мови
розмітки, як SMIL, CDF, MathML, XSL, і список робочих  проектів  нових  мов,
що знаходяться на розгляді W3C, постійно поповнюється.

Структура документа

Не обмежуючи автора яким-небудь фіксованим набором тегів, XML дозволяє  йому
вводити  будь-які  імена.   Ця   можливість   є   ключовою   для   активного
маніпулювання даними.
Приклад для порівняння представлення списку імен і адрес на HTML і на XML.
От фрагмент HTML:
<H1>Еditor Сontacts</H1>
<H2>Ім'я: Джонатан Эйнджел</H2>
<P>Посада: старший редактор</P>
<P>Видання: Network Magazine</P>
<P>Вулиця і будинок: Гарісона, 600 </P>
<P>Місто: Сан-Франциско</P>
<P>Штат: Каліфорнія</P>
<P>Індекс: 94107</P>
<P>Електронна пошта:
jangel@mfi. com</P>
Теги розміщають  дані  на  екрані,  але  нічого  не  повідомляють  про  їхню
структуру.
У випадку XML  той  же  самий  фрагмент  буде  поданий  у  такий  спосіб  (і
збережений у файлі EDITORS. XML).
<?xml version = '1.0' ?>
<?xml-stylesheet type='text/xsl' href='editors.xsl' ?>
<editor_contacts>
  <editor>
    <first_name>Jonatan</first_name>
    <last_name>Andjel</last_name>
    <title>chif editor" --><title>Стандарт XML</title>
    <publication>Network
    Magazine</publication>
    <address>
      <street>Garissona, 600 </street>
      <city>San-Francisko</city>
      <state>California</state>
      <zip>94107</zip>
    </address>
    <e_mail>jangel@mfi.com</e_mail>
  </editor>
</editor_contacts>
У XML теги не  можуть  накладатися,  як  у  HTML,  проте  вони  можуть  бути
вкладені один в одний. Насправді, вкладення навіть рекомендується  як  засіб
створення ієрархії даних (підпорядковані  або  рівноправні  відношення).  Як
очевидно з приведеного приклада, такі елементи, як <first_name> і  <e_mail>,
містять дані, у  той  час  як  інші  (<address>)  присутні  тільки  з  метою
структурування.
Теги  початку  і  кінця  елемента  є  основними  використовуваними   в   XML
розмітками, але ними справа не  вичерпується.  Наприклад,  елементам  можуть
бути привласнені атрибути. Ця можливість  аналогічна  наявній  в  HTML,  де,
наприклад, елементу <table> може бути привласнений  атрибут  align=»center».
У XML елемент може  мати  один  або  більше  пов'язаних  із  ним  атрибутів,
причому при упорядкуванні документа ви можете видумати їх  стільки,  скільки
побажнете,         наприклад         <publication         topic=»networking»
circulation=»controlled»>.
Документи XML можуть містити посилання на інші  об'єкти.  Посилання  являють
собою рядок, що починається з амперсанта і закінчується  “;”.  Ці  посилання
дозволяють, зокрема, вставити в документ спеціальні символи.  Посилання  XML
на  об'єкти  надають  набагато  більше  можливостей,  тому  що  вони  можуть
посилатися на визначені автором розділи тексту в тому ж самому або в  іншому
документі.
Наприклад,   посилання   на   об'єкти   дозволяють   застосувати   об'єктно-
орієнтований підхід при створенні журнальної статті:
<article>
&introduction;
&body;
&sidebar;
&conclusion;
&resources;
</article>
Найпростіший XML- документ може виглядати так, як це показано в Прикладі 1
<?xml version="1.0"?>
<list_of_items>
<item id="1"><first/>Перший</item>
<item id="2">Другий <sub_item>підпункт 1</sub_item></item>
<item id="3">Третій</item>
<item id="4"><last/>Останній</item>
</list_of_items>
У XML існують  відкриваючі,  закриваючі  і  порожні  теги  (у  HTML  поняття
порожнього тэга теж існує, але спеціального його позначення не потрібно).
Тіло  документа  XML   складається   з   елементів   розмітки   (markup)   і
безпосередньо вмісту документа - даних (content). XML - теги призначені  для
визначення елементів документа, їхніх атрибутів і інших конструкцій мови.
Любий XML-документ повинний  завжди  починатися  з  інструкції  <?  xml?  >,
усередині якої  також  можна  задавати  номер  версії  мови,  номер  кодової
сторінки й інші параметри, необхідні програмі-аналізатору в процесі  розбору
документа.

Правила створення XML- документа

У загальному випадку XML- документи повинні задовольняти таким вимогам:
 . У заголовку документа поміщається оголошення XML, у якому вказується мова
   розмітки документа, номер її версії і додаткова інформація
 . Кожний відкриваючий тег, що визначає  деяку  область  даних  у  документі
   обов'язково повинний мати відповідний закриваючий тег
 . У XML враховується регістр символів
 . Всі значення атрибутів, використовуваних у визначенні тегів, повинні бути
   взяті в лапки
 . Вкладеність тегів у XML строго контролюється, тому необхідно  стежити  за
   порядком слідування відкриваючих і закриваючих тегів
 . Вся інформація, що розташовується  між  початковим  і  кінцевими  тегами,
   розглядається в XML як дані і тому враховуються всі символи форматування
Якщо  XML-  документ  не  порушує  приведені  правила,  то  він  називається
формально-правильним  і  всі  аналізатори,  призначені  для   розбору   XML-
документів, зможуть працювати з ним коректно.
З XML-документом пов'язані три рівні коректності:
 . Правильно побудований XML-документ - це такий, у якому елементи правильно
   структуровані у вигляді дерева з коректно  розставленими  відкриваючих  і
   закриваючих тегами.
 . Діючий XML-документ правильно побудований і містить теги, що відповідають
   оголошенню  типу  документа.  Він  містить  тільки  елементи  і  значення
   атрибутів, що відповідають DTD. Хоча XML-документ може  підготовлятися  і
   читатися без DTD, DTD істотно для встановлення дієвості.
 . Синтаксически коректний  XML-документ  знаходиться  поза  контролем  XML.
   Розробник такого документа відповідає за його логічну структуризацію.
Проте крім перевірки на формальну відповідність граматиці мови, у  документі
можуть бути присутнім засоби контролю над вмістом документа, за  дотриманням
правил, що визначають необхідні співвідношення між  елементами  і  формуючою
структурою документа. Наприклад, наступний текст, будучи  цілком  правильним
XML- документом, буде абсолютно безглуздим:
<country><title>Russia" --><title>Стандарт XML</title><city><title>Novosibirsk</country>" --><title>Стандарт XML</title></ci
ty>
Для того, щоб забезпечити перевірку  коректності  XML-документів,  необхідно
використовувати  аналізатори,  що  роблять  таку  перевірку  і   називаються
верифікованими.
На сьогоднішній день існує два способи контролю правильності  XML-документа:
DTD  -  визначення  (Document  Type  Definition)  і  схеми  даних  (Semantic
Schema). Визначення DTD- правил у XML не є необхідністю.

Конструкції мови

Вміст XML- документа являє собою набір  елементів,  секцій  CDATA,  директив
аналізатора, коментарів, спецсимволів, текстових даних.
Елементи даних
Елемент - це структурна одиниця XML- документа. Вкладаючи  слово  rose  в  у
тэги  <flower>  </flower>  ,  ми  визначаємо  непустий   елемент,   названий
<flower>, вмістом якого  є  rose.  У  загальному  випадку  в  якості  вмісту
елементів можуть виступати як простий текст, так і інші, вкладені,  елементи
документа,  секції  CDATA,  інструкції  з  опрацювання,  коментар,  -  тобто
практично будь-які частини XML- документа.
Любий непустой елемент повинний складатися з початкового, кінцевого тегов  і
даних, між  ними  заключених.  Наприклад,  наступні  фрагменти  будуть  бути
елементами:
<flower>rose</flower>
<city>Novosibirsk</city>
,а ці - ні:
<rose>
<flower>
rose
Набором всіх елементів, що містяться в документі, задається  його  структура
і  визначаються  всі  ієрархічні   співвідношення.   Плоска   модель   даних
перетворюється з використанням елементів  у  складну  ієрархічну  систему  з
множиною можливих зв'язків між елементами. Наприклад, у такому  прикладі  ми
описуємо  місце  розташування  Новосибірських  університетів  (вказуємо,  що
Новосибірський Університет розташований у місті Новосибірську,  що,  у  свою
чергу, знаходиться в Росії), використовуючи для цього вкладеність  елементів
XML :
<country id="Russia">
 <cities-list>
<city>
<title>Новосибірськ" --><title>Стандарт XML</title>
<state>Siberia</state>
<universities-list>
<university id="2">
<title>Новосибірський Державний Технічний Університет" --><title>Стандарт XML</title>
<noprivate/>
<address URL="www.nstu.ru"/>
<description>дуже гарний інститут</description>
</university>
<university id="2">
<title>Новосибірський Державний Університет" --><title>Стандарт XML</title>
<noprivate/>
<address URL="www.nsu.ru"/>
<description>теж не поганої</description>
</university>
</universities-list>
</city>
</cities-list>
</country>
Проводячи пошук у  цьому  документі,  програма  клієнта  буде  спиратися  на
інформацію, закладену в його структуру - використовуючи елементи  документа.
Тобто, якщо, наприклад, потрібно знайти потрібний університет  у  потрібному
місті, використовуючи  приведений  фрагмент  документа,  то  необхідно  буде
переглянути  вміст  конкретного  елемента   <university>,   що   знаходиться
всередині конкретного елемента  <city>.  Пошук  при  цьому,  природно,  буде
набагато  більш  ефективним,  ніж  знаходження  потрібної  послідовності  по
всьому документу.
У XML документі, як правило, визначається  хоча  б  один  елемент,  названий
кореневим і з нього програми-аналізатори  починають  перегляд  документа.  У
приведеному прикладі цим елементом є <country>
У деяких випадках теги можуть  змінювати  й  уточнювати  семантику  тих  або
інших фрагментів документа, по різному визначаючи ту  саму  інформацію,  тим
самим надаючи додатку-аналізатору  цього  документа  зведення  про  контекст
використання описуваних даних.
У випадку, якщо елемент не має вмісту, тобто немає даних, які  він  повинний
визначати,  він  називається  порожнім.  Необхідно  тільки   пам'ятати,   що
початковий і кінцеві теги порожнього елемента ніби об'єднується  в  один,  і
треба обов'язково ставити косу риску перед  кутовою закриваючою  (наприклад,
<empty/>;)
Коментар
Коментарями є будь-яка область даних, поміщена між послідовностями  символів
<!  --  і  -->  Коментар  пропускаються  аналізатором  і  тому  при  розборі
структури документа в якості значущої інформації не розглядається.
Атрибути
Якщо  при  визначенні  елементів  необхідно  задати  якісь   параметри,   що
уточнюють його характеристики,  то  є  можливість  використовувати  атрибути
елемента. Атрибут - це пару "назва" =  "значення",  що  треба  задавати  при
визначенні елемента в початковому тегу. Приклад:
<color RGB="true">#ff08ff</color>
<color RGB="false">white</color>
або
<author id=0>Ivan Petrov</author>
Прикладом використання атрибутів у HTML є опис елемента <font>:
<font color=»white» name=»Arial»>Black</font>
Cпеціальні символи
Для того, щоб включити в документ символ,  використовуваний  для  визначення
яких-небудь конструкцій мови і не викликати  при  цьому  помилок  у  процесі
розбору  такого  документа,  потрібно   використовувати   його   спеціальний
символьний або числовий ідентифікатор. Наприклад, <  ,  >  "  або
$(десяткова форма запису),  (шестнадцатеричная) і т.д.
Директиви аналізатора
Інструкції, призначені для аналізаторів мови, описуються в XML документі  за
допомогою спеціальних тегів - <? і ? >;. Програма  клієнта  використовує  ці
інструкції  для  керування  процесом  розбору  документа.  Найбільше   часто
інструкції використовуються при визначенні  типу  документа  (наприклад,  <?
Xml version=»1.0»? >) або створенні простору імен.
CDATA
Розділи символьных даних - це частини документа,  аналізовані  винятково  як
символьные  дані,  що  не  піддаються  розборові,  але,  у  відмінності  від
коментарів, використовуються застосуванням, виглядають так:
<![CDATA[
Цей текст, навіть якщо він містить інструкції JavaScript або елементи коду
HTML, такі, як <B>жирныйшрифт</B> або <H1>заголовок</H1>, не піддається
граматичному розборові. Замість цього він відображається як їсти.
]]>

   Таблиці стилів

Таблиці стилів узагалі, і каскадні таблиці стилів (Cascading  Style  Sheets,
CSS) зокрема, дозволяють відокремити структуру й вміст документа  від  рівня
представлення. У застосуванні до Web і HTML це  означає,  що  мова  HTML  не
містить  у   собі   презентаційних   можливостей:   характер   представлення
формується окремими інструментальними засобами.
Технологія  CSS  помітно  спрощує  упорядкування  і   супровід   документів.
Створивши одну таблицю  стилів,  ви  зможете  використовувати  її  в  сотнях
документів. Вже  в  CSS1,  першої  версії  CSS,  були  передбачені  елементи
уявлення,  узагалі  немислимі  в  HTML  (наприклад,   регулювання   фізичних
розмірів шрифтів).
XML/CSS як метод публікації  можна  зіставити  з  використанням  програмного
засобу опрацювання текстів, що підтримує  стилі  або  макрокоманди:  XML/CSS
здійснює  структурування  документів,  але  виникаюча   структура   не   має
незалежну загальнодоступну семантику.
CSS можуть служити і для форматирования  документів  XML,  але  це  не  дуже
удалий вибір. Головна перевага XML у тому, що вона подає  формат  документа,
для можливих маніпуляцій, у виді деревоподібної структури. На жаль,  CSS  не
спроможні взаємодіяти з деревом і можуть тільки  форматувати  документи  XML
«як вони є». Ви можете вивести документ на екран у будь-якому  форматі,  але
не  можете  здійснити  якесь  вибіркове   представлення   його   даних   без
застосування мови сценаріїв.
Дані обмеження призвели до створення XSL. Найбільше важлива особливість  XML
і супутньої йому технології розширюваної  мови  таблиці  стилів  (Extensible
Stylesheet  Language,  XSL)  складається  у  відділенні  форматирования  від
інформаційного наповнення.
Таблиці стилів XSL описують, як  документи  XML  повинні  перетворюватися  в
інші формати, такі, як HTML або RTF.  Але  таблиці  стилів  XML  -  це  щось
більше, ніж просто перетворювачі форматів; вони також надають  механізм  для
маніпулювання даними. Наприклад, дані можна сортувати, робити по ним  пошук,
видаляти або додавати прямо з браузера.
XSL спроможна також здійснювати умовну трансформацію виведення в  залежності
від  значень  різноманітних  елементів  або  атрибутів.  Більш  того,   вона
дозволяє запитувати дані з використанням  множини  різноманітних  операторів
шаблонів, символів підстановки,  фільтрів,  булевых  операторів  і  виражень
множини. XML і XSL ніяким чином не призначені для  заміни  SQL,  до  того  ж
навряд чи знайдеться багато бажаючих берегти свої бази  даних  безпосередньо
у форматі XML. Проте XSL відчиняє можливість різноманітного пошуку по  даним
після  їх  завантаження  в  браузер.   Вам   ніколи   вже   не   знадобиться
використовувати  для  пошуку  інформації   примітивну   вмонтовану   команду
браузера Find.
Значний  потенціал  XML  у  якості   проміжного   програмного   забезпечення
підкріплюється об'єктною моделлю документа  (Document  Object  Model,  DOM),
версія 1.0 якиа була прийнята в якості рекомендації W3C у жовтні 1998  року.


   Визначення Типу Документів (DTD)

Якщо теги й елементи XML  використовуються  винятково  заради  зручності  на
вашому власному вузлі Web, то не має  ніякого  значення,  що  ви  даєте  цим
елементам і  тегам  імена,  зміст  яких  відрізняється  від  стандартного  і
відомий тільки  вам.  Якщо  ж,  з  іншого  боку,  ви  хочете  надавати  дані
зовнішньому світу й одержувати інформацію від партнерів по  бизнесу,  те  ця
обставина набуває величезне значення. Елементи й атрибути повинні  вживатися
вами точно так само, як і всіма іншими  людьми,  або  принаймні  ви  повинні
документувати те, що робите.
Для  цього  використовується  визначення  типів  документів  (Document  Type
Definition – DTD). Збережені на початку файла XML або назовні у  виді  файла
*.DTD,  ці  визначення  описують  інформаційну  структуру   документа.   DTD
перераховують  можливі  імена  елементів,  визначають  наявні  атрибути  для
кожного типу елементів і описують сполучуваність одних елементів з іншими.
Кожний рядок у  визначенні  типу  документа  може  містити  декларацію  типу
елемента, іменувати елемент і визначати тип даних, що елемент може  містити.
Вона має такий вигляд
<!ELEMENT ім'я_елемента
 (тип_даних)>
Наприклад, декларація визначає<!ELEMENT  publication  (#PCDATA)>  елемент  з
ім'ям publication, що містить символьні дані (тобто текст).
Декларація  <!ELEMENT  special_report  (article_1,  article_2,   article_3)>
визначає елемент з ім'ям special_report, що містить  піделементи  article_1,
article_2 і article_3 у зазначеному порядку, наприклад:
<special_report>
<article_1>XML:час прийшов</article_1>
<article_2>XML перевершує саме себе</article_2>
<article_3>Керування мережами і системами за допомогою XML</article_3>
</special_report>
Після визначення елементів DTD можуть також визначати атрибути за  допомогою
команди !ATTLIST. Вона вказує
елемент, іменує пов'язаний із ним атрибут і  потім  описує  його  припустимі
значення.!ATTLIST дозволяє управляти атрибутами і багатьма іншими  засобами:
задавати значення по замовченню, знищувати пробіли і т.д. DTD  можуть  також
містити декларації !ENTITY, де визначаються посилання на  об'єкти,  а  також
декларації !NOTATION, що вказують, що  робити  з  двійковими  файлами  не  у
форматі XML.
Серйозне і дещо надзвичайне  обмеження  DTD  полягає  в  тому,  що  вони  не
припускають  типізації  даних,  тобто  обмежують  дані  конкретним  форматом
(таким,  як  дата,  ціле  число  або  число   з   плаваючою   точкою).   DTD
використовують інший синтаксис, ніж XML, і не дуже-то інтуїтивно  зрозумілі.
По названих причинах DTD  будуть,  напевно,  замінені  на  більш  потужні  і
прості у використанні схеми XML, робота над який ведеться в даний час.

   Схеми даних

Схеми даних (Schemas) є альтернативним  засобом  створення  правил  побудови
XML-документів. У порівнянні з DTD, схеми мають  більш  потужні  засоби  для
визначення складних структур  даних,  забезпечують  більш  зрозумілий  засіб
опису грамматики мови,  спроможні  легко  модернізуватися  і  розширюватися.
Безумовною перевагою схем є також те, що вони дозволяють  описувати  правила
для XML- документа засобами самого ж XML.
Проте це не означає, що схеми можуть цілком замінити DTD-описи -  цей  засіб
визначення  грамматики  мови  використовується   зараз   практичними   всіма
верифікуючими аналізаторами, XML і, більш того, самі схеми, як звичайні XML-
 елементи, теж описуються DTD. Але  серйозні  можливості  нової  мови  і  її
відносної простоти, безумовно, дають підстави підтверджувати,  що  майбутній
стандарт знайде широке застосування в якості зручного й  ефективного  засобу
перевірки коректності упорядкування документів.
В даний час у W3  консорціумі  йде  робота  над  першою  специфікацією  схем
даних.
Консорціум World Wide Web (W3C)  не  збирається  давати  своє  благословення
ніяким  додаткам  XML  (у  термінології  XML  «додатком»  називається   опис
галузевих термінів за допомогою деякого набору тегов XML).  Іншими  словами,
конкретні вертикальні ринки повинні  самостійно  узгодити  усередині  галузі
імена для своїх об'єктів. Щоб сприяти  відкритості  і  передбачуваності  при
упорядкуванні  схем  XML  у   вертикальних   галузях,   Microsoft   висунула
ініціативу, названу BizTalk. За станом на серпень 1999  року  цю  ініціативу
підтримало понад 25 компанії.
Почасти BizTalk являє собою  не  що  інше,  як  суспільний  сервер  Web,  де
публікуються всі  схеми,  запропоновані  для  використання  в  різноманітних
галузях. Проте BizTalk не ставить своєю ціллю об'єднати всі галузі в  спробі
скласти одну гігантську схему для усіх використовуваних  у  якому  б  то  ні
було бізнесі даних.
BizTalk складається з трьох  окремих  елементів.  По-перше,  це  сховище  на
сервері Web разом із рекомендаціями  і  тегами  XML,  використовуваними  для
додавання нових схем у сховище. По-друге, це розробка програмного  продукту,
серверу  BizTalk.  І  по-третє,  це  будуть  інтерактивні  послуги  на  базі
технології BizTalk.
Відмова від DTD
У тому, що стосується відображення  галузевих  даних,  BizTalk  виходить  із
безперспективності визначень типів  документів  (Document  Type  Definition,
DTD). Замість того щоб заохочувати розробку  XML  DTD,  прихильники  BizTalk
описують свої ієрархії даних за допомогою  XML  Schema  (як  передбачається,
цей стандарт повинний прийти на зміну DTD).
В даний час W3C намагається  узгодити  різноманітні  підходи  до  схем,  але
запропонована версія стандарту - XML Schema - дає  достатньо  ясне  уявлення
про те, як буде виглядати заміна DTD. XML Schema  має  значно  більш  широкі
можливості, ніж DTD, причому описи даються за допомогою  безпосередньо  XML,
без створення ще однієї системи розмітки, як того потребує DTD.
DTD цілком достатньо для  базового  визначення  документа,  але  вони  мають
декілька недоліків. По-перше, вони даються не на XML. З  огляду  на  високий
ступінь адаптованості і розширюваність XML, наявність ще одного формату  для
визначення документів є зайвою.
По-друге,  елементи  DTD  усередині   документа   XML   потребують   повного
визначення усього, що знаходиться усередині цих елементів.  Іншими  словами,
ніякі піделементи «на перспективу»  не  припускаються  -  якщо  такі  будуть
присутні в документі, те, по визначенню, документ  не  буде  бути  правильно
складеним. Тим часом визначення XML Schema використовують модель  відкритого
інформаційного наповнення, у котрої невизначені елементи цілком  припустимі.

По-третє,  DTD  обмежуються   тільки   граматикою   і   синтаксисом   (тобто
відношенням одного елемента до  іншого),  тоді  як  XML  Schema  може  також
задавати безпосередні обмеження на тип даних, що елемент  може  містити.  Це
значно спрощує реалізацію  передачі  даних  додатка  в  порівнянні  з  більш
традиційним текстовим документом. Наприклад, точно так само, як  це  роблять
розроблювачі в мовах  програмування,  ви  можете  явно  зазначити,  що  дана
область  збереження  може  містити  тільки  целочисленные   дані.   Нарешті,
розроблювачам, що  працюють  у  середовищах  Wintel,  буде  дуже  зручно  те
обставина, що XML Schema легко відображається на Microsoft  Document  Object
Model. Таким чином, що працює з документами XML програма  може  запросити  у
відповідної  схеми  наявне  визначення  для  елемента  документа  по  своєму
виборі. Код виглядає в такий спосіб:
var bookNode = doc. documentElement
Проте як же буде виглядати сам документ, що містить  схему,  зсередини?  По-
перше, він буде містити теги XML, що повідомляють, що це схема, на зразок:
<Schema name=»schema_sample_1»>
... вміст схеми
</Schema>
Кожний пункт  усередині  схеми  об'являється  потім  індивідуально,  причому
особливості кожного елемента розшифровуються за допомогою  вкладених  тегів,
наприклад:
<ElementType name=»PERSONA» content=»textOnly» />
визначає елемент <Inventor> як здатний містити тільки текстові дані.
Подібні схеми можуть виявитися  дуже  важкі  для  читання,  але  вони  легко
піддаються розборові за допомогою інструментів 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, то тип  даних,  котрими  ви  наповняєте  свій
документ, буде легко встановити. Нарешті,  ви  можете  також  вставити  блок
маршрутних документів, наприклад:
<Route>
<From locationID=»11111111»
locationType=»DUNS»
 process=»» path=»» handle=»3»/>
<To locationID=»222222222»
locationType=»DUNS»
process=»» path=»»
handle=»23CF15»/>
</Route>
BizTalk Framework нічого не говорить про те,  які  дані  повинні  входити  в
чотирьох атрибута тегів і<FROM><TO>,   вона  просто  встановлює  призначення
кожного з них. Теги  location  ідентифікують  мережний  вузол  (можливо,  за
допомогою URL), куди направляється документ, у той час  як  теги  process  і
handle  визначають  додаток  і  конкретний   примірник   (наприклад,   номер
транзакции),  до  якого  відносяться  дані.  Тег  path  служить  свого  роду
вмістилищем, де проміжні сервери можуть берегти відомості про  дату  й  іншу
інформацію, щоб маршрут (і за допомогою розширення  зворотний  маршрут)  був
видимий усім серверам уздовж шляху.
Бізнес-модель BIZTALK
Microsoft  випустить  серверний  продукт  для  регулювання  обміну  BizTalk-
сумісними  повідомленнями  XML  між  партнерами  по   бізнесу   (бета-версія
наприкінці  осені 1999 року; готовий продукт повинний  вийти  після  Windows
2000).
Як це виглядає
Інструкції в схемах складають набір правил, використовуючи  який,  програма-
клієнт буде робити висновок про те, коректний документ або ні. Схема  даних,
наприклад, може виглядати таким чином:
<schema id="OurSchema">
<elementType id="#title">
<string/>
</elementType>
<elementType id="photo">
<element type="#title">
<attribute name="src"/>
</elementType>
<elementType id="gallery">
<element type="#photo">
</elementType>
</schema>
Якщо ми включимо  приведені  правила  всередину  XML-  документа,  програма-
клієнт зможе використовувати їх  для  перевірки.  Тобто,  вона  тепер  зможе
визначити, що правильним буде бути такий фрагмент:
<gallery>
<photo id="1"><title>My computer" --><title>Стандарт XML</title></photo>
<photo id="2"><title>My family" --><title>Стандарт XML</title></photo>
<photo id="3"><title>My dog" --><title>Стандарт XML</title></photo>
</gallery>
, а некоректним цей:
<gallery>
<photo id="1"/>
<photo index="2"><title>My family" --><title>Стандарт XML</title></photo>
<photo index="3"><title>My dog </title><dogname>Sharik</dogname></photo>
</gallery>
Всі конструкції мови  схем  описуються  правилами  "XML  DTD  for  XML-Data-
Schema".
Область схеми даних
Створюючи схеми  даних,  ми  визначаємо  в  документі  спеціальний  елемент,
<schema>;, усередині якого містяться описи правил:
<schema id="OurSchema">
<!-- послідовність інструкцій -->
</schema>
Якщо використовувати  окремий  простір  імен,  то  повний  XML-документ,  що
містить у собі схему даних, буде виглядати в такий спосіб:
<?XML version='1.0' ?>
<?xml:namespace href="http://www.mrcpk.nstu.ru/schemas/" as="s"/?>
<s:schema id="OurSchema">
<!-- послідовність інструкцій -->
</s:schema>
Опис елементів
Для визначення класу  елемента,  до  якого  надалі   будуть  застосовуватися
інструкції, що описують його  вміст  і  структуру,  призначений  спеціальний
елемент схеми elementType,
<elementType id="issue">
<descript>Елемент містить інформацію про черговий випуск
часопису</descript>
</elementType>
Назва  елемента  задається  атрибутом  id.  Всі  подальші   інструкції,   що
ставляться до описуваного  класу,  визначають  його  внутрішню  структуру  і
набір  припустимих  даних,  містяться  всередині  блока,   заданого   тегами
<elementType> і </elementType>.
Як  очевидно  з  приклада,  при  визначенні  класу  елемента,  можна   також
використовувати    коментар    до    нього,    що    заключають    у    тэги
<descript></descript>
Атрибути елемента
Для  того,  щоб  в  описі  елемента  визначити  його  атрибути   й   описати
властивості цих атрибутів ми повинні використовувати елемент attribute:
<elementType id="photo">
<attribute name="src"/>
<empty/>
</elementType>
У даному прикладі  елементу  <photo>  визначається  атрибут  src,  значенням
якого може бути будь-яка послідовність дозволених символів:
<photo src="0"/>
<photo src="some text">
Подібно DTD, схеми даних дозволяють встановлювати обмеження  на  значення  і
засіб використання атрибутів. Для цього в дескрипторі <attribute>  необхідно
використовувати параметр atttype.
Наприклад,  якщо  ми  хочемо  зазначити,  що   значення   атрибута   повинно
використовуватися програмою-аналізатором  як  унікальний  ідентифікатор,  то
нам необхідно створити таке правило:
<elementType id="bouquet">
<attribute name="id" atttype="ID">
</elementType>
Якщо ж потрібно задати список можливих значень атрибута,  то  приклад  будет
виглядати в такий спосіб:
<attribute name="flower" atttype="ENUMERATION" values="red green blue"
default="red">
Модель вмісту елемента
Під моделлю вмісту в схемі даних розуміють опис  усіх  припустимих  об'єктів
XML- документа, використання котрих усередині даного елемента  є  коректним.
Модель  вмісту  визначається  інструкціями,  розташованими  всередині  блока
<elementType>.
<elementType id="article">
<attribute name="id" atttype="ID">
<element type="#title">
<string/>
</elementType>
Для цього правила коректним буде бути такий фрагмент документа:
<article id="0">
<title>Психи і маніяки в Інтернет" --><title>My dog </title>
</article>
Вкладені  елементи  описуються  за  допомогою  інструкції  element,  у  якій
параметром type указується клас об'єкта - посилання на його визначення:
<elementType id="article">
<element type="#title"/>
<element type="#author"/>
</elementType>
Якщо потрібно зазначити режим використання  вкладеного  елемента,  то  треба
визначити параметр occurs:
<elementType id="article">
<element type="#title" occurs="REQUIRED"/>
<element type="#author" occurs="OPTIONAL"/>
<element type="#subject" occurs="ONEORMORE"/>
</elementType>
Можливі значення цього параметра такі:
REQUIRED - елемент повинний бути обов'язково визначений
OPTIONAL - використання елемента не є обов’язковим
ZEROORMORE - вкладений елемент може зустрічатися декілька разів або  жодного
разу
ONEORMORE - елемент повинний зустрічатися хоча б один раз
Приклади правильних XML-документів, що використовують приведену вище  схему:

<article>
<title>Навіщо він потрібний, XML?" --><title>My dog </title>
<author>Іван Петров</author>
<subject>Що таке XML</subject>
<subject>потрібний чи він нам</subject>
</article>
або
<article>
<title>Навіщо він потрібний, XML?" --><title>My dog </title>
<subject>Що таке XML</subject>
</article>
Крім елементів, вмістом XML-документа можуть також бути звичайним текстом  і
областями CDATA. Для позначення типів вмісту  поточного  елемента  в  схемах
використовуються такі інструкції:
<string/> - вказує на те, що  вмістом  елемента  є  тільки  вільна  текстова
інформація (секція PCDATA) :
<elementType id="flower">
<string/>
</elementType>
<any/> - вказує на те, що вмістом елемента  повинні  бути  тільки  елементи,
без тексту, незаключенного ні в один елемент:
<elementType id="issue">
<any/>
</elementType>
<mixed> - будь-яке сполучення елементів і тексту
<elementType id="contacts">
<mixed/>
</elementType>
<empty> - порожній елемент
Приклад:
<elementType id="title">
<string/>
</elementType>
<elementType id="chapter">
<string/>
</elementType>
<elementType id="chapters-list">
<any/>
</elementType>
<elementType id="content">
<element type="#chapters-list" occurs="OPTIONAL">
</elementType>
<elementType id="article">
<mixed><element type="#title"></mixed>
<element type="#content" occurs="OPTIONAL">
</elementType>

Що в імені твоєму?

Розширювана мова розмітки (Extensible Markup  Language,  XML)  дозволяє  вам
створювати свої власні теги, документувати їх за допомогою  визначень  типів
документів (Document Type  Definition,  DTD)  або  схеми  XML  і  потім  без
проблем обмінюватися даними з іншими  джерелами.  Все  це  добре,  але  може
виявитися, що інші використовують ті ж самі, що і ви, імена для елементів  і
атрибутів, але при цьому спираються на інші DTD. Це прямий шлях до  проблем.

Щоб уникнути подібних конфліктів W3C розробив  концепцію  просторів  імен  і
ключового   слова   xmlns.   Завдяки   їм   в   одному   документі    можуть
використовуватися імена елементів  і  атрибутів,  що  інакше  вступили  б  у
конфлікт один з одним. Тепер же вони різняться різними  префіксами  простору
імен і визначаються по різноманітним DTD або схемах.
От, наприклад, фрагмент коду XML із використанням просторів імен:
<inventory xmlns:storea=
«http://www.knowknew.com/
books.dtd» xmlns:storeb=
«http://www.amazon.com/schema»>
<storea:magazine>
<storea:title>Network
Magazine</storea:title>
</storea:magazine>
<storeb:magazine>
<storeb:magazine storeb:title=
«Data Communications»>
</storeb:magazine>
</inventory>
У визначенні 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 підвищує важливість моделювання і проектування даних.