Це черговий урок з основ XMLі в ньому ми розглянемо таку тему як простору імен. Якщо висловлюватись простими словами, то в XML просторі імен використовуються грубо кажучи для надання унікальності кожному окремому . Як ви пам'ятаєте з попередніх статей, кожен розробник, працюючи з XML, як би сам винаходить свою мову. У зв'язку з цим, щоб усі елементи документа були унікальні і несли свій зміст, використовуються так звані простори імен, мова про які і піде в цій статті.
Щоб краще зрозуміти всю суть сказаного вище, давайте розглянемо невеликий приклад. Допустимо у нас є документ, в якому використовуються кілька логічних схем, які мають однакові елементи, що використовуються у різних сенсах. Якби схема була однією, то особливих проблемне виникало б, але оскільки їх кілька, стає неможливим визначити, який елемент відноситься до якої схеми або які схеми використовуються в документі взагалі.
У зв'язку з цим були розроблені простору іменXML. Щоб розрізняти схеми документів, для кожної з них ставиться у відповідність спеціальний унікальний ідентифікатор ресурсу або URI. В результаті схеми будуть вважатися тотожними лише в тому випадку, якщо унікальні ідентифікатори збігатимуться. У зв'язку з цим як ідентифікатор найчастіше використовується адреса свого ресурсу.
Варто зауважити, що не обов'язково, щоб на цю адресу щось знаходилося. Обробник не переходитиме за посиланням і перевірятиме наявність будь-якої інформації. Вона використовується як унікальний ідентифікатор, а оскільки це ще й URL свого ресурсу, то навряд чи хтось буде використовувати його як ідентифікатор для своєї схеми.
Отже, з теорією ми розібралися. Тепер перейдемо безпосередньо до розгляду префіксів просторів імен та прикладів правильного їх використання.
Префікс просторів імен XML. Приклади використання просторів імен у XML та XSLT
Як уже говорилося трохи вище, простори імен задаються за допомогою унікальних ідентифікаторів URI. Щоб спростити роботу з ними, були розроблені спеціальні префікси просторів імен, які дозволяють легко визначити, якій схемі належить той чи інший елемент документа. Щоб це продемонструвати, розглянемо невеликий приклад.
<префикс:элемент xmlns:префикс="URI"> ...
Як видно з прикладу, префікси просторів імен задаються як атрибути з іменами, що починаються послідовністю xmlns. Якщо говорити про XSLT, то найчастіше використовується префікс xsl. Насправді все це виглядає так.
Як префікс просторів імен може використовуватися будь-яка інша назва, наприклад, ddd. У цьому випадку код буде виглядати так.
Наведені вище два приклади абсолютно ідентичні між собою і нічим не відрізнятимуться. Варто відразу зауважити, що створений префікс просторів імен може використовуватися тільки у власному імені та у вкладених елементах, але ніяк не за межами елемента, в якому він був створений. Для наочності розглянемо такий приклад.
Ще один момент, на який варто звернути увагу, те, що самі префікси не визначають елемент до тієї чи іншої схеми. Це роблять унікальні ідентифікатори, які поставлені у відповідність до цих префіксів. Таким чином, два елементи з різними префіксами, яким задані однакові ідентифікатори, будуть вважатися належать до однієї схеми. Щоб продемонструвати це, розглянемо такий приклад.
Незважаючи на те, що елементи stylesheet і text мають різні префікси, вони належать одній схемі, оскільки їх префіксам проставлені у відповідність однакові ідентифікатори. Таким чином, у документі може використовуватись будь-яка кількість префіксів просторів імен. Найчастіше всі вони визначаються в кореневому елементі, а потім використовуються в потрібному місці документа. І знову ще один приклад для демонстрації.
Існує ще один спосіб, що дозволяє не проставляти префікси в елементах. Для цього достатньо задати простір стандартних імен. У цьому випадку всі вкладені елементи належать до простору імен батьківського елемента. При цьому не втрачається можливість використовувати інші простори імен для дочірніх елементів. Для цього достатньо вручну прописати потрібний простір імен за допомогою атрибуту xmlns.
Тут варто звернути увагу, що елементи one і two будуть належати простору імен елемента thirdelement, оскільки він є для них батьківським. Як бачимо, тут простежується так зване спадкування. Якщо елемент не вказує простір імен, йому автоматично присвоюється простір імен найближчого батьківського елемента.
Зазвичай наведений вище спосіб не дуже популярний і найчастіше використовуються префікси просторів імен. Але в деяких випадках їх можна опустити та використати спосіб із завданням простору імен за замовчуванням. Щоб не залишалося жодних питань, розглянемо аналогічний спосіб подання останнього прикладу.
На цьому ми закінчуємо розгляд просторів імен та у наступній статті поговоримо про основні моменти опису за допомогою DTD. Якщо ви не хочете пропустити випуск нових статей, рекомендую підписатися на розсилку новин, скориставшись формою підписки нижче.
На цьому все. Успіхів вам і успіхів у вивченні XML.
Це черговий урок з основ XML і ми розглянемо таку тему як простору імен. Якщо виражатися простими словами, то в XML просторі імен використовуються грубо кажучи для надання унікальності кожному окремому. Як ви пам'ятаєте з попередніх статей, кожен розробник, працюючи з XML, як би сам винаходить свою мову. У зв'язку з цим, щоб усі елементи документа були унікальні і несли свій зміст, використовуються так звані простори імен, мова про які і піде в цій статті.
Щоб краще зрозуміти всю суть сказаного вище, давайте розглянемо невеликий приклад. Припустимо, у нас є документ, в якому використовуються кілька логічних схем, які мають однакові елементи, що використовуються в різних сенсах. Якби схема була однією, то особливих проблем не виникало б, але оскільки їх кілька, то стає неможливим визначити, який елемент відноситься до якоїсь схеми або які схеми використовуються в документі взагалі.
У зв'язку з цим були розроблені простору іменXML. Щоб розрізняти схеми документів, для кожної з них ставиться у відповідність спеціальний унікальний ідентифікатор ресурсу або URI. В результаті схеми будуть вважатися тотожними лише в тому випадку, якщо унікальні ідентифікатори збігатимуться. У зв'язку з цим як ідентифікатор найчастіше використовується адреса свого ресурсу.
Варто зауважити, що не обов'язково, щоб на цю адресу щось знаходилося. Обробник не переходитиме за посиланням і перевірятиме наявність будь-якої інформації. Вона використовується як унікальний ідентифікатор, а оскільки це ще й URL свого ресурсу, то навряд чи хтось буде використовувати його як ідентифікатор для своєї схеми.
Отже, з теорією ми розібралися. Тепер перейдемо безпосередньо до розгляду префіксів просторів імен та прикладів правильного їх використання.
Префікс просторів імен XML. Приклади використання просторів імен у XML та XSLT
Як уже говорилося трохи вище, простори імен задаються за допомогою унікальних ідентифікаторів URI. Щоб спростити роботу з ними, були розроблені спеціальні префікси просторів імен, які дозволяють легко визначити, якій схемі належить той чи інший елемент документа. Щоб це продемонструвати, розглянемо невеликий приклад.
<префикс:элемент xmlns:префикс="URI"> ...
Як видно з прикладу, префікси просторів імен задаються як атрибути з іменами, що починаються послідовністю xmlns. Якщо говорити про XSLT, то найчастіше використовується префікс xsl. Насправді все це виглядає так.
Як префікс просторів імен може використовуватися будь-яка інша назва, наприклад, ddd. У цьому випадку код буде виглядати так.
Наведені вище два приклади абсолютно ідентичні між собою і нічим не відрізнятимуться. Варто відразу зауважити, що створений префікс просторів імен може використовуватися тільки у власному імені та у вкладених елементах, але ніяк не за межами елемента, в якому він був створений. Для наочності розглянемо такий приклад.
Ще один момент, на який варто звернути увагу, те, що самі префікси не визначають елемент до тієї чи іншої схеми. Це роблять унікальні ідентифікатори, які поставлені у відповідність до цих префіксів. Таким чином, два елементи з різними префіксами, яким задані однакові ідентифікатори, будуть вважатися належать до однієї схеми. Щоб продемонструвати це, розглянемо такий приклад.
Незважаючи на те, що елементи stylesheet і text мають різні префікси, вони належать одній схемі, тому що їх префіксам проставлені у відповідність однакові ідентифікатори. Таким чином, у документі може використовуватись будь-яка кількість префіксів просторів імен. Найчастіше всі вони визначаються в кореневому елементі, а потім використовуються в потрібному місці документа. І знову ще один приклад для демонстрації.
Існує ще один спосіб, що дозволяє не проставляти префікси в елементах. Для цього достатньо задати простір стандартних імен. І тут всі вкладені елементи належать простору імен батьківського елемента. При цьому не втрачається можливість використовувати інші місця для дочірніх елементів. Для цього достатньо вручну прописати потрібний простір імен за допомогою атрибуту xmlns.
Тут варто звернути увагу, що елементи one і two будуть належати простору імен елемента thirdelement, оскільки він є для них батьківським. Як бачимо, тут простежується так зване спадкування. Якщо елемент не вказує простір імен, йому автоматично присвоюється простір імен найближчого батьківського елемента.
Зазвичай наведений вище спосіб не дуже популярний і найчастіше використовуються префікси просторів імен. Але в деяких випадках їх можна опустити та використати спосіб із завданням простору імен за замовчуванням. Щоб не залишалося жодних питань, розглянемо аналогічний спосіб подання останнього прикладу.
На цьому ми закінчуємо розгляд просторів імен та у наступній статті поговоримо про основні моменти опису за допомогою DTD. Якщо ви не хочете пропустити випуск нових статей, рекомендую підписатися на розсилку новин, скориставшись формою підписки нижче.
На цьому все. Успіхів вам і успіхів у вивченні XML.
Володимир Енгельс, Oracle СНД
Вступ
При реалізації типових SOA-проектів зазвичай створюється кілька XML-схем. У цих випадках проектувальник XML-схем повинен вирішити наступне питання:
- чи необхідно всім XML-схемам у проекті надавати різні значення targetNamespace
- або потрібно використовувати єдиний targetNamespace для всіх
- і чи можна деяким XML-схемам не надавати ніякого targetNamespace?
Який підхід буде оптимальнішим? Які посібники слід виконувати, починаючи роботу над SOA-проектами, в яких створюється кілька XML-схем?
Точності заради, слід зазначити, що є три проектні підходи під час роботи з кількома XML-схемами:
- гетерогенний простір імен- кожній XML-схемі присвоюється свій targetNamespace;
- гомогенний простір імен- всім XML-схемам присвоюється єдиний targetNamespace;
- простір імен типу "хамелеон"- головній XML-схемі присвоюється targetNamespace, а допоміжним XML-схем не присвоюється ніякого targetNamespace (XML-схеми без targetNamespace використовують targetNamespace головної XML-схеми при об'єднанні подібно до хамелеону).
Для опису та оцінки переваг та недоліків трьох зазначених проектних підходів наведемо приклади для кожного з них.
Приклад: XML-модель даних компанії
Уявімо собі проект, який вимагає створення моделі даних компанії, використовуючи XML-схеми. Ця модельстворюється у вигляді наступних трьох XML-схем:
- Company.xsd
- Person.xsd
- Product.xsd
Це можна охарактеризувати як "інформація про компанію включає дані по персони і по продукту". Наведемо три схеми кожного проектного підходу.
Гетерогенний простір імен
Цей проектний підхід передбачає використання кожної XML-схеми свого targetNamespace. Нижче наведено три схеми, спроектовані із застосуванням цього проектного підходу.
Product.xsd
Person.xsd
Company.xsd
Зверніть увагу, що у схемах використовується три різні простори імен:
http://www.product.org http://www.person.org http://www.company.org
Гомогенне простір імен
Цей проектний підхід передбачає використання єдиного targetNamespace для всіх XML-схем. Нижче наведено три схеми, спроектовані із застосуванням цього проектного підходу.
Product.xsd
Person.xsd
Company.xsd
Зверніть увагу, що у всіх трьох схемах використовується єдиний простір імен:
http://www.company.org
Також зверніть увагу, що для об'єднання XML-схем, які використовують єдиний простірімен, застосовується механізм
Простір імен типу "хамелеон"
Цей проектний підхід передбачає використання targetNamespace лише для головної XML-схеми, а допоміжним XML-схемам не присвоюється жодного targetNamespace. Нижче наведено три схеми, спроектовані із застосуванням цього проектного підходу. У даному прикладі XML-схема Company.xsd є головною, XML-схеми Product.xsd та Person.xsd – допоміжні.
Product.xsd (ні targetNamespace)
Person.xsd (ні targetNamespace)
Company.xsd
Зверніть увагу на два аспекти під час використання даного проектного підходу:
- для об'єднання XML-схем, що використовують простір імен "хамелеон", також використовується механізм
, та головна XML-схема має доступ до елементів допоміжних XML-схем; - допоміжні XML-схеми без targetNamespace в рамках даного проектного підходу мають наступну характеристику - компоненти XML-схем без targetNamespace використовують приведення простору імен (це означає, що компоненти приймають targetNamespace головної XML-схеми).
"Ефект хамелеону..."- цей термін запровадив Генрі Томпсон (Henry Thompson).
Вплив проектних підходів на XML-документи
Вище було продемонстровано, як могли б бути спроектовані XML-схеми із застосуванням трьох проектних підходів. Тепер звернемося до XML-документів. Чи відрізняється створення XML-документів залежно від застосування того чи іншого проектного підходу? Всі наведені вище XML-схеми були спроектовані з вимогою явного вказівки просторів імен в XML-документах (на що вказує: elementFormDefault="qualified"). Якби вони використовували натомість elementFormDefault="unqualified", то XML-документ для всіх трьох випадків мав би наступну форму:
Як виглядатимуть XML-документи для наших трьох підходів проектування?
Company.xml (для версії з гетерогенним простором імен у targetNamespace)
Зверніть увагу на таке:
- необхідно мати декларацію namespace для кожного простору імен;
- всі елементи повинні бути унікально кваліфіковані (явно або через простір імен "за замовчуванням").
Company.xml (для версії з гомогенним простором імен у targetNamespace)
Оскільки всі схеми належать одному простору імен, то в XML-документах для цієї ситуації можна скористатися перевагою використання простору імен "за замовчуванням".
Company.xml (для версії з простором імен типу "хамелеон" у targetNamespace)
Обидві XML-схеми без визначення targetNamespace прийняли targetNamespace XML-схеми Company.xsd (подібно до хамелеон-ефекту). Таким чином, всі компоненти належать одному targetNamespace, і в XML-документах для цієї ситуації також можна скористатися перевагою використання простору імен "за замовчуванням".
Елемент
- він виконує неявний
що дозволяє мати доступ до всіх компонентів у допоміжних схемах; - він дає можливість внести якесь число (нуль або більше) змін до визначення компонентів, що імпортуються, тобто розширити визначення компонентів або навпаки накласти додаткові обмеженнявизначення компонентів.
приклад. Розглянемо знову наведену вище XML-схему Company.xsd. Припустимо, що вона використовує елемент ProductType із Product.xsd. Додатково, під час використання необхідно розширити елемент ProductType і включити елемент ID (ідентифікатор продукту). Наведемо приклад, як це можна зробити, використовуючи елемент
Тепер елемент
Елемент
Простір імен "за замовчуванням" та проектний підхід типу "хамелеон"
Якщо XML-схема передбачає використання елемента
Як уникнути колізії імен під час використання підходу типу "хамелеон"
Колізія імен
Коли головна XML-схема використовує хамелеон-комоненти, ці компоненти стають частиною простору імен (вказаного в targetNamespace) головної XML-схеми, так як ніби проектувальник XML-схеми використовував in-line декларацію елементів і типів. Якщо головна схема включає (
Припустимо, існує дві XML-схеми без вказівки targetNamespace:
1.xsd A B 2.xsd A C
XML-схема 1.xsd визначає елементи A та B без вказівки простору імен.
XML-схема 2.xsd визначає елементи A та C без вказівки простору імен.
Тепер, якщо XML-схема 3.xsd включає (
3.xsd targetNamespace="http://www.example.org"
Зверніть увагу, що помилкою не є визначення двох елементів з однаковим ім'ям, якщо вони належать до одного типу. Якщо ж вони належать різним типам, це помилка, і має місце колізія імен.
Стандартним механізмом виключення колізій імен і є застосування просторів імен. Якби в наведеному вище прикладі компоненти XML-схем 1.xsd і 2.xsd перебували в різних просторах імен і вони були імпортовані в XML-схему 3.xsd, то колізії імен не виникло. [Зауважте, що два компоненти можуть мати однакове ім'я, якщо компоненти належать різним просторам імен.]
А як вирішити проблему колізії імен при використанні просторів імен типу "хамелеон"?
Вирішення проблеми колізії імен із застосуванням проксіруючих XML-схем
Існує дуже просте вирішення даної проблеми колізії імен: для кожної XML-схеми, що включається, без вказівки простору імен створюється допоміжна проксируюча XML-схема, в якій декларовано простір імен і яка сама вже включає (
Наведемо приклад, що демонструє даний проектний підхід:
1-proxy.xsd targetNamespace="http://www.1-proxy.org"
Застосовуючи цей проектний підхід, нам вдалося уникнути колізії імен. Більш того, цей проектний підхід має ще одну додаткову перевагу: в рамках проксуючих XML-схем також можна використовувати елемент
Таким чином, цей проектний підхід регламентує триступеневий процес:
- створити хамелеон-схеми;
- створити проксіруючі XML-схеми кожної хамелеон-схеми;
- імпортувати (
) проксіруючі XML-схеми в головну.
Використання цього триступеневого процесу дозволяє гнучкіше приймати рішення в проекті з приводу доменів (просторів імен) тих компонентів, які використовуються повторно. Більше того, з'являється можливість внести зміни до хамелеон-компонентів. Хоча в даному підході і використовується додатковий крок процесу (створення проксуючих XML-схем), все ж він має велику гнучкість.
Порівняємо даний триступінчастий процес з раніше описаним двоступінчастим процесом, в якому компонентам призначаються простори імен із самого початку існування компонента:
1-fixed.xsd targetNamespace="http://www.1-fixed.org" A B 2-fixed.xsd targetNamespace="http://www.2-fixed.org" A C main.xsd targetNamespace="http: //www.main.org"
Двоступінчастий процес дає той самий результат, що й триступінчастий. У цьому прикладі компоненти вже не є "хамелеонами", і елементи A, B і C жорстко прив'язані до відповідних просторів імен з початку життєвого циклу компонентів. Зворотний бік даного підходу - якщо в main.xsd знадобиться внести зміни до визначення компонентів з використанням
Засоби, що полегшують використання хамелеон-компонентів
Опис проблеми ідентифікації хамелеон-компонентів
Ми вже кілька разів спостерігали, що хамелеон-компоненти можуть змішуватись у схемах, які їх використовують. Це відбувається, коли вони приймають простір імен, що включають (
Припустимо, існують такі XML-схеми без визначення просторів імен:
1.xsd A B
Далі ми визначаємо головну XML-схему main.xsd, яка включає (
Main.xsd targetNamespace="http://www.example.org"
Припустимо, у процесі трансформації нам необхідно чітко ідентифікувати хамелеон-компонент A незалежно від того, до якого простору імен вони, можливо, належать у майбутньому. Як нам відрізнити хамелеон-компонент A від локально визначеного у XML-схемі компонента A?
Ідентифікація хамелеон-компонентів
Існує один простий засіб – при створенні хамелеон-компонента призначити йому глобально унікальний ідентифікатор (GUID). Специфікація XML Schema дозволяє додавати атрибут id для елемента, атрибута, а також компонентів простого і комплексного типів. Зверніть увагу, що атрибут id є виключно локальним для XML-схеми, і він ніколи не потрапляє в XML-документ. Саме цей атрибут можна використовувати для точної ідентифікації хамелеон-компонента незалежно від його поточного простору імен.
Питання: що станеться, якщо через проблеми мережі, XML-процесор не зможе отримати доступ до XML-схеми, що містить необхідні визначення?
Як і у випадку з DTD-визначеннями, відбудеться виняткова ситуація в XML-процесорі. Вирішення цієї проблеми - завжди зберігати копії використовуваних XML-схем локально.
Практика використання просторів імен XML у проектах
Вище описані проектні підходи стосовно використання просторів імен XML у проектах. Були розглянуті як XML-схеми, і XML-документи кожного з трьох проектних підходів.
Тепер залишилося відповісти на головне питання: який підхід кращий, і в якому разі?
Якщо у проекті використовується XML-схема, створена і контрольована кимось іншим, необхідно використовувати імпортування (
- дуже швидко локальна копія проекту розсинхронізується з іншими XML-схемами та...
- проект втратить здатність взаємодіяти з будь-яким додатком, що обробляє інші XML-схеми.
Цікавіша ситуація (ситуація, яка розглядалася як приклади), як вчинити з простором імен XML-схем, створюваних у рамках проекту і повністю підконтрольних одному проектувальнику (або групі). Нижче наведено кілька рекомендацій:
Використовуйте простір імен типу "хамелеон":
приклад. Репозиторій таких компонентів, як, наприклад, XML-схема, що визначає типи масиву, вектора, зв'язаного списку тощо, повинні визначатися без вказівки targetNamespace (тобто як хамелеон-XML-схема).
Якщо XML-схема містить лише визначення типів (відсутні декларації елементів), вона також хороший кандидат використання хамелеон- простору імен.
Використовуйте гомогенний простір імен:
- якщо всі XML-схеми концептуально співвідносяться одна з одною;
- якщо немає необхідності візуально ідентифікувати в XML-документі належність елементів та атрибутів тій чи іншій XML-схемі. При цьому підході всі компоненти належать одному простору імен і, таким чином, втрачається можливість ідентифікувати в документі XML, що "елемент A визначений у схемі X". Часто це нормально, що проектувальник не бажає категоризувати окремо елементи чи атрибути. І тут гомогенний простір імен цілком підходить.
Використовуйте гетерогенний простір імен:
І, нарешті, як було продемонстровано вище, у XML-схемах кожен компонент може бути унікально ідентифікований з використанням атрибуту id (це не те саме, що оголосити атрибут id для елемента; це внутрішній механізм XML-схем для ідентифікації кожного компонента XML-схеми ). Використання атрибута id для ідентифікації кожного компонента XML-схеми дає навіть більший контроль над компонентом, аніж за використання просторів імен. Комбінація цих двох засобів - просторів імен та атрибутів id компонентів XML-схем - потужний тандем, що дозволяє надійно ідентифікувати комоненти XML-схем як візуально, так і програмно.
При створенні документа XML ми можемо зіткнутися з тим, що різні за змістом елементи матимуть однакове ім'я. Ви можете побачити приклад у статті «10 головних помилок RSS» у пункті 5 «Неправильне розширення RSS».
Розберемо приклад, явно «притягнутий за вуха», проте простий для розуміння. Нам необхідно зробити вибірку із двох таблиць бази даних, що стосуються творчості якогось музичного колективу та сформувати каталог у вигляді XML-документу. В одній таблиці бази даних міститься інформація про аудіо записи колективу, в іншій - інформація про книги присвячені його творчості. З якоїсь причини (незрозуміло якою, але дуже важливою), і опис аудіо записів та опис книг має міститися в елементі «item». З тієї ж причини, і назви записів та назви книг повинні міститися в елементі "title".
В результаті отримуємо щось на кшталт цього:
В наявності конфлікт імен, оскільки складно визначити, який вид даних містить кожен з елементів «item» і «title». Перший блок item відноситься до дискографії і елемент title містить назву диска. Другий блок "item" відноситься до бібліографії і елемент "title" містить назву книги. Для запобігання такому конфлікту нам треба розділити ці групи логічно. Робиться це завданням простору імен: одні елементи відносяться до імені "music", інші - до імені "book". Для оголошення простору імен використовується атрибут ім'я якого складається з зарезервованого слова « xmlns », після якого слідує двокрапка і, власне, саме ім'я:
Xmlns:music = "http://ininfo.biz/music"
Перше питання, яке виникає, що використовувати як значення атрибуту xmlns? Для того, щоб забезпечити унікальність простору імен, треба використовувати будь-який, простіше кажучи — унікальний рядок, який однозначно ідентифікуватиме цей елемент * . Багато хто використовують як ідентифікатор URL , тому що імена доменів, які використовуються в URL є унікальними. Крім того, навряд чи хтось буде використовувати адресу "http://ininfo.biz/book" крім його власника, так що конфлікт виключено.
Простір імен для елементів
Вказівка на те, до якого простору імен відноситься той чи інший елемент, записується перед початком імені елемента з роздільником у вигляді двокрапки:
Виходячи з вищевикладеного, в принципі можна оголосити простір імен для кожного елемента, який використовується в документі:
Погодьтеся, це найкращий варіант, оскільки по-перше, треба набирати багато тексту; по-друге, такий код важко читати; по-третє, легко наробити помилок. Можна зробити іншим чином використовуючи правило:
Простір імен, оголошений для будь-якого елемента, є таким для всіх вкладених у нього елементів, якщо для них не оголошено інших просторів імен.
Можна зробити ще простіше — оголосити всі простори імен за один раз у кореневому елементі:
Однак слід пам'ятати, що ідентифікатором простору імен є значення атрибуту xmlns, а не його назва-префікс. У наступному прикладі всі елементи належать одному простору (значення атрибуту дорівнює "http://ininfo.biz/group") хоча і мають різні імена-префікси ("music" і "book"):
Допускається і зворотне – елементи мають різні простори імен, але використовують однакові імена-префікси:
Можна обійтися без імен-префіксів. Для цього треба задати простір імен за замовчуванням. У цьому випадку цей простір буде використовуватися для елемента, в якому він зустрічається і для всіх його дочірніх елементів.
Для того, щоб скасувати простір імен заданий за замовчуванням, необхідно присвоїти атрибуту xmlns значення порожнього рядка:
Простір імен для атрибутів елементів
Також як і елементи, до заданого простору імен можуть бути віднесені та їх атрибути:
Однак простір імен за замовчуванням на атрибути не розповсюджується. Якщо атрибут не має префіксу, то він не належить до жодного простору імен:
Вищевикладене вірно і випадку, коли простір імен заданий для елемента, якого належить атрибут, наприклад:
Щоб дуже заплутатися, можна назвати, що оголошення простору імен діє у межах елемента, у якому воно зустрічається:
Можливо, цю статтю буде доповнено. Тому продовження слідує і слідкуйте за оновленнями .
* У громадянина РФ унікальним ідентифікатором може вважатися його ІПН. Не номер паспорта — паспорт тричі змінюється і у разі втрати виписується новий.
Анотація: У цьому розділі описується використання та декларація просторів імен. Даються основні характеристики RDF, XML-Data, Document Content Description (DCD), Schema for Object-Oriented XML (SOX), Document Definition Markup Language (DDML, раніше відомий як XSchema).
Раніше ми описали деякі недоліки визначень DTD, вони пов'язані:
- синтаксис цих визначень відрізняється від синтаксису XML (конкретно, використовується так звана розширена форма Бекуса-Наура, Extended Backus Naur Form);
- ці визначення недостатньо виразні;
- Так як кожен користувач може створювати свої власні теги, то цілком ймовірна ситуація коли для позначення різних речей люди будуть користуватися одними і тими самими іменами елементів. Навіть якщо значення елементів однакові, їх можливий зміст може змінюватись залежно від визначення. Таким чином, нам необхідний спосіб, що дозволяє визначати конкретні види використання елемента, особливо якщо в одному документі ми змішуємо різні види словників. Для вирішення проблеми консорціум W3C випустив специфікацію, що називається XML Namespaces (простір імен XML), що дозволяє визначити контекст елемента в просторі імен.
- існують ситуації, коли необхідно скомбінувати документи XML із різних джерел, що відповідають різним визначенням DTD . Наприклад, така ситуація виникає при описі великого обсягу інформації, якщо окремих DTD недостатньо для охоплення всього обсягу або вони складні для розуміння. Виникає вона і в системах електронної комерції під час спроб об'єднати дані вашого ділового партнера з вашими. Так само може виникнути ситуація, коли необхідно просто додати свої налаштування до вже існуючої DTD для того, щоб обмінюватися деякою інформацією в стандартному форматі. На жаль, рекомендація XML не надає способу суміщення декількома DTD в одному документі без їх модифікації або створення нового DTD (використовуючи зовнішні посилання).
У цьому розділі розглядаються такі два поняття - простір імені схеми XML. Простір імен дозволяє розробникам XML розбивати складну проблему на невеликі фрагменти і об'єднувати кілька словників в одному документі для її повного опису. За допомогою схем проектувальники словників створюють більш точні визначення, ніж це було можливо в DTD, причому роблять це, використовуючи синтаксис XML.
Ці два інструменти допомагають вирішувати складні завдання, що виникають під час використання XML . Простори імен і схем дозволяють проектувальникам і програмістам XML :
- Краще організовувати словники на вирішення складних проблем;
- Зберігати сильну типізаціюданих при перетвореннях на XML та з нього;
- Більш точно та гнучко описувати словники, ніж це було можливо у випадку DTD;
- Читати правила словника мовою XML, здійснюючи доступом до його визначенням без ускладнення аналізатора.
Змішування словників
При проектуванні словника може бути сенс розбити глобальну проблему кілька складових частин. І тому необхідні способи сегментації великої проблеми кілька словників. Однак, при цьому справжня проблема, яку потрібно вирішити, пов'язана з об'єднанням окремих DTD у тілі одного документа. Ця проблема може виникнути і у випадку, якщо ви, наприклад, працюєте на корпорацію в якій, швидше за все, вже існує набір визначень DTD і їх використання може суттєво полегшити роботу, тому що вони описують проблему так, як її розуміють інші. Часто також корисно повторне використання визначень DTD , тобто. використання загальних конструкцій із раніше створених визначень DTD. Якщо ви розробляєте програму, яка повинна зв'язуватися з програмами зовнішнього партнера, вам практично нічого не залишається, крім повторного використання існуючих концепцій. Наявні визначення DTD становлять загальноприйняту мову, якою треба говорити, щоб бути зрозумілою. Якщо концепція вже існує, треба працювати так, щоб бути зрозумілим у термінах цієї концепції.
Коли ви використовуєте корисні для вас визначення з DTD інших розробників або комбінуєте сегментовані DTD для створення документа, що описує складну проблему, якщо у ваших документах використовуються елементи з однаковими іменами, ви ризикуєте зіткнутися з проблемою неясності та колізії імен.
Проблема ще більше загострюється під час використання екземплярів імен із кількох DTD. У цьому випадку ми не знаємо, який елемент, який визначення DTD посилається, така проблема правильно оформлених документів називається неясністю. Більше того, якщо імена документа вимагають перевірки допустимості, ми можемо дуже сильно "заплутати" наш додаток. Ця проблема називається колізією імен.
Простір імен
Простір імен здатний допомогти користувачеві у двох дуже важливих випадках. З їх допомогою можна:
- поєднувати документи з двох або більше джерел, не втрачаючи при цьому впевненості, що програма розрізнить, з якого джерела взято той чи інший елемент чи атрибут;
- по можливості дозволить агенту користувача доступ до подальшого матеріалу, такого як визначення типу документа (DTD) або іншого опису елементів та атрибутів.
Простір імен являє собою сукупність деяких величин або характеристик, які можуть бути використані в документах XML як імена елементів або атрибутів. Простори імен у XML визначаються уніфікованим ідентифікатором ресурсу URI (як URI можна використовувати адресу DTD на вашому сервері). Він дозволяє кожному простору імен бути унікальним.
Отже, для того, щоб ефективно використовувати простір імен у документі, що комбінує елементи з різних джерел, нам треба визначити:
- Посилання на URI, що описує використання елемента.
- Псевдонім, що дозволяє зрозуміти, із якого простору імен взято наш елемент. Цей псевдонім має форму префікса елемента (наприклад, якщо псевдонімом для неясного елемента Book є слово catalog , то елемент буде називатися
Використання та декларація просторів імен
Декларація простору імен
Оскільки у різних мовах розміток - реалізаціях XML - можуть зустрітися одні й самі імена тегів та його атрибутів, мають зовсім різний зміст, треба мати можливість їх якось розрізняти. Для цього імена тегів та атрибутів забезпечують коротким префіксом, який відокремлюється від імені двокрапкою. Префікс імені зв'язується з ідентифікатором, який визначає простір імен (namespace). Усі імена тегів і атрибутів, префікси яких пов'язані з тим самим ідентифікатором, утворюють одне простір імен, у якому імена мають бути унікальні.
Оскільки необхідно, щоб зустрівши декларацію простору імен кожен міг розпізнати її, для нього зарезервуємо спеціальне слово. Відповідно до рекомендацій просторів імен це слово xmlns . Значенням атрибута є ідентифікатор URI, що визначає простір імен, що використовується. Часто це адреса URL визначення DTD, але так має бути не завжди. Префікс та ідентифікатор простору імен визначаються атрибутом xmlns наступним чином:
Як бачите, префікс ntb щойно визначено, але його можна використовувати в імені ntb: notebook . Надалі імена тегів та атрибутів, які ми хочемо віднести до простору імен http://some.firm.com/2003/ntbml , мають префікс ntb, наприклад:
Крім того, в одному тезі можуть траплятися відразу кілька просторів імен. Нижче наводиться приклад змішування кількох просторів імен:
Елемент book взятий з простору імен catalog, а атрибут ISBN – з order.
Ім'я разом із префіксом, наприклад
називається розширеним, уточненим або кваліфікованим ім'ям (OName. Qualified Name). Частина імені, записана після двокрапки, називається локальною частиною (local part) імені.
Номенклатура назв Web-ресурсів може заплутати. Універсальний покажчик ресурсу ( Uniform Resource Locator , URL) вказує на ресурс у термінах протоколу доступу та розташування в мережі. Універсальний ідентифікатор ресурсу ( Uniform Resource Identifier, URI) є унікальне ім'я деякого ресурсу. Дивіться на URI просто як на унікальний рядок символів, що ідентифікує простір імен.
За правилами SGML і XML, двокрапка може застосовуватися в іменах як звичайний символ, тому ім'я з префіксом - це просто фокус, будь-яка програма, яка "не знає" простору імен, аналізуючи документ, розглядає уточнене ім'я як звичайне ім'я. Звідси випливає, зокрема, що в оголошенні типу документа(Document Type Declaration) не можна опускати префікси імен.
Атрибут xmlns може з'явитися у будь-якому елементі XML, а не лише у кореневому. Визначений ним префікс можна застосовувати в тому елементі, в якому записано атрибут xmlns і у всіх вкладених в нього елементах. Більше того, в одному елементі можна визначити декілька просторів імен.
У вкладених елементах простір імен можна перевизначити, зв'язавши префікс з іншим ідентифікатором.
Поява імені тега без префікса в документі, що використовує простір імен, означає, що ім'я належить простору стандартних імен (default namespace ).
Добре оформлений документ повинен використовувати простір імен для всіх своїх елементів.
Префікси, що починаються з символів xml з будь-яким регістром букв, зарезервовані за мовою XML. Префікс xmlns використовується для зв'язку іншого, який визначається, префікса з ідентифікатором його простору імен. Префікс xmlns не потрібно визначати, він введений рекомендацією "Namespaces in XML" і пов'язаний там з ідентифікатором простору імен http://www.w3.ori/2000 /xmlns/.
Ще один префікс, xml, пов'язаний з тією ж рекомендацією з ідентифікатором http://www.w3.org/XML/1998/namespace. Його теж не потрібно визначати у документі XML. Жодний інший префікс не може бути пов'язаний з цими ідентифікаторами. Це важливо для деяких текстів, наприклад програмних кодів. Значення default залишає пробілові символи на розсуд програми-обробника.
Область дії
У декларацій просторів імен є область дії, як і, як в декларацій змінних у мовах програмування. Це важливо, оскільки простори імен не завжди декларуються на початку документа XML, іноді це робиться в наступних розділах. Декларація простору імен може бути застосована до елемента, в якому вона з'являється, а також до нащадків цього елемента, навіть якщо вона не визначена там явно. Ім'я може посилатися на простір імен, лише якщо використовується у сфері дії його декларації.
Однак нам потрібно також змішувати області дії просторів імен в елементах, які інакше успадкували б інші простори імен. У зв'язку з цим визначено два способи декларації області дії-default (за замовчуванням) та qualified (кваліфікований).
Область дії за умовчанням
Як і слід очікувати, необхідність додавання префікса до кожного імені в документі швидко стає стомлюючою. Фактично, запровадивши концепцію сфери дії імені, ми можемо змішувати в нашому документі велику кількість префіксів. Якщо ми визначаємо простір імен за замовчуванням, то передбачається, що йому належать усі некваліфіковані імена у сфері дії його декларації. Таким чином, простір імен, оголошений за промовчанням у кореневому елементі, вважається простір за промовчанням для всього документа і може бути перекритий тільки більш специфічним простір імен, оголошеним всередині документа.
Щоб простір імен зробити простір імен за замовчуванням для певної області, достатньо опустити декларацію префікса.
Якщо префікс оголошено, а потім використано спільно з ім'ям, то кажуть, що простір імен явно встановлено. Щоб віднести до простору імен некваліфіковане ім'я, необхідно оголосити простір за промовчанням, який включає це некваліфіковане ім'я (без префіксу).
Кваліфікована сфера дії
Описаний вище метод працює добре, якщо ви можете чітко поділити ваші простори імен. Але іноді буває необхідно включити до документа окремі імена із зовнішніх просторів імен. Замість того, щоб декларувати простір імен для цілої області, можна використовувати кваліфіковані імена. Оголосіть потрібні простори імен на початку документа, а потім кваліфікуйте їх у місці використання.
