JEWeell Home | About Project

XML Питання та відповіді

Частина I: Огляд 1) Розділ 1: РЕЗЮМЕ 1,1) Чи можете ви дати мені резюме про те, що XML простору імен? Звичайно. Ось вона в п'ять простих пунктів кулі. XML рекомендації імен визначає спосіб розрізняти дублікати типу імен елементів і атрибутів. Таке дублювання може виникнути, наприклад, при перетворенні або в документі, який містить типи елементів і атрибутів з двох різних DTD. Простір імен XML являє собою набір типів елементів і атрибутів. Простір імен ідентифікується унікальним ім'ям, яке є URI посилання. Таким чином, будь-який тип елемента або атрибута ім'я в просторі імен XML можуть бути однозначно визначені на дві частини назви: ім'я його XML-простору імен і локального імені. Це дві частини система іменування є єдиним визначається XML рекомендація просторів імен. XML простору імен, оголошені з атрибутом XMLNS, які можна пов'язати з префіксом простору імен. Декларація в області для елемента, що містить атрибут і всіх його нащадків. Наприклад:
  <!-- Declares two XML namespaces. Their scope is the A and B elements. -->
  <A xmlns:foo="http://www.foo.org/" xmlns="http://www.bar.org/">
     <B>abcd</B>
  </A>
Якщо декларація XML простір імен містить префікс, ви посилаєтеся на тип імена елементів і атрибутів в цьому просторі імен з префіксом. Наприклад:
<!-- A and B are in the http://www.foo.org/ namespace,
          which is associated with the foo prefix. -->
  <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B>abcd</foo:B>
  </foo:A>
Якщо декларація XML простір імен не містить префікс простору імен є простором імен за замовчуванням XML і ви посилаєтеся на тип елемента імена в цьому просторі імен без префікса. Наприклад:
 <!-- This is equivalent to the previous example but uses
          a default namespace instead of the foo prefix. -->
  <A xmlns="http://www.foo.org/">
     <B>abcd</B>
  </A>
1,2) Чи можете ви дати мені резюме про те, що XML простору імен немає? Вони не є панацеєю від раку, вони не спосіб виграти в лотерею, і вони не є безпосередньою причиною миру в усьому світі. Вони також не дуже складно зрозуміти і використати. Дві речі, які XML простору імен не викликали багато плутанини, тому ми будемо згадувати їх тут: XML простору імен не є технологією для приєднання XML документи, які використовують різні DTD. Хоча вони можуть бути використані в таких технологій, вони не дають його самі. URI посилання, які використовуються в якості імен XML простору імен не гарантується вказують на схеми, інформацію про простір імен, або що-небудь ще - вони просто ідентифікатори. URI посилання були використані просто тому, що URI, є відомі системи для створення унікальних ідентифікаторів. Навіть не думайте про спробу вирішити ці URI посилання. (Більш детальну інформацію див питання 14.6.) 2) Розділ 2: ТРАДИЦІЙНІ NAMESPACES 2,1) Що таке традиційне простір імен? Перш ніж обговорювати простору імен XML, корисно обговорити імен в цілому. У цьому FAQ, ми будемо називати імен таких як традиційних імен. Ми будемо називати імен XML як XML простору імен. Слово імен може ставитися або до традиційних імен або імен XML, в залежності від контексту, але в цілому ставляться до XML простору імен. Традиційних імен являє собою набір з нуля або більше імен, кожне з яких має бути унікальним в межах простору імен і побудований відповідно до правил (якщо такі є) простору імен. Наприклад, імена типів елементів в документі XML мешкають традиційних імен, як і імена таблиць в реляційної бази даних та імена змінних класу в клас Java. Традиційні імен також відбуваються за межами області комп'ютерної науки - наприклад, імена людей, можна розглядати мешкати в традиційних імен, так само як і назви видів. 2,2) Яка взаємозв'язок між різними традиційних імен? Вони не перетинаються - тобто, вони не пов'язані. Через це назви в одній традиційної імен не стикаються з тими ж іменами в різних традиційних імен. Ця властивість корисно для додатків, які мають декілька наборів імен. Призначаючи кожен набір імен різних традиційних імен, вони можуть дозволити тим же ім'ям відбуватися в кожен набір імен, не побоюючись зіткнення. Наприклад, в наступному документі XML, немає конфлікту між трьома різними використання імені Value.
 <AuctionItem>
     <Title Value="486Laptop"/>
     <Category Value="Computers"/>
     <Value>$100</Value>
  </AuctionItem>
Це тому, що документ XML має одне традиційне простір імен для типів елементів, і для кожного типу елемента, одне традиційне простір імен для імен атрибутів, які застосовуються до цього типу елемента. Таким чином, два імені, значення атрибута не суперечать, тому що кожен призначений різних традиційних імен - перший атрибут простору імен для типів назва елемента, а другий атрибут простору імен для типів елементів категорії. Крім того, жодна із значення атрибуту імена конфлікти з ім'ям типу елемента значення, тому що імена елементів типу зберігаються в традиційних імен, яке є окремим від атрибута простору імен. Інші приклади додатків, що використовують кілька традиційних імен включають в себе:
  • Java-класи. У класі Java, є одне традиційних імен для імен змінних класу, один традиційний імен для імен методів, і для кожного методу, одне традиційне простір імен для імен локальних змінних цього методу.
  • Реляційних баз даних. У реляційній базі даних, є одне традиційних імен для імен таблиці та для кожної таблиці, одна традиційних імен для імен стовпців в цій таблиці.
2,3) Які традиційні простору імен, що використовуються для? Мабуть, найбільш поширеною (інформатика) використання традиційних імен є створення контейнера для набору ідентифікаторів. Наприклад, традиційні імен використовуються для зберігання імен (ідентифікаторів) типів елементів в документі XML, імена змінних класу в клас Java, а імена таблиць в реляційної бази даних. Традиційні імен корисні в цьому відношенні, тому що їх вимога, що кожне ім'я в просторі імен бути унікальним. Таким чином, якщо нове ім'я (ідентифікатор) додається до простору імен, унікальності ідентифікатора може бути перевірена шляхом перевірки того, що ім'я не існує в просторі імен. (Зверніть увагу, що тільки тому, що безліч об'єктів черпає свої імена від деяких традиційних імен не означає, що ці імена однозначно ідентифікувати об'єкти. Наприклад, дві різні людини можуть мати однакові назви, так само як два різних вузлах елемента в дерево DOM, які використовують тип елемента імена, як їхні імена. для імен в традиційних імен для унікальної ідентифікації об'єктів в наборі, об'єкти в наборі повинні залучити їх імена тільки з цього простору імен і ім'я не може бути застосований до більш ніж одному об'єкту. на практиці, імена з одного традиційного простору імен використовуються тільки для ідентифікації об'єктів в єдиний комплекс, в іншому випадку, додаткова інформація повинна зберігатися заявивши, імена яких поширюється на якому встановлений). 3) РОЗДІЛ 3: простору імен XML 3,1) Яка мета простору імен XML? Простору імен XML самого початку були призначені для забезпечення універсальних унікальних імен для елементів і атрибутів. На практиці вони використовуються в XML-технологий, коли унікальні імена потрібні, такі як складні назви типу в XML-схем і імена функцій в XQuery. Цей FAQ присвячений перший випадок, але більшість з того, що він обговорює відноситься і до більш широкої випадках. Як приклад того, чому XML простору імен необхідно, розглянемо наступні два XML-документів:
 <?xml version="1.0" ?>
  <Address>
     <Street>Wilhelminenstr. 7</Street>
     <City>Darmstadt</City>
     <State>Hessen</State>
     <Country>Germany</Country>
     <PostalCode>D-64285</PostalCode>
  </Address>
і:
  <?xml version="1.0" ?>
  <Server>
     <Name>OurWebServer</Name>
     <Address>123.45.67.8</Address>
  </Server>
Кожен документ використовує інший XML мову і кожна мова визначає тип адреси елемента. Кожен з цих типів адрес елемент відрізняється від інших - тобто, кожен має різні моделі змісту, інший зміст, і інтерпретується додатком по-іншому. Це не проблема, поки ці типи елементів існують тільки у вигляді окремих документів. Але що, якщо ми хочемо, щоб використовувати їх в тому ж документі, таких як список підрозділів, їх адреси, і їх веб-серверів? Як додаток знаєте, який тип адреси елемента він обробляє? Одним з рішень є просто перейменувати один з типів Адреса елементів - наприклад, ми могли б перейменувати другий тип елемента IP-адресу. Тим не менш, це не корисно довгострокове рішення. Одна з надій XML є те, що люди будуть стандартизувати XML мови для різних предметних областях і писати модульний код для обробки цих мов. Повторне використання існуючих мов і кодів, люди можуть швидко визначити нові мови і писати програми, які обробляють їх. Якщо ми перейменуємо другий тип елемента адреси в IP-адресу, ми розіб'ємо будь-якого коду, який очікує, що стара назва. Кращою відповіддю є призначення кожної мови (в тому числі його тип елемента Address) в інший простір імен. Це дозволяє нам продовжити використання адреси імені в кожній мові, але різниця між двома різними типами елементів. Механізм, за допомогою якого ми робимо це XML простору імен. Наприклад, наступний документ використовує простір імен XML розрізняти два різних типи елемента з іменем Address.
<Department>
     <Name>DVS1</Name>
     <addr:Address xmlns:addr="http://www.tu-darmstadt.de/ito/addresses">
        <addr:Street>Wilhelminenstr. 7</addr:Street>
        <addr:City>Darmstadt</addr:City>
        <addr:State>Hessen</addr:State>
        <addr:Country>Germany</addr:Country>
        <addr:PostalCode>D-64285</addr:PostalCode>
     </addr:Address>
     <serv:Server xmlns:serv="http://www.tu-darmstadt.de/ito/servers">
        <serv:Name>OurWebServer</serv:Name>
        <serv:Address>123.45.67.8</serv:Address>
     </serv:Server>
  </Department>
Перші Адреса тип елемента назва відноситься до http://www.tu-darmstadt.de/ito/addresses XML простору імен. Вона має розширену (дві частини) назву "http://www.tu-darmstadt.de/ito/addresses" плюс "Адреса". (У відповідності з Конвенцією в статті Джеймсом Кларком, запишемо це як {} Адреса http://www.tu-darmstadt.de/ito/addresses.) Другий Адреса тип елемента назва відноситься до http://www. tu-darmstadt.de/ito/servers XML простору імен і має розширене ім'я {} http://www.tu-darmstadt.de/ito/servers адресу. Таким чином, кожен розширив ім'я є унікальним, що відповідають вимогам, що кожен тип елемента в документі XML мати унікальне ім'я. (Зауважимо, що, призначаючи кожною Адреса ім'я простору імен XML, ми насправді змінити назву на дві частини ім'я, що складається з назви простору імен XML, а також ім'я-адресу. Це означає, що будь-який код, який визнає тільки ім'я Адреса знадобляться бути змінені, щоб визнати нове з двох частин назви Однак, це тільки має бути зроблено відразу, як дві частини назви (розширене назва) універсальних унікальних Для отримання додаткової інформації про унікальність розширених імен, див. питання 12.16 .. Для отримання додаткової інформації про обробку розширених імен, див. питання 11.1.) 3,2) Які деякі приклади того, як простору імен XML використовуються? Простору імен XML, які використовуються в ряді напрямків. Наприклад:
  • Багаторазові схем. Багато промислові групи розробили свої власні XML-схем. Щоб уникнути зіткнення з загальними іменами в інших схемах, всі вони призначили одного або декількох XML-простору імен для своїх схем. В результаті, можна повторно використовувати елементи та атрибути, визначені в цих схем в нових схем, не побоюючись конфліктів імен. Наприклад, SVG, XHTML, XLink, MathML, і Dublin Core є хорошими кандидатами для включення в інших мовах, так як вони забезпечують чіткі і широко підтримуються елементів і атрибутів (відповідно) графіка, текст, посилання, математики і метаданих.
Наприклад, SVG використовує XLink для її ланок. У наступному фрагменті (від SVG рекомендації) показує атрибуту XLink HREF, який пов'язує еліпс на домашній сторінці W3C.
   <?xml version="1.0" standalone="no"?>
   <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
      "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
   <svg width="5cm" height="3cm" viewBox="0 0 5 3" version="1.1"
        xmlns="http://www.w3.org/2000/svg"
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <desc>Example link01 - a link on an ellipse</desc>
      <rect x=".01" y=".01" width="4.98" height="2.98" 
            fill="none" stroke="blue"  stroke-width=".03"/>
      <a xlink:href="http://www.w3.org">
         <ellipse cx="2.5" cy="1.5" rx="2" ry="1" fill="red" />
      </a>
   </svg>
Extensible схем. Мови, таких як XML-схем, DocBook, DITA, HL7, FIXML, і Мец були розроблені з урахуванням можливості розширення. Іншими словами, мова або місця, де користувальницькі елементи як очікується, будуть включені або автори цих схем просто чекати користувачам змінювати їх відповідно до їх потреб. Наприклад, ряд компаній використовує XML-схеми в якості основи для XML-на-реляційних баз даних мов відображення, додавши відображення інформації як всередині XS: AppInfo елемент або як атрибути в XS: елемент і XS: атрибут елементів. Наступний фрагмент показує деякі з розширень використовується Microsoft SQL Server 2005:
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
               xmlns:sql="urn:schemas-microsoft-com:mapping-schema">
      <xs:annotation>
         <xs:appinfo>
            <sql:relationship name="CustomerOrderHeader"
               parent="Sales.Customer"
               parent-key="CustomerID"
               child="Sales.SalesOrderHeader"
               child-key="CustomerID" />
            <sql:relationship name="OrderHeaderOrderDetail"
               parent="Sales.SalesOrderHeader"
               parent-key="SalesOrderID"
               child="Sales.SalesOrderDetail"
               child-key="SalesOrderID" />
         </xs:appinfo>
      </xs:annotation>
      <xs:element name="Customer" sql:relation="Sales.Customer" >
      ...
   </xs:schema>
Зверніть увагу, що розширення визначається Microsoft використовують різні простори імен XML від використовуваного XML-схем. Поки код, який обробляє XML-схеми (наприклад, перевіряючий парсер) ігнорує елементи і атрибути з простору імен XML не визнати, що код буде продовжувати працювати, навіть якщо елементи і атрибути, визначені Microsoft присутні.
  • Довільні XML плюс обробка XML. Існує великий клас XML мови, які включають довільні XML плюс деякі XML, що дає обробки інформації. Два найбільш відомих прикладів цього типу мови XSLT і SOAP.
XSLT стилів складаються з довільних елементів і атрибутів (які були скопійовані безпосередньо на вихід), а також елементи та атрибути з мов XSLT, які визначають, як перетворити вхідний документ. SOAP документів складається з конверта, заголовка і тіла. На конверті діє як контейнер для заголовків і тіла, заголовок містить додаткову інформацію (наприклад, контекст повідомлення або обробки інформації), а тіло містить саме повідомлення. SOAP визначає конверта, заголовка і тіла елементів, в той час як користувачам визначити вміст заголовка і тіла. Наприклад, наступний документ містить SOAP повідомлення, щоб запросити ціну акцій IBM. Зверніть увагу, що повідомлення (всередині мила: Body елемента) використовує різні простори імен з SOAP елементи.
   <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
      <soap:Body>
         <stock:GetPrice xmlns:stock="http://www.foo.org/stockprices">
            <stock:Symbol>IBM</stock:Item>
         </stock:GetPrice>
      </soap:Body>
   </soap:Envelope>
Без XML простору імен, таких мов не існує. Це тому, що XML простору імен є єдиним способом відрізнити елементів і атрибутів при обробці XML з довільного XML. Якщо XML простору імен не були використані, завжди буде можливість зіткнення імена в довільному XML та імена в обробці XML.
  • Багаторазові код. Код тому, що процеси XML повинен визнати, імена елементів і атрибутів. Оскільки XML-простору імен, зробити це можна написати такий код, не турбуючись про елементом і зіткнення ім'я атрибута, в результаті код може бути використаний у різних додатках. Наприклад, існують плагіни для відтворення зображень для SVG і MathML. Коли браузер зустрічає елемент з простору імен SVG і MathML, його можна передати від обробки в плагіні. Інший клас багаторазового код XQuery вирази для вирішення конкретних завдань, наприклад, для отримання інформації про маршрутизації від SOAP повідомлення.
  • Версії. Простору імен XML іноді використовуються, щоб забезпечити інформацію про версії. Тобто, новий простір імен використовується, коли нова версія мови виділяється, що не має зворотної сумісності зі старою версією. Тому що це призводить нові імена елементів і атрибутів, не існує побоювання, що додатки, призначені для обробки стара версія мови буде неправильно обробляє документ, відповідний новій версії. Замість цього, вони не визнають новий простір імен і або ігнорувати документ або повертає помилку. Це особливо важливо, коли елемент або атрибут залишається незмінним (крім своїх імен), але має іншу семантику. Більш докладну інформацію про XML простору імен і версій, див Простори імен та версій по Уче Ogbuji.
  • Простір імен на основі перевірки. Простір імен на основі перевірки диспетчерського мови (NVDL) дозволяє користувачам вказувати, як перевірити документ відповідно до XML-простору імен елементів і атрибутів. Основна ідея полягає в тому, що документ розділений на піддерев, з елементами і атрибутами в кожному піддереві обмін одного XML простору імен. NVDL Потім скрипт відображає кожне простір імен XML у схемі використовуються для перевірки елементів і атрибутів в цьому просторі імен.
Наприклад, наступний документ XHTML містить вбудований Scalable Vector Graphics (SVG) документа:
  <html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:svg="http://www.w3.org/2000/svg">
      <head>
         <title>XHTML with embedded SVG</title>
      </head>
      <body>
         <p>Following this paragraph is an 
            SVG fragment that defines a circle.</p>
         <svg:svg width="400" height="400" version="1.1">
            <svg:circle cx="200" cy="200" r="100" />
         </svg:svg>
      </body>
   </html>
Цей документ не може бути перевірена на відповідність схемі XHTML XHTML, тому що не містить SVG: SVG елемент, і він не може бути перевірений на SVG SVG схеми, тому що не містить HTML-елементів. Однак, по окремості перевірки XHTML піддерева (мінус SVG піддерево) і SVG піддерева, можна визначити обгрунтованість всього документа. Для отримання додаткової інформації див питання 9.2.
  • Простори імен пошуки. У мовах, таких як XQuery, можна шукати в просторі імен елемента або атрибута. Одне з можливих застосувань цього шукає всі документи, які відхиляються від певного стандарту. Наприклад, припустимо, у вас є база даних DocBook документів і хочете знайти всі документи, які використовують елементи не визначені DocBook. Це можна зробити за допомогою наступного виразу XQuery:
 for $doc in collection("my_documents")
   where some $element in $doc//element() satisfies
         (fn:namespace-uri($element) ne "http://docbook.org/ns/docbook")
   return $doc
3,3) Що таке XML імен? Простір імен XML являє собою набір типів елементів і атрибутів. Сама колекція не має значення - по суті, розумний аргумент може бути зроблений, що простору імен XML насправді не існують як фізичні або концептуальні осіб (див. простір імен Міф № 1). Що важливо, це ім'я простору імен XML, який є URI посилання. Це дозволяє XML простору імен, щоб забезпечити двох частин система іменування для типів елементів і атрибутів. Перша частина назви є URI посилання використовуються для визначення простору імен XML - простору імен. Друга частина являє собою тип елемента або атрибута сама назва - локальна частина, також відомий як локальне ім'я. Разом вони утворюють розширене ім'я. Це дві частини система іменування є єдиним визначається XML рекомендація просторів імен. 3,4) чи XML рекомендація просторів імен визначають нічого, крім двох частинах система іменування для типів елементів і атрибутів? Ні. Це дуже важливий момент, і джерело багато плутанини, тому ми будемо повторювати: Рекомендації XML Namespaces не визначає нічого, крім двох частин системи іменування для типів елементів і атрибутів. Зокрема, вони не надають або визначити одну з таких дій:
  • Спосіб об'єднати два документи, які використовують різні DTD. (Див. питання 10.5.)
  • Спосіб зв'язування імен XML і схеми інформації. (Див. питання 14,6 і простір імен Міф № 8).
  • Спосіб перевірки документів, які використовують XML простору імен. (Див. питання 7.6.)
  • Спосіб зв'язати тип елемента або атрибута заяви в DTD з XML простору імен. (Див. питання 7.2).
3,5) Що XML простору імен насправді містять? XML простору імен колекцій імена, не більше того. Тобто, вони містять імена типів елементів і атрибутів, а не елементи чи атрибути себе. Наприклад, розглянемо наступний документ.
<foo:A xmlns:foo="http://www.foo.org/">
     <B foo:C="foo" D="bar"/>
  </foo:A>
Назва елемента типу А і С ім'ям атрибута в http://www.foo.org/ простір імен, оскільки вони відображаються там префікс Foo. Назва елемента типу B і D ім'я атрибуту немає в XML простору імен, тому що без префікса відображає їх там. З іншого боку, елементи А і В і атрибути С і D не є в будь-якому просторі імен XML, навіть якщо вони фізично в рамках http://www.foo.org/ імен. Це тому, що XML простору імен містять імена, а не елементи чи атрибути. XML простору імен також не містять визначення типів елементів і атрибутів. Це важлива відмінність, так як багато людей схильні думати про XML простору імен, як схему, яка це не так. (Для отримання додаткової інформації див Простір імен Міф № 8). (Для отримання інформації про структуру простору імен XML, см. Простір імен Міф № 6). 3,6) імена всіх типів елементів і атрибутів в XML деяких імен? Ні. Якщо тип елемента або атрибута, ім'я якого не спеціально оголошений в просторі імен XML - тобто, він без префіксів і (у випадку з іменами типу елемента) не існує за замовчуванням простір імен XML - те, що ім'я не в будь-якому XML простору імен. Якщо ви хочете, ви можете думати про нього як мають нульовий посиланням URI, як його ім'я, хоча і не "нульовий" XML простору імен справді існує. Наприклад, в наступному, ім'я елемента типу В і імена атрибутів C і E немає в XML простору імен:
 <foo:A xmlns:foo="http://www.foo.org/">
     <B C="bar"/>
     <foo:D E="bar"/>
  </foo:A>
Для отримання додаткової інформації про атрибут без префікса імен і просторів імен XML, см. Простір імен Міф № 4. 3,7) чи XML простору імен відноситься до імена об'єктів, позначення імен, або цільові інструкції по обробці? Ні. Простору імен XML застосовується тільки до типу імен елементів і атрибутів. Крім того, в XML-документ, відповідний XML рекомендації простору імен, імена об'єктів, позначення назви і мети інструкції обробки не повинні містити двокрапки. 3,8) Хто може створювати XML імен? Будь-хто може створити XML простору імен - все, що вам потрібно зробити, це призначити URI посилання, як його ім'я і вирішити, який тип імена елементів і атрибутів в ньому. URI це називається повинна бути під вашим контролем і не повинно бути використовується для ідентифікації іншого простору імен XML, таким як колега. (На практиці, більшість людей, які створюють простір імен XML також описати типи елементів і атрибутів, імена яких у ньому -. Їх зміст моделей та типів, їх семантика і т. д. Однак, це не є частиною процесу створення XML імен, і не включають імен XML або надати спосіб відкрити для себе таку інформацію). 3,9) Чи потрібно використовувати XML простору імен? Може бути, може бути, немає. Якщо у вас немає ніяких конфліктів імен в XML-документи, які ви використовуєте сьогодні, як це часто буває з документами, використовувані усередині однієї організації, то ви, мабуть, не потрібно використовувати XML простору імен. Тим не менш, якщо у вас є сьогоднішні конфлікти, або якщо ви очікуєте конфліктів у майбутньому через поширення документів за межі організації або залучення зовнішніх документів у вашій організації, то ви повинні, ймовірно, використовувати XML простору імен. Незалежно від того, чи використовуєте ви просторів імен XML у ваших власних документів, цілком імовірно, що ви будете використовувати їх у поєднанні з деякими іншими технології XML, такі як XSL, XHTML або XML-схем. Наприклад, наступний XSLT (XSL Transformations) перетворення використовує XML простору імен розрізняти типи елементів, визначених у XSLT і ті, що визначені в іншому місці:
 <xsl:stylesheet version="1.0"
                 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
     <xsl:template match="Address">
     <!-- The Addresses element type is not part of the XSLT namespace. -->
     <Addresses>
        <xsl:apply-templates/>
     </Addresses>
     </xsl:template>
  </xsl:stylesheet>
3,10) Яка взаємозв'язок між просторами імен XML і рекомендації XML 1.0? Незважаючи на рекомендації XML 1.0 очікується необхідності простору імен XML, зазначивши, що тип імена елементів і атрибутів не повинно містити двокрапки, це насправді не підтримує простору імен XML. Таким чином, XML простору імен на верхньому рівні XML 1.0. Зокрема, будь XML-документ, який використовує XML простору імен є юридичним документом XML 1.0 і може бути інтерпретоване як такої в відсутність простору імен XML. Наприклад, розглянемо наступний документ:
 <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B foo:C="bar"/>
  </foo:A>
Якщо цей документ обробляється простору імен не знають процесора, що процесор буде бачити двох елементів, імена яких Foo: і Foo: B. Foo: елемент має атрибут з ім'ям XMLNS: Foo і Foo: B елемент має атрибут з ім'ям Foo: C. З іншого боку, простору імен процесорів побачите двох елементів з розширеними іменами {http://www.foo.org} і {} http://www.foo.org B. {} Http :/ / www.foo.org не має ніяких атрибутів, замість цього, він має декларацію простору імен, яке відображає префікс Foo в http://www.foo.org посиланням URI. {} B http://www.foo.org елемент має атрибут з ім'ям {} http://www.foo.org C. Зайве говорити, що це призвело до певної плутанини. Одним з напрямків плутанина відносин між просторами імен XML і перевірки XML документів проти DTD. Це відбувається тому, XML рекомендації імен не описують, як використовувати XML простору імен з DTD. (Для отримання додаткової інформації див розділ 7.) На щастя, подібна ситуація не повинна виникати при мов XML-схем, так як всі ці підтримкою XML простору імен. Інші основні області плутанини в рекомендації та характеристики, такі як DOM і SAX, перша версія передує XML рекомендація просторів імен. Хоча ці з тих пір був оновлений, щоб включити підтримку простору імен XML, рішення не завжди були досить через вимоги зворотної сумісності. Всі рекомендації в родині XML тепер підтримує простору імен XML. 3,11) Які відмінності між версіями 1.0 і 1.1 XML рекомендації імен? Є тільки два істотних відмінностей між просторами імен XML 1.0 і XML простору імен 1.1:
  • Версія 1.1 додає шлях до undeclare префіксів. Для отримання додаткової інформації див питання 4.7.
  • Версія 1.1 використовує IRI (Міжнародні ідентифікатори ресурсів) посилання замість URI посилання. В принципі, URI, обмежені підмножиною символів ASCII, а IRIs дозволяють значно ширшому використанню Unicode символи. Для отримання повної інформації див Міжнародні ідентифікатори ресурсів.
ПРИМІТКА: На момент написання статті (січень, 2007), простору імен в XML 1.1, здається, не буде широко реалізовано. Перед початком використання перевірити програмне забезпечення ви використовуєте, щоб побачити, якщо вона не підтримується. І якщо ви обміну документами з іншими, переконайтеся, що їх програмне забезпечення підтримує його. ЧАСТИНА II: Оголошення та використання просторів імен XML 4) Розділ 4: Оголошення простору імен XML в документ XML 4,1) Як оголосити простір імен XML у документі XML? Щоб оголосити простір імен XML, можна використовувати атрибут, ім'я якого має вигляд:
xmlns:<i>prefix</i>
        --OR--
  xmlns
Ці ознаки часто називають XMLNS атрибути та їх значення ім'я простору імен XML був оголошений, це URI посилання. Перша форма атрибуту (XMLNS: префікс) оголошує префікс, який буде пов'язаний з XML простору імен. Друга форма (XMLNS) заявляє, що зазначене простір імен за замовчуванням простір імен XML. Наприклад, наступний оголошує два простори імен XML, названий http://www.tu-darmstadt.de/ito/addresses і http://www.tu-darmstadt.de/ito/servers. Перший партнерів декларації префікс адресу з http://www.tu-darmstadt.de/ito/addresses імен, а другий стану заяву, що імен http://www.tu-darmstadt.de/ito/servers є за умовчанням простір імен XML.
<Department
       xmlns:addr="http://www.tu-darmstadt.de/ito/addresses"
       xmlns="http://www.tu-darmstadt.de/ito/servers">
ПРИМІТКА: Технічно, XMLNS атрибути не є атрибутами на всіх - вони XML оголошення простору імен, що просто так, щоб виглядати як атрибути. На жаль, вони не розглядаються послідовно різні рекомендації XML, який означає, що ви повинні бути обережні при написанні XML додатка. Наприклад, у XML набір інформації (http://www.w3.org/TR/xml-infoset), Xmlns "атрибути" не з'являються як атрибутів. Замість цього, вони відображаються у вигляді імен елементів інформації декларацію. З іншого боку, DOM Level 2, DOM Level 3, і SAX 2.0 задоволенням атрибутах, дещо двозначно. У SAX 2.0, додаток може доручити парсер, щоб повернутися XMLNS "атрибути" разом з іншими атрибутами, або опустити їх зі списку атрибутів. Крім того, в той час як DOM Level 2 встановлює імен інформація, заснована на XMLNS "атрибути", це також змушує додатків вручну додавати оголошення простору імен, використовуючи той самий механізм додаток буде використовувати для установки будь-яких інших атрибутів. (Ця проблема вирішується в DOM Level 3 із Document.normalizeDocument метод, який додає XMLNS атрибути.) 4,2) Де я можу оголосити XML імен? Ви можете оголосити XML імен на будь-який елемент у документі XML. Простір імен в області видимості для цього елемента і всіх його нащадків, якщо він не перевизначений (див. питання 4.5 і питання 4,6) або неоголошеної (див. питання 4.7 і питання 4,8). Для отримання додаткової інформації про масштабів, див. розділ 6. 4,3) Чи можу я використовувати за замовчуванням для атрибутів в ЗТД оголосити XML імен? Так. Наприклад, наступний використовує атрибут FIXED XMLNS: Foo на тип елемента, щоб зв'язати префікс Foo з http://www.foo.org/ імен. Результатом цього є те, що А і Б знаходяться в http://www.foo.org/ імен.
<?xml version="1.0" ?>
  <!DOCTYPE foo:A [
     <!ELEMENT foo:A (foo:B)>
     <!ATTLIST foo:A
               xmlns:foo CDATA #FIXED "http://www.foo.org/">
     <!ELEMENT foo:B (#PCDATA)>
  ]>
  <!-- foo prefix declared through default attribute. -->
  <foo:A>
     <foo:B>abc</foo:B>
  </foo:A>
ВАЖЛИВО: Ви повинні бути дуже обережні в розміщенні оголошення простору імен XML тільки в зовнішніх осіб (зовнішні DTD) або в параметрі осіб, у тому числі об'єкти параметрів у внутрішньому підмножині (внутрішні DTD). Причиною цього є те, що без перевірки аналізаторів не потрібно читати зовнішні об'єкти або об'єкти параметрів. Наприклад, припустимо, що попередній DTD була поміщена під зовнішнє обличчя (foo.dtd) і, що документ був оброблений без перевірки аналізатор, який не читав foo.dtd. Це призведе до помилки, оскільки імен префікс Foo ніколи не був заявив:
 <?xml version="1.0" ?>
  <!-- foo.dtd might not be read by non-validating parsers. -->
  <!DOCTYPE foo:A SYSTEM "foo.dtd">
  <!-- foo prefix not declared unless foo.dtd is read. -->
  <foo:A>
     <foo:B>abc</foo:B>
  </foo:A>
віслюку більшості реальних DTD, є зовнішніми, ви можете уникнути цієї проблеми шляхом розміщення вашого оголошення простору імен в обох DTD і сам документ. Наприклад: DTD:
----
   <!ELEMENT foo:A (foo:B)>
   <!-- Declare the namespace in the DTD. -->
   <!ATTLIST foo:A
             xmlns:foo CDATA #FIXED "http://www.foo.org/">
   <!ELEMENT foo:B (#PCDATA)>

XML document:
-------------
   <!DOCTYPE foo:A SYSTEM "foo.dtd">
   <!-- Declare the namespace in the document. -->
   <foo:A xmlns:foo="http://www.foo.org/">
      <foo:B>abc</foo:B>
   </foo:A>
Цей документ є дійсним імен завжди, незалежно від того DTD читати, бо декларація простору імен в самому документі. Крім того, документ дійсний по відношенню до DTD, тому що XMLNS: Foo атрибут оголошений в DTD. Ситуація для XML-схем аналогічно. Для отримання додаткової інформації про XML простору імен і DTD, див. розділ 7. Для отримання додаткової інформації про XML простору імен і XML-схем, див. розділ 8. 4,4) Чи значення за замовчуванням XMLNS атрибутів, оголошених в DTD застосовуються до DTD? Ні. Оголошення значення за замовчуванням XMLNS атрибут в DTD не оголошувати простір імен для XML DTD. (Насправді, ніяких декларацій простору імен XML застосовується до DTD.) Замість цього, ці значення за замовчуванням (декларацій) набудуть чинності тільки тоді, коли атрибут екземпляра на елемент. Наприклад:
 <?xml version="1.0" ?>
  <!DOCTYPE foo:A [
     <!ELEMENT foo:A (foo:B)>
     <!ATTLIST foo:A
               xmlns:foo CDATA #FIXED "http://www.foo.org/">
     <!ELEMENT foo:B (#PCDATA)>
  ]>
  <foo:A>  <========== Namespace declaration takes effect here.
     <foo:B>abc</foo:B>
  </foo:A>  <========= Namespace declaration ends here.
Для отримання додаткової інформації див питання 7.2. (Відзначимо, що більш рання версія MSXML (парсера використовується Internet Explorer) не використовувати фіксовані XMLNS оголошення атрибутів, як декларації XML імен, але що це була видалена в MSXML 4. Для отримання додаткової інформації див питання 10.6.) 4,5) Як я можу змінити XML оголошення простору імен, який використовує префікс? Щоб змінити префікс, використовуваний в оголошенні простору імен XML, ви просто оголосити ще один XML імен з тим самим префіксом. Наприклад, в наступному, префікс Foo пов'язано з http://www.foo.org/ імен на А і B елементи і http://www.bar.org/ імен на C і D елементів . Тобто, імена і B знаходяться в http://www.foo.org/ імен і назв C і D знаходяться в http://www.bar.org/ імен.
<foo:A xmlns:foo="http://www.foo.org/">
     <foo:B>
        <foo:C xmlns:foo="http://www.bar.org/">
           <foo:D>abcd</foo:D>
        </foo:C>
     </foo:B>
  </foo:A>
Загалом, це призводить до документів, які збивають з пантелику читати і слід уникати. 4,6) Як я можу змінити простір імен за замовчуванням XML декларації? Щоб змінити поточний замовчуванням простір імен XML, ви просто оголосити ще один XML простору імен за замовчуванням. Наприклад, в наступному, за замовчуванням простір імен XML є http://www.foo.org/ імен на А і B елементи і http://www.bar.org/ імен на C і D елементів. Тобто, імена і B знаходяться в http://www.foo.org/ імен і назв C і D знаходяться в http://www.bar.org/ імен.
<A xmlns="http://www.foo.org/">
     <B>
        <C xmlns="http://www.bar.org/">
           <D>abcd</D>
        </C>
     </B>
  </A>
Використання декількох замовчуванням простір імен XML може привести до документів, які збивають з пантелику читати і повинно бути зроблено акуратно. Для отримання додаткової інформації див питання 5.4. 4,7) Як я undeclare XML префікс простору імен? У версії 1.0 XML рекомендація просторів імен, ви не можете "undeclare" префікс простору імен XML. Він залишається в області до кінця елемента, на який він був оголошений, якщо він не скасований. Крім того, намагаючись undeclare префікса шляхом оголошення його порожній (нульової довжини) URI посиланням результатів в просторі імен помилки. Наприклад:
  <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B>
        <foo:C xmlns:foo="">   <==== This is an error in v1.0, legal in v1.1.
           <foo:D>abcd</foo:D>
        </foo:C>
     </foo:B>
  </foo:A>
У версії 1.1 XML рекомендація просторів імен, ви можете undeclare XML префікс простору імен шляхом оголошення його з порожнім ім'ям. Наприклад, у згаданому вище документі, XML XMLNS оголошення простору імен: Foo = "" є законним і видаляє відображення префікса до Foo http://www.foo.org. Через це, використання префікса Foo Foo в: C і Foo: D елементів призводить до простору імен помилки. 4,8) Як я undeclare за замовчуванням простір імен XML? Для "undeclare" за умовчанням простір імен XML, ви розкажете за замовчуванням простір імен XML з порожньою (нульової довжини) URI посилання. В рамках цієї декларації, без префікса імені елемента типу не належать до жодного XML простору імен. Наприклад, в наступному, за замовчуванням простір імен XML є http://www.foo.org/ для А і В елементів і за замовчуванням не існує XML-простору імен для C і D елементів. Тобто, імена і B знаходяться в http://www.foo.org/ імен і назв C і D немає в XML простору імен.
 <A xmlns="http://www.foo.org/">
     <B>
        <C xmlns="">
           <D>abcd</D>
        </C>
     </B>
  </A>
4,9) Чому спеціальні атрибути використовуються для оголошення простору імен XML? Я не знаю відповіді на це питання, але вірогідною причиною є те, що надія, що вони дозволять спростити процес переміщення фрагментів з одного документа в інший документ. Один з перших проектів XML рекомендації імен запропонував використовувати інструкції обробки XML оголосити простір імен. У той час це були прості для читання і обробки, вони не були легкими, щоб перейти до інших документів. Атрибути, з іншого боку, тісно асоціюються з елементами переміщається. На жаль, це не спрацювало, а також було висловлено сподівання. Наприклад, розглянемо наступний документ XML:
<foo:A xmlns:foo="http://www.foo.org/">
     <foo:B>
        <foo:C>bar</foo:C>
     </foo:B>
  </foo:A>
Просто за допомогою текстового редактора, щоб скоротити фрагмент на чолі з <B> елемента з одного документа і вставити його в інший документ призводить до втрати інформації про просторі імен, тому що оголошення простору імен не є частиною фрагмент - це на батьківський елемент (<A>) - і не переміщається. Навіть тоді, коли це буде зроблено програмно, ситуація не обов'язково краще. Наприклад, припустимо, що додаток використовує DOM Level 2 "вирізати" фрагмент з вищевказаного документа і "вставити" його в інший документ. Хоча імен інформація передається (вона здійснюється кожен вузол), оголошення простору імен (XMLNS атрибут) не є, знову ж таки, тому що вона не є частиною фрагмента. Таким чином, застосування необхідно вручну додати декларацію до сериализации документ або в новий документ буде недійсним. (Ця проблема частково вирішена в DOM Level 3 із Document.normalizeDocument метод, який додає відповідні атрибути XMLNS. Тим не менш, існування метод для очищення таких проблем, вказує, що цей механізм є не зовсім вдалим.) Цікаво відзначити, що це насправді нічим не відрізняється від ситуації в строго типізованих мов програмування. Наприклад, в наступному фрагменті коду, змінна загального оголошена як ціле число в першій заяві та змінної я оголошений як ціле число протягом пункту: int total = 0; for (int i = 0; i < 10; i++) { total = total + i; } Тепер, якщо ми скоротимо заяву total = total + i; і вставте його в іншу частину коду, це призведе до помилки часу компіляції. Це тому, що ми ще не оголошені змінні загального, і я в новій частині коду. Для людей, які звикли працювати з строго типізованих мовах, це не є сюрпризом, і він приймається без питань. Незважаючи на це, наші очікування щодо XML бувають різні: Ми очікуємо, щоб мати можливість вирізати і вставляти фрагменти XML, не турбуючись про заяви, які впливають на імена в цих фрагментах будуть вирішені. Це, ймовірно, походить від двох джерел. По-перше, це було можливо раніше XML простору імен були введені. По-друге, з точки зору написання додатків, XML ближче до даних, чим це в коді, і ми не звикли до таких проблем при переміщенні даних навколо. (Найближча річ, яку я можу думати про те, щоб кинути мають дані з одного типу в інший, але це набагато простіше, ніж турбуватися про XML оголошення простору імен). 4,10) Як різні технології XML лікування XML оголошення простору імен? Це залежить від технологій - деякі розглядають їх як атрибути, а деякі ставляться до них як оголошення просторів імен. Наприклад, SAX1 розглядає їх як атрибути і SAX2 може розглядати їх як атрибути або декларацій простору імен, в залежності від того, як аналізатор налаштований. (Для отримання додаткової інформації див питання 11,3 і SAX2 документації.) DOM рівня 1, 2 і 3 ставляться до них як атрибути, але DOM рівня 2 і 3 також інтерпретувати їх як оголошення просторів імен. (Для отримання додаткової інформації див питання 11,5 і 11,6 запитання.) XPath, XSLT, XML-схем і ставитися до них як простір імен декларацій. Причина, по якій різні технології лікування цих по-різному, що багато з цих технологій передували XML простору імен. Таким чином, нові версії їх потрібно турбуватися і про XML простору імен і проблем з зворотною сумісністю. 5) РОЗДІЛ 5: Використання просторів імен XML в документ XML 5,1) Як я можу використовувати префікси для позначення типу імен елементів і атрибутів в просторі імен XML? Переконайтеся, що ви заявили префікс (див. питання 4.1) і що він все ще знаходиться в області видимості (див. розділ 6). Все що вам потрібно зробити, це префікс місцева назва типу елемента або атрибута з префіксом і товстої кишки. У результаті виходить повне ім'я (див. питання 12,1), який додаток аналізує щоб визначити, які простору імен XML місцева назва належить. Наприклад, припустимо, що ви пов'язані Serv префікс простору імен http://www.tu-darmstadt.de/ito/servers і що ця заява все ще перебуває в області. У наступному, Serv: Адреса посилається на адресу ім'я в просторі імен http://www.tu-darmstadt.de/ito/servers. (Зверніть увагу, що префікс використовується як на початковий і кінцевий теги.) <!-- serv refers to the http://www.tu-darmstadt.de/ito/servers namespace. --> <serv:Address>123.45.67.8</serv:Address> Тепер припустимо, що ви пов'язані з префіксом XSLT імен http://www.w3.org/1999/XSL/Transform. У наступному, XSLT: версія відноситься до версії ім'я в просторі імен http://www.w3.org/1999/XSL/Transform: <!-- xslt refers to the http://www.w3.org/1999/XSL/Transform namespace. --> <html xslt:version="1.0"> 5,2) Як я можу використовувати за умовчанням простір імен XML для позначення типу елемента імен в XML імен? Переконайтеся, що ви оголосили за замовчуванням простір імен XML (див. питання 4.1) і що ця заява все ще знаходиться в області видимості (див. розділ 6). Все що вам потрібно зробити, це використовувати місцеві назви типу елемента. Навіть якщо це не префікс, то результат буде ще повне ім'я (див. питання 12,1), який додаток аналізує щоб визначити, які простору імен XML він належить. Наприклад, припустимо, що ви оголосили http://www.tu-darmstadt.de/ito/addresses простір імен, що за замовчуванням простір імен XML і що ця заява все ще перебуває в області. У наступному, адреса посилається на адресу ім'я в просторі імен http://www.tu-darmstadt.de/ito/addresses.
<!-- http://www.tu-darmstadt.de/ito/addresses is the default XML namespace. -->
  <Address>123.45.67.8</Address>
Для отримання інформації про те, як використовувати за умовчанням простір імен XML з іменами атрибутів, див. питання 5.3. 5,3) Як я можу використовувати за умовчанням простір імен XML для позначення імен атрибутів простору імен XML? Ви не можете. За замовчуванням простір імен XML застосовується тільки для типів елементів, так що ви можете посилатися на імена атрибутів, які знаходяться в просторі імен XML тільки з префіксом. Наприклад, припустимо, що ви оголосили http://www.tu-darmstadt.de/ito/addresses простір імен, що за замовчуванням простір імен XML. У наступному, назва типу атрибута не відноситься до простору імен, що, хоча тип адреси ім'я елемента робить. Тобто, типу адреси імені елемента в просторі імен http://www.tu-darmstadt.de/ito/addresses, але ім'я атрибута типу немає ні в одному XML простору імен.
<!-- http://www.tu-darmstadt.de/ito/addresses is the default XML namespace. -->
  <Address type="home">
Щоб зрозуміти, чому це так, пам'ятайте, що мета простору імен XML, щоб однозначно ідентифікувати імена елементів і атрибутів. Префіксів імен атрибутів можуть бути однозначно визначені на основі типу елемента, до якого вони належать, тому немає необхідності ідентифікувати їх подальшого включення їх в простір імен XML. Насправді, єдина причина, за те, що імена атрибутів повинні бути префіксом так, що атрибути, визначені на одній мові XML може бути використаний в інший XML-мову. Для отримання інформації про те, як використовувати за умовчанням простір імен XML з іменами типу елемента, див. питання 5.2. Для отримання додаткової інформації про атрибут без префікса імен і просторів імен XML, см. Простір імен Міф № 4. 5,4) Коли я повинен використовувати за умовчанням простір імен XML замість префіксів? Це просто питання вибору, хоча ваш вибір може вплинути на читаність документа. Коли елементи, імена яких належать до одного простору імен XML згруповані разом, використовуючи за замовчуванням простір імен XML може зробити документ більш читабельним. Наприклад:
<!-- A, B, C, and G are in the http://www.foo.org/ namespace. -->
  <A xmlns="http://www.foo.org/">
     <B>abcd</B>
     <C>efgh</C>
     <!-- D, E, and F are in the http://www.bar.org/ namespace. -->
     <D xmlns="http://www.bar.org/">
        <E>1234</E>
        <F>5678</F>
     </D>
     <!-- Remember! G is in the http://www.foo.org/ namespace. -->
     <G>ijkl</G>
  </A>
Коли елементи, імена яких знаходяться в різних просторах імен XML перемежовуються, за замовчуванням простір імен XML, безумовно, зробити документ більш важким для читання і префікси повинні використовуватись замість цього. Наприклад:
 <A xmlns="http://www.foo.org/">
     <B xmlns="http://www.bar.org/">abcd</B>
     <C xmlns="http://www.foo.org/">efgh</C>
     <D xmlns="http://www.bar.org/">
        <E xmlns="http://www.foo.org/">1234</E>
        <F xmlns="http://www.bar.org/">5678</F>
     </D>
     <G xmlns="http://www.foo.org/">ijkl</G>
  </A>
У деяких випадках, за замовчуванням простір імен може бути оброблений швидше, ніж префікси простору імен, але різниця буде, безсумнівно, нікчемний в порівнянні з загального часу обробки. 6) РОЗДІЛ 6: ОБСЯГ оголошення простору імен XML 6,1) Що є предметом оголошення простору імен XML? Обсяг оголошення простору імен XML є те, що частина XML-документа, до якого належить декларація. Декларація XML простір імен залишається в області для елемента, на якому вона оголошена, і всі його нащадки, якщо вони не перевизначені або неоголошена на одному з цих нащадків (див. питання 4.5, 4.6 і 4.8). Наприклад, в наступному, обсяг декларацію http://www.foo.org/ простору імен елемента і його нащадків (B і C). Обсяг декларації http://www.bar.org/ імен є тільки елементом C.
<foo:A xmlns:foo="http://www.foo.org/">
     <foo:B>
        <bar:C xmlns:bar="http://www.bar.org/" />
     </foo:B>
  </foo:A>
Зверніть увагу, що, перебуваючи в рамках оголошення простору імен XML відрізняється від буття в просторі імен XML собі. Перебуваючи в сферу заяву просто означає, що декларація доступно для вирішення префікси, це не означає, що дана заява фактично усуває певного префікса. Наприклад, два оголошення простору імен в області видимості елемента C (http://www.foo.org/ і http://www.bar.org/), але тільки декларації за http://www.bar . ORG / насправді вирішує бар префікс. 6,2) Чи сфери оголошення простору імен XML включає елемент він заявив? Так. Наприклад, в наступному, назви B і C знаходяться в http://www.bar.org/ імен, не http://www.foo.org/ імен. Це тому, що декларація, яка пов'язує префікс Foo з http://www.bar.org/ імен відбувається на елемент B, перевизначення декларацію про елементом, який пов'язує його з http://www.foo.org / імен.
 <foo:A xmlns:foo="http://www.foo.org/">
     <foo:B xmlns:foo="http://www.bar.org/">
        <foo:C>abcd</foo:C>
     </foo:B>
  </foo:A>
Крім того, в наступному, назви B і C знаходяться в http://www.bar.org/ імен, не http://www.foo.org/ імен, бо декларація оголошення http://www.bar . ORG / як простір імен XML за замовчуванням відбувається на елемент B, перевизначення декларацію про елементом.
<A xmlns="http://www.foo.org/"> <B xmlns="http://www.bar.org/"> <C>abcd</C> </B> </A> Останнім прикладом є те, що в наступному, D ім'я атрибута в http://www.bar.org/ імен. <foo:A xmlns:foo="http://www.foo.org/"> <foo:B foo:D="In http://www.bar.org/ namespace" xmlns:foo="http://www.bar.org/"> <C>abcd</C> </foo:B> </foo:A> Одним із наслідків XML оголошення простору імен, що відносяться до елементів вони відбуваються на те, що вони насправді застосовується перш ніж вони з'являться. Через це, програмне забезпечення, яке обробляє повні імена повинні бути особливо обережні, щоб сканувати атрибути елемента для простору імен XML заяв, перш ніж вирішити, що XML простір імен (якщо такі є) тип елемента або атрибута, ім'я належить. 6,3) Якщо елемент або атрибут у сфері оголошення простору імен XML, є його ім'я в цьому просторі імен? Не обов'язково. Коли елемент або атрибут у сфері оголошення простору імен XML, елемента або ім'я атрибута перевіряється, щоб побачити, якщо вона має префікс, відповідний префікс в заяві. Чи ім'я насправді в просторі імен XML залежить від того, матчі префікс. Наприклад, в наступному, тип елемента імена A, B, D, F та й імена атрибутів C і E в рамках декларації http://www.foo.org/ імен. У той час як імена A, B, C і знаходяться в http://www.foo.org/ імен, назв D, E, F і немає: D і Е використовувати інший префікс (бар) і F не має префікса взагалі.
<foo:A xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org/">
     <foo:B foo:C="foo" />
     <bar:D bar:E="bar" />
     <F>baz</F>
  </foo:A>
(Див. також питання 3.6.) 6,4) Що відбувається, коли XML оголошення простору імен виходить з області видимості? Коли XML оголошення простору імен виходить з області видимості, він просто більше не застосовується. Наприклад, в наступному, оголошення http://www.foo.org/ імен не поширюється на елемент C, тому що це знаходиться поза сферою його застосування. Тобто, це в кінці минулого елемента B, на якій http://www.foo.org/ імен була оголошена. <!-- B is in the http://www.foo.org/ namespace; C is not in any XML namespace. --> <A> <B xmlns="http://www.foo.org/">abcd</B> <C>efgh</C> </A> На додаток до декларації не застосування, будь-які заяви, які він подолав повернутися в область. Наприклад, в наступному, оголошення http://www.foo.org/ імен повертається в область після закінчення елемент B. Це тому, що вона була скасована з B елемента декларації http://www.bar.org/ імен. <!-- A and C are in the http://www.foo.org/ namespace. B is in the http://www.bar.org/ namespace. --> <A xmlns="http://www.foo.org/"> <B xmlns="http://www.bar.org/">abcd</B> <C>efgh</C> </A> 6,5) Що станеться, якщо не XML оголошення простору імен в області видимості? Якщо немає XML оголошення простору імен в області видимості, то будь префікс типу елемента або атрибута імена результаті в просторі імен помилок. Наприклад, в наступному, імена Foo: і Foo: В результаті в просторі імен помилок. <?xml version="1.0" ?> <foo:A foo:B="error" /> У відсутність декларації простору імен XML, без префікса типу імен елементів і атрибутів не належать до жодного XML простору імен. Наприклад, в наступному, імена і B немає в XML простору імен. Для отримання додаткової інформації див питання 3.6. <?xml version="1.0" ?> <A B="no error" /> 6,6) може декілька оголошень просторів імен XML в область дії, в той же час? Так, за умови, що вони не використовують ті ж префікси і не більше одного з них за замовчуванням простір імен XML. Наприклад, в наступному, http://www.foo.org/ і http://www.bar.org/ простору імен, як за охопленням, для всіх елементів: <A xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org/"> <foo:B>abcd</foo:B> <bar:C>efgh</bar:C> </A> Одним з наслідків цього є те, що ви можете помістити всі оголошення простору імен XML в кореневому елементі, і вони будуть знаходитися в області видимості для всіх елементів. Це найпростіший спосіб використання простору імен XML. 6,7) Як я можу оголосити простір імен XML, так що всі елементи і атрибути знаходяться в їх сферу? XML оголошення простору імен, які зроблені на кореневий елемент знаходяться в області видимості для всіх елементів і атрибутів в документі. Це означає, що простий спосіб оголосити простір імен XML, щоб оголосити їх тільки на кореневий елемент. Наприклад: <Department xmlns:addr="http://www.tu-darmstadt.de/ito/addresses" xmlns:serv="http://www.tu-darmstadt.de/ito/servers"> <Name>DVS1</Name> <addr:Address> <addr:Street>Wilhelminenstr. 7</addr:Street> <addr:City>Darmstadt</addr:City> <addr:State>Hessen</addr:State> <addr:Country>Germany</addr:Country> <addr:PostalCode>D-64285</addr:PostalCode> </addr:Address> <serv:Server> <serv:Name>OurWebServer</serv:Name> <serv:Address>123.45.67.8</serv:Address> </serv:Server> </Department> Ні. Простору імен XML може бути оголошена тільки на елементи і сфери їх застосування складається тільки з тих елементів, і їх нащадки. Таким чином, область не може включати в DTD. Для отримання додаткової інформації див питання 7.2. 7) Розділ 7: XML простору імен і DTD, 7,1) Чи можу я використовувати простору імен XML в DTD? Так, і ні. Зокрема, DTD може містити повні імена (див. питання 7.3), проте заяви XML простору імен, не застосовуються до DTD (див. питання 7.2). Це має ряд наслідків. Тому декларацій простору імен XML не поширюється на DTD:
  • Існує не так, щоб визначити, які простору імен XML префікс в точках DTD в. Що означає ...
  • Кваліфіковані імена в DTD не може бути зіставлений з розширеним імена. Що означає ...
  • Тип оголошення елементів і атрибутів в DTD виражається в термінах повні імена, імена не розкриваються. Що означає ...
  • Перевірка не може бути переглянута з точки зору розширеного імена, як можна було очікувати.
Ця ситуація викликана численними скаргами, але, як XML простору імен вже рекомендація, навряд чи зміниться. Довгостроковим рішенням цієї проблеми є XML мову схемою: всі пропоновані схеми XML мови забезпечують механізм, за допомогою якого місцеві назви в тип елемента або атрибута може бути пов'язано з XML простору імен. Це дає можливість по-новому дії з точки зору розширеного імена. 7,2) чи XML оголошення простору імен застосовуються до DTD? Ні. Зокрема, XMLNS атрибуту, оголошеного в DTD за замовчуванням не є XML декларації простору імен для DTD. Для отримання додаткової інформації див питання 4.4. (Відзначимо, що більш рання версія MSXML (парсера використовується Internet Explorer) не використовувати таких заяв, як декларації XML імен, але що це була видалена в MSXML 4. Для отримання додаткової інформації див питання 10.6.) 7,3) Чи можу я використовувати повні імена в DTD? Так. Наприклад, наступне є законним: <!ELEMENT foo:A (foo:B)> <!ATTLIST foo:A foo:C CDATA #IMPLIED> <!ELEMENT foo:B (#PCDATA)> Однак, оскільки декларацій простору імен XML не поширюється на DTD (див. питання 7.2), кваліфіковані імена в DTD не можуть бути перетворені в розширеному імена. В результаті, кваліфіковані імена в DTD не мають особливого сенсу. Наприклад, Foo: просто Foo: - це не в XML імен, до якого приставка Foo відображається. Причина повні імена дозволені в DTD так, що перевірка буде продовжувати працювати. Для отримання додаткової інформації див питання 7.6. 7,4) Чи може модель вмісту в оголошенні типу елемента містять типи елементів, імена яких приїжджають з інших просторів імен XML? Так, і ні. Відповідь на це питання була ствердною, в тому сенсі, що повне ім'я в модель вмісту може мати різні приставки, ніж повне ім'я типу елемента оголошуються. Наприклад, наступне є законним: <!ELEMENT foo:A (bar:B, baz:C)> Відповідь на це питання не в тому сенсі, що декларації простору імен XML не поширюється на DTD, так префікси, що використовуються в оголошенні типу елемента технічно безглуздо. Зокрема, вони не уточнюють, що назва певного типу елемента належить до певного простору імен. Тим не менш, можливість змішувати префікси таким чином, має вирішальне значення, коли: а) у вас є документ, чиї імена приходять з декількох просторів імен XML (див. питання 10,5), і б) ви хочете побудувати цей документ таким чином, що є як дійсний і відповідає рекомендації імен XML (див. питання 7.6). 7,5) Може списку атрибутів елемента типу містять атрибути, імена яких приїжджають з інших просторів імен XML? Та й немає, з причин, перерахованих у питанні 7.4. Наприклад, наступне є законним: <!ATTLIST foo:A bar:B CDATA #IMPLIED> 7,6) Як я можу побудувати XML-документ, який діє і відповідає рекомендації імен XML? Відповідаючи на це питання, важливо пам'ятати, що: Дія це поняття визначено в XML 1.0, XML простору імен на верхньому рівні XML 1.0 (див. простір імен Міф № 11), і Рекомендації XML Namespaces не перевизначені дії, наприклад, в умовах розширеного імена (див. простір імен Міф № 9). Таким чином, дії однакові для документа, який використовує XML простору імен і той, який не робить. Зокрема, щодо дії: XMLNS атрибути розглядаються як атрибути, а не XML декларації простору імен. Повні імена розглядаються як інші імена. Наприклад, в ім'я Foo: A, Foo не розглядається як префікс простору імен, товстої кишки не розглядається як відділення префікса з локального імені, і не розглядається в якості локального імені. Назва Foo: розглядається просто як ім'я Foo: A. Через це, XML документи, які ви могли б очікувати, щоб бути дійсними не є. Наприклад, наступний документ не є допустимим, оскільки ім'я типу елемента не оголошений в DTD, незважаючи на те, як Foo: і частка розширене ім'я {} http://www.foo.org/ : <?xml version="1.0" ?> <!DOCTYPE foo:A [ <!ELEMENT foo:A EMPTY> <!ATTLIST foo:A xmlns:foo CDATA #FIXED "http://www.foo.org/" xmlns CDATA #FIXED "http://www.foo.org/"> ]> <A /> Аналогічним чином, наступне є неприпустимим, оскільки атрибут XMLNS не оголошений в DTD: <?xml version="1.0" ?> <!DOCTYPE A [ <!ELEMENT A EMPTY> ]> <A xmlns="http://www.foo.org/> Крім того, документи, які ви могли б очікувати недійсними є дійсними. Наприклад, наступний документ дійсний, але містить два визначення типу елемента з розширеним ім'ям {} http://www.foo.org/: <?xml version="1.0" ?> <!DOCTYPE foo:A [ <!ELEMENT foo:A (bar:A)> <!ATTLIST foo:A xmlns:foo CDATA #FIXED "http://www.foo.org/"> <!ELEMENT bar:A (#PCDATA)> <!ATTLIST bar:A xmlns:bar CDATA #FIXED "http://www.foo.org/"> ]> <foo:A> <bar:A>abcd</bar:A> </foo:A> Нарешті, дії не має нічого спільного з правильним використанням XML простору імен. Наприклад, наступний документ дійсний, але не відповідають XML рекомендації імен, тому що префікс Foo ніколи не заявляв: <?xml version="1.0" ?> <!DOCTYPE foo:A [ <!ELEMENT foo:A EMPTY> ]> <foo:A /> Таким чином, при побудові XML-документ, який використовує XML простору імен, ви повинні зробити обидва з наступних, якщо ви хочете, щоб документ, який буде дійсним: Оголосити XMLNS атрибутів в DTD. Використовуйте ті ж імена в DTD і тіло документа. Наприклад: <?xml version="1.0" ?> <!DOCTYPE foo:A [ <!ELEMENT foo:A (foo:B) <!ATTLIST foo:A xmlns:foo CDATA #FIXED "http://www.foo.org/"> <!ELEMENT foo:B EMPTY> ]> <foo:A> <foo:B /> </foo:A> Хоча це мінімальний набір вимог для забезпечення достовірності, кращий набір керівних принципів таким чином:
  • Оголосіть весь XMLNS атрибутів в DTD.
  • Використовуйте ті ж імена в DTD і тіло документа.
  • Використовуйте один префікс простору імен в XML.
  • Не використовуйте той же префікс для більш ніж одного XML простору імен.
  • Використовуйте не більше одного простору імен за замовчуванням XML.
  • Оголосіть весь XML простору імен в XML документі.
  • Оголосіть весь XML простору імен на кореневий елемент документа.
Як уже зазначалося, пункти 1 і 2 необхідні для забезпечення дійсності. Пункти 3, 4 і 5 гарантією того, що є один-до-одного між префікси і простору імен XML. Це гарантує, що це не можливо побудувати документів, які використовують безліч префіксів за той же префікс або ж XML-простору імен для декількох просторів імен XML, обидва з яких збивають з пантелику читати і схильні до помилок. Вони також усувають порушення, такі як визначення типу елемента або атрибута із заданим розширене ім'я кілька разів, як це було раніше. На жаль, це також означає, що префікси виконують роль зазвичай грає простору імен - унікальної ідентифікації XML простору імен. Тому що це суперечить духу префіксів, які були розроблені для їх гнучкість, трохи краще, рішення показано в питанні 7.7. Пункт 5 гарантує, що документ завжди буде імен в силі. Це не завжди вірно, якщо простір імен XML може бути оголошена тільки з фіксованим атрибут в DTD, для отримання додаткової інформації, див питання 4.3. Пункт 6 спрощує DTD, дозволяючи XMLNS атрибути повинні бути оголошені тільки від типу кореневий елемент (и). В іншому випадку, вони повинні були б бути оголошені на всі типи елементів, так як декларації простору імен XML допускається на будь-який елемент у документі. 7,7) Як я можу дозволити префікси в моєму документі не збігатися з префіксами в моїй DTD? Одна з проблем, з рішенням, запропонованим в питанні 7,6, що це вимагає префікса в документі, співпадають в DTD. На щастя, є рішення цієї проблеми, хоча вона вимагає, щоб один префікс бути використані для конкретного простору імен в документі. (Це гарна практика, в будь-якому випадку, так що це не надто багато обмежень.) Рішення припускає, що ви використовуєте DTD, що є зовнішнім по відношенню документ, який є звичайною практикою. Щоб використовувати різні префікси у зовнішньому DTD і XML-документи, ви розкажете префікса з парою параметрів об'єктів в DTD. Ви можете перевизначити ці особи з заявами у внутрішні DTD в даний XML документ. Це працює, тому що внутрішні DTD для читання перед зовнішніми DTD і перше визначення конкретного об'єкта є той, який використовується. Наступні пункти описують, як використовувати один простір імен в DTD. Вам потрібно буде змінити їх декілька, щоб використовувати кілька просторів імен. Почнемо з того, оголосити три параметри особами в DTD:
 <!ENTITY % p "" >
   <!ENTITY % s "" >
   <!ENTITY % nsdecl "xmlns%s;" >
Особа р («р» є скороченням від "префікс") використовується замість фактичного префікс типу імен елементів і атрибутів. Підприємство S ("S" є скороченням від "суфікс") використовується замість фактичного префікс в декларації простору імен. Підприємство nsdecl ("nsdecl" є скороченням від "декларації простору імен") використовується замість назви XMLNS атрибут в декларації цього атрибута. Тепер використовуйте суті р для визначення параметра осіб для кожного з імен в просторі імен. Наприклад, припустимо, що тип елемента імена A, B, і С і D імені атрибута у вашому просторі імен.
 <!ENTITY % A "%p;A">
   <!ENTITY % B "%p;B">
   <!ENTITY % C "%p;C">
   <!ENTITY % D "%p;D">
Далі, оголосити типів елементів і атрибутів за допомогою "ім'я" особи, не справжні імена. Наприклад:
   <!ELEMENT %A; ((%B;)*, %C;)>
   <!ATTLIST %A;
             %nsdecl; CDATA "http://www.foo.org/">
   <!ELEMENT %B; EMPTY>
   <!ATTLIST %B;
             %D; NMTOKEN #REQUIRED
             E CDATA #REQUIRED>
   <!ELEMENT %C; (#PCDATA)>
Є кілька речей, щоб помітити тут.
  • Характеристики D знаходиться в просторі імен, тому він оголошений з "ім'я" особи. Характеристики E не в просторі імен, так що жоден суб'єкт не використовується.
  • Nsdecl особи використовується для оголошення XMLNS атрибут. (XMLNS атрибути повинні бути оголошені на кожен тип елемента, на яких вони можуть виникнути.) Зауважимо, що значення за замовчуванням даного атрибуту XMLNS.
  • Посилання на елемент типу В в моделі вмісту поміщають в круглих дужках. Причиною цього є те, що модифікатор - * в даному випадку - до нього застосовується. За допомогою дужок необхідно тому, що заміна значення параметра суб'єктів пробілами; безпосереднього застосування модифікатора посилання на сутність параметра може призвести до незаконних синтаксис в моделі вмісту.
Наприклад, припустимо, що значення організація «Foo:" вартість підприємства Б "Foo: B", а значення суб'єкта С "Foo: C". Заява: <!ELEMENT %A; (%B;*, %C;)> буде перетворено в: <!ELEMENT foo:A ( foo:B *, foo:C )> Це незаконно, тому що * модифікатор повинен безпосередньо слідувати посилання на Foo: B тип елемента. Розміщуючи посилання на B особою в дужках, декларація постановляє: <!ELEMENT foo:A (( foo:B )*, foo:C )> Це тому, що правова * модифікатора прямо випливає закриває дужка. Тепер давайте подивимося, як все це працює. Нехай наш XML документ не буде використовувати префікси, але замість цього хоче простір імен за замовчуванням, щоб бути http://www.foo.org/ імен. У цьому випадку, жоден суб'єкт декларацій необхідні в документі. Наприклад, наш документ може бути: <!DOCTYPE A SYSTEM "http://www.foo.org/foo.dtd"> <A> <B D="bar" E="baz buz" /> <B D="boo" E="biz bez" /> <C>bizbuz</C> </A> Цей документ є дійсним, так як оголошення для P, S, і nsdecl в DTD безліч р і із до "" і nsdecl на "XMLNS". Тобто, після заміни P, S, і nsdecl осіб параметра, DTD полягає в наступному. Зверніть увагу, що обидва документи DTD і використовувати назви типу елемента A, B, і С, а імена атрибутів D і E. <!ELEMENT A (( B )*, C )> <!ATTLIST A xmlns CDATA "http://www.foo.org/"> <!ELEMENT B EMPTY> <!ATTLIST B D NMTOKEN #REQUIRED E CDATA #REQUIRED> <!ELEMENT C (#PCDATA)> Але що, якщо документ хоче використовувати інший префікс, наприклад, Foo? У цьому випадку документ необхідно перевизначити декларацій р і з особами у свої внутрішні DTD. Тобто, він повинен оголосити ці особи так, що вони використовують Foo в якості префікса (двокрапка) і суфікс (двокрапка). Наприклад: <!DOCTYPE foo:A SYSTEM "http://www.foo.org/foo.dtd" [ <!ENTITY % p "foo:"> <!ENTITY % s ":foo"> ]> <foo:A> <foo:B foo:D="bar" E="baz buz" /> <foo:B foo:D="boo" E="biz bez" /> <foo:C>bizbuz</foo:C> </foo:A> У цьому випадку внутрішні DTD для читання перед зовнішніми DTD, так що значення р і з особами з документа використовується. Таким чином, після заміни P, S, і nsdecl осіб параметра, DTD полягає в наступному. Зверніть увагу, що обидва документи DTD і використовувати елемент типу імен Foo: A, Foo: B, і Foo: C і імена атрибутів Foo: D і E. <!ELEMENT foo:A (( foo:B )*, foo:C )> <!ATTLIST foo:A xmlns:foo CDATA "http://www.foo.org/"> <!ELEMENT foo:B EMPTY> <!ATTLIST foo:B foo:D NMTOKEN #REQUIRED E CDATA #REQUIRED> <!ELEMENT foo:C (#PCDATA)> 7,8) Як можна перевірити XML-документ, який використовує XML простору імен? Коли люди задають це питання, вони зазвичай припускають, що дії різні для документів, які використовують простору імен XML і документи, які цього не роблять. Насправді, це не так - це те ж саме для обох сторін. Таким чином, немає ніякої різниці між перевірці документів, яка використовує XML простору імен і перевірку який не робить. У будь-якому випадку, ви просто використовуєте перевіряючий парсер або інше програмне забезпечення, яке виконує перевірку. Для отримання інформації про те, як побудувати XML документ, який діє і відповідає рекомендації XML простору імен, див. питання 7.6 і 7.7. 7,9) Якби я почати використовувати XML простору імен, я повинен змінити свій існуючий DTD? Можливо. Якщо ви хочете, щоб ваш XML документи повинні бути дійсними і відповідають XML рекомендація просторів імен, ви повинні оголосити будь XMLNS атрибутів і використовувати ті ж імена в DTD, як і в тілі документа. (Для отримання додаткової інформації див питання 7.6 і 7.7). Якщо ваш DTD містить тип імена елементів і атрибутів з одного простору імен XML, найпростіше зробити, це використовувати XML простору імен, імен по замовчуванню XML. Щоб зробити це, оголосити атрибут XMLNS (без префікса) для кожного можливого типу кореневий елемент. Якщо ви можете гарантувати, що DTD завжди читається (див. питання 4.3), встановити значення за замовчуванням в кожному оголошенні атрибуту XMLNS до URI посиланням використовуватися в якості простору імен. В іншому випадку, оголосити простір імен XML, як за замовчуванням простір імен XML в кореневому елементі кожного примірника документа. Якщо ваш DTD містить тип імена елементів і атрибутів з декількох просторів імен XML, вам потрібно вибрати один префікс для кожного простору імен XML і використовувати їх послідовно в кваліфікованих імен як в DTD і тіло кожного документа. Крім того, необхідно оголосити XMLNS атрибутів в DTD і оголосити XML простору імен. Як і у випадку одного простору імен XML, найпростіший спосіб це зробити, це додати XMLNS атрибути для кожного можливого типу кореневий елемент і використовувати значення за замовчуванням, якщо це можливо. Зверніть увагу, що ви повинні тільки потрібно, щоб ці зміни відразу. 8) РОЗДІЛ 8: XML простору імен і XML-схем 8,1) Як я можу використовувати XML простору імен з XML-схем? XML-схема одного документа заявляє елементів і атрибутів для одного простору імен XML, відомої як цільове простір імен. Це робиться з TargetNamespace атрибут XS: елемент схеми. Наприклад, наступна схема оголошує елементи A, B, C і в http://www.foo.org/ імен: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.foo.org/"> <xs:element name="A"> <xs:complexType> <xs:sequence> <xs:element ref="B"/> <xs:element ref="C"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="B" type="xs:string"/> <xs:element name="C" type="xs:string"/> </xs:schema> Це не обмежує схем для одного XML простору імен. Для того щоб використовувати елементи і атрибути з іншого простору імен XML, вони повинні бути оголошені в інший документ XML Schema, потім імпортується та посилання в поточному документі XML Schema. Наприклад, наступні схеми оголошувати елементи А і В у http://www.foo.org/ імен та C в http://www.bar.org/ імен. Модель вмісту для елемента посилання елемента C. A_B.xsd: -------- <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bar="http://www.bar.org/" targetNamespace="http://www.foo.org/"> <!-- Import namespace http://www.bar.org/ --> <xs:import namespace="http://www.bar.org/" /> <xs:element name="A"> <xs:complexType> <xs:sequence> <xs:element ref="B"/> <!-- Reference C from http://www.bar.org/ --> <xs:element ref="bar:C"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="B" type="xs:string"/> </xs:schema> C.xsd: ------ <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.bar.org/"> <xs:element name="C" type="xs:string"/> </xs:schema> Зверніть увагу, що XS: імпорт посилання на елементи схеми, в якій C оголошений своїх імен XML, а не його місце. Це дозволяє процесору схеми вирішити для себе, де для отримання документа схеми. Необов'язковий атрибут schemaLocation може бути використаний, щоб дати схему процесора підказку про те, де знайти схему документа. Тим не менш, схема процесор не зобов'язаний слідувати підказці. Наприклад, наступний XS: імпорт елементів натякає, що документ схеми можна знайти в C: \ схеми каталогу:
<import namespace="http://www.bar.org/"
           schemaLocation="file://localhost/C|/schemas/C.xsd" />
8,2) Які кваліфікованих і некваліфікованих місцевих імен в XML-схем? У XML-схеми, елементи і атрибути можуть бути оголошені глобально або локально. Глобальні елементи та атрибути цих елементів і атрибутів, визначених на зовнішньому рівні схеми - тобто, як діти XS: елемент схеми. Глобальні елементи можуть бути використані в якості кореневого елемента. Обидва глобальних елементів і глобальних атрибутів можна посилатися з заяв інших елементів в їх власної схеми або іншою схемою. Місцеві елементів і атрибутів є ті, оголошені усередині оголошення іншого елемента. Вони можуть бути використані тільки всередині елемента, в якому вони були оголошені і не можуть посилатися на заяви інших елементів. Наприклад, у такій схемі А і В були оголошені глобально і C оголошений локально. Зверніть увагу, що декларація B посилається всередині моделі вмісту, і C оголошена усередині вмісту моделі А.
  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="B"/>
               <xs:element name="C" type="xs:string"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="B" type="xs:string"/>
   </xs:schema>
(Навпаки, всі елементи типів, визначених у DTD носять глобальний характер. Їх можна використовувати як тип кореневої елемент і може бути використане в моделі вмісту інших елементів, у тому ж DTD. Всі атрибути, визначені в DTD носять локальний характер. Вони можуть бути використані тільки в тип елемента, з яким вони пов'язані.) Основна відмінність між локальними та глобальними елементів і атрибутів є те, що схема може мати кілька локальних елементів і атрибутів з тим же ім'ям, хоча він може мати тільки один глобальний елемент або атрибут з таким же ім'ям. Це корисно, коли ви хочете використовувати те ж ім'я в різних контекстах. Наприклад, припустимо, ви визначаєте схему замовлень, яка включає замовлення номера і номера позиції. За допомогою місцевих елементів, можна оголосити два елементи ім'ям Number - той, який є локальним по відношенню до елементу SalesOrder і той, який є локальним для елемента LineItem. Це корисно, коли кількість замовлень мають різний формат номера позиції. Наприклад, числа замовлень може бути алфавітно-цифровий, відповідний певним шаблоном, і номери позицій можуть бути позитивними числами. Це не було б можливо, якщо ви оголосили глобальний елемент номер. Тому що ви можете мати тільки один глобальний елемент номер, ви не могли б обмежити його, щоб бути буквено-цифрові в елемент SalesOrder і ціле позитивне число в елемент LineItem. Будь локальних елементів і атрибутів мають кваліфіковані імена залежить від elementFormDefault і attributeFormDefault атрибути XS: елемент схеми (або форма атрибуту XS: елемент і XS: атрибут елементів). За замовчуванням, значення цих атрибутів є «безумовної», що означає, що локальні елементи та атрибути не мають повних імен - тобто, вони не мають префікси. Наприклад, в наступному порядку, B і C є місцеві елементи, які не кваліфіковані і D є локальним атрибут, який не має права:
 <!-- elementFormDefault is "unqualified"
        attributeFormDefault is "unqualified" -->
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/"
           attributeFormDefault="unqualified"
           elementFormDefault="unqualified">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element name="B" type="xs:string"/>
               <xs:element name="C" type="xs:string"/>
            </xs:sequence>
         </xs:complexType>
         <xs:attribute name="D" type="xs:string"/>
      </xs:element>
   </xs:schema>
Нижче наведено приклад документа, який відповідає цій схемі. Відзначимо, що B, C, D і не префікс. <foo:A xmlns:foo="http://www.foo.org/" D="dddd"> <B>bbbb</B> <C>cccc</C> </foo:A> В наступному порядку, B і C є локальними елементами, що кваліфіковані і D є атрибутом, який кваліфікований:
 <!-- elementFormDefault is "qualified"
        attributeFormDefault is "qualified" -->
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/"
           attributeFormDefault="qualified"
           elementFormDefault="qualified">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element name="B" type="xs:string"/>
               <xs:element name="C" type="xs:string"/>
            </xs:sequence>
         </xs:complexType>
         <xs:attribute name="D" type="xs:string"/>
      </xs:element>
   </xs:schema>
Нижче наведено приклад документа, який відповідає цій схемі. Відзначимо, що B, C, D і починаються.
   <foo:A xmlns:foo="http://www.foo.org/" foo:D="dddd">
      <foo:B>bbbb</foo:B>
      <foo:C>cccc</foo:C>
   </foo:A>
Чи варто використовувати кваліфікований (префікс) або неповний (без префікса) місцеві назви елементів і атрибутів в основному стилістичні рішення. Тобто, це впливає тільки на те, що примірник документа виглядає, не так, як це підтверджено. Тим не менш, є певні переваги і недоліки кожного підходу. Див, наприклад, XML-схеми: мета elementFormDefault? Генрі Томпсон і простору імен, W3C XML Schema від Матвія Фукс. Як правило, люди ставлять elementFormDefault для «кваліфікованих» і attributeFormDefault до «безумовної». Це означає, що всі імена елементів використовувати префікси (або простору імен за замовчуванням), а не імена атрибутів використовувати префікси. Якщо ім'я кваліфікованим або некваліфікованим не впливає на елемент або атрибут локального або глобального, і не впливають на зіткнення між цими іменами. Тобто, ви можете мати кілька кваліфікованим або некваліфікованим елементи чи атрибути, які мають однакові назви, поки вони були оголошені локально в різних елементах, і ви можете мати тільки один глобальний елемент або атрибут з таким же ім'ям. 8,3) Чи повинен я використовувати XML простору імен з XML-схем? Ні. Якщо ви не хочете, щоб елементи та атрибути, які заявляють, що в будь-якому просторі імен XML, просто опустити TargetNamespace атрибут з XS: елемент схеми. Наприклад, наступний XML-схеми документа заявляє, елементи А, В, і С, жоден з яких знаходиться в просторі імен XML:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="B"/>
               <xs:element ref="C"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="B" type="xs:string"/>
      <xs:element name="C" type="xs:string"/>
   </xs:schema>
Для отримання інформації про те, що це гарна ідея, щоб оголосити елементи та атрибути, які не є в будь-якому просторі імен XML, див. питання 3.9. 8,4) Що таке схема хамелеон? Схема хамелеона XML Schema, який не має цільового простору імен. Це називається схемою хамелеон, тому що, коли він входить в іншу схему, він бере на цільовому просторі імен останній схеми. Це дозволяє схем буде побудований в модульних частин і повторно використані в інших схемах без плутанини з наявністю декількох просторів імен в цих схемах. У наступному прикладі, Chameleon.xsd включені в A.xsd через XS: включати елемент. В результаті елемент C знаходиться в http://www.foo.org/ імен. Зверніть увагу, що Chameleon.xsd не використовують TargetNamespace атрибутів, в той час C.xsd робить.
Chameleon.xsd
-------------

   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xs:element name="C" type="xs:string"/>
   </xs:schema>

A.xsd
-----
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/">
      <include schemaLocation="file://localhost/C|/schemas/Chameleon.xsd" />
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
               <xs:element ref="B"/>
               <xs:element ref="C"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="B" type="xs:string"/>
   </xs:schema>
Щоб побачити, як змінюється простір імен C, розглянемо наступні два документи. Перший документ відповідає Chameleon.xsd, в ньому елемент C немає ні в одному просторі імен. Другий документ відповідає A.xsd, в ньому елемент C знаходиться в http://www.foo.org імен.
Document conforming to Chameleon.xsd
------------------------------------

   <C>cccc</C>

Document conforming to A.xsd
----------------------------

   <foo:A xmlns:foo="http://www.foo.org/">
      <foo:B>bbbb</foo:B>
      <foo:C>cccc</foo:C>
   </foo:A>
Схема хамелеон тільки бере на цільовому просторі імен іншу схему, коли вона включена в цю схему, а не коли воно імпортується в цій схемі. У тому числі еквівалентно фізично вирізування і вставки, в результаті чого в декларації цільового простору імен, що відносяться до "вирізати-вставити-" (входять у комплект) схеми. Імпорт дозволяє повторне використання логічних визначень і оголошень від імпортованих схем, які залишаються фізично розділені. Для отримання додаткової інформації про те, коли і як використовувати хамелеон схемах див. в W3C XML шаблони проектування схеми: як уникнути складності по Dare Обасанджо і нуль, один або багато імен членів XML-DEV список розсилки. Для протилежної точки зору, див. W3C XML Schema: можна і не можна робити на Kohsuke Кавагуті. 8,5) чи всі визначені або оголошені в XML Schema в XML імен? Строго кажучи, немає. Це тому, що Простори імен у XML-рекомендації тільки говорить про використання XML простору імен з елементами і атрибутами. Однак, оскільки предмети, такі як складні типи, групи атрибутів, модель груп і ключові визначення, використовувати повні імена, простіше за все думати про цих імен як в XML простору імен. Це тому, що їхні імена будуть вирішені з використанням тих же механізмів, як імена елементів і атрибутів. 8,6) Є один-до-одного між просторами імен XML і XML-схеми? Ні. Як було показано в питанні 8.1, схема може використовувати елементи чи атрибути з декількох просторів імен XML. І хоча даний документ XML Schema може тільки оголосити елементів і атрибутів в єдиний простір імен XML, відносини між просторами імен XML і XML-документи схеми не один-на-один. Це тому, що кілька документів можуть всі оголошення елементів і атрибутів в тому ж XML-простору імен. Коли це буде зроблено, один XML Schema документ може включати в себе інший XML-документ схеми з тим же цільового простору імен з XS: включати елемент. Для отримання додаткової інформації див Простір імен Міф № 8. 8,7) Як перевірити документи, які використовують простору імен XML з XML-схем? Щоб перевірити документ на XML Schema, ви повинні використовувати парсер (або інший процесор), який підтримує XML-схем. Процесор перевіряє, що документ слід правилами в схемі. Перевірка на відповідність схемі називається перевірки схеми. Перевірка у відношенні DTD називається просто перевірка. (На практиці, перевірка схеми часто називають перевірки і люди розуміють чи документ в даний час перевіряються на DTD або XML Schema). Хоча є низка відмінностей між схеми перевірки та перевірки, основні відмінності між двома відносно простору імен XML є те, що перевірка схеми вирішує кваліфікованих імен у розширеному імен перед їх порівнянням, в той час як перевірка просто порівнює імен. В результаті документа, який перевіряється на XML-схеми можна використовувати будь префікс в кваліфікованих імен, в той час як документа, який перевіряється на DTD повинні використовувати префікс, який використовується в DTD. Наприклад, наступний документ схеми діють у відношенні наступних XML Schema, але недійсним за наступними DTD. Це тому, що префікс в документі вирішує цільового простору імен в XML Schema, але не відповідає префікс, використовуваний в DTD. Для отримання додаткової інформації про перевірку документів, які використовують простору імен XML з DTD, див. питання 7.6, питання 7.7, і питання 7.8.
XML document:
-------------
   <bar:A xmlns:bar="http://www.foo.org/">
      <bar:B>bbbb</bar:B>
      <bar:C>cccc</bar:C>
   </bar:A>

XML Schema:
-----------
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.foo.org/">
      <xs:element name="A">
         <xs:complexType>
            <xs:sequence>
            <xs:sequence>
               <xs:element ref="B"/>
               <xs:element ref="C"/>
            </xs:sequence>
         </xs:complexType>
      </xs:element>
      <xs:element name="B" type="xs:string"/>
      <xs:element name="C" type="xs:string"/>
   </xs:schema>

DTD:
----
   <!ELEMENT foo:A (foo:B, foo:C)>
   <!ELEMENT foo:B (#PCDATA)>
   <!ELEMENT foo:C (#PCDATA)>
РОЗДІЛ 9: XML простору імен і валідації 9,1) Як перевірити документи, які використовують простору імен XML? Строго кажучи, насправді є XML концепцією 1,0, що означає перевірити, що XML-документ відповідає правилам DTD. У більш загальному сенсі, означає перевірку, щоб перевірити, що документ XML відповідає правилам в будь XML-схеми, незалежно від схеми використовуваної мови. Оскільки DTD, не підтримують простору імен XML і інших основних мов XML-схеми (XML-схем, RELAX NG, Schematron) підтримують простору імен XML, перевірка тож діляться на дві категорії: перевірка щодо DTD і перевірки відносно всіх інших мов XML-схем. Коли документ XML перевіряється на DTD, який кваліфікований імен у документі не будуть вирішені в розширеному імен перед перевіркою. Замість цього, вони порівнюються за принципом символ-за-символ з ім'ям в DTD. Таким чином, префікси в документ XML повинен збігатися з префіксами в DTD та перевірки по DTD, а можливо, насправді не поводяться, як можна було б очікувати по відношенню до XML простору імен. Для отримання додаткової інформації див питання 7.6, питання 7.7, і питання 7.8. Коли документ XML перевіряється на XML-схем, RELAX NG, Schematron, або будь-який інший схемі XML мова, яка підтримує простору імен XML, кваліфіковані імена вирішуються у розширеному імена, як частина процесу перевірки. Через це, префікси в документі XML не потрібна відповідно до префіксами в XML-схем. Це те, що можна чекати. Для отримання додаткової інформації про перевірку документів щодо XML-схем, див. питання 8.7. 9,2) Що таке простір імен на основі перевірки диспетчерського мови (NVDL)? Простір імен на основі перевірки диспетчерського мови (NVDL) є ISO / IEC стандартом для перевірки документів проти декількох схем. Основна ідея полягає в тому, що документ розділений на піддерев, з елементами і атрибутами в кожному піддереві обмін одного XML простору імен. NVDL Потім скрипт відображає кожне простір імен XML у схемі використовуються для перевірки елементів і атрибутів в цьому просторі імен. Наприклад, наступний документ XHTML містить вбудований Scalable Vector Graphics (SVG) документа:
<html xmlns="http://www.w3.org/1999/xhtml"
         xmlns:svg="http://www.w3.org/2000/svg">
      <head>
         <title>XHTML with embedded SVG</title>
      </head>
      <body>
         <p>Following this paragraph is an 
            SVG fragment that defines a circle.</p>
         <svg:svg width="400" height="400" version="1.1">
            <svg:circle cx="200" cy="200" r="100" />
         </svg:svg>
      </body>
   </html>
Оскільки XHTML не включає в себе SVG: SVG елемента, ви не можете успішно перевірити цей документ на відповідність схемі XHTML. Однак, з NVDL, ви можете вказати, що XHTML елементи (http://www.w3.org/1999/xhtml імен) бути підтверджено зі схемою XHTML і SVG елементів (http://www.w3.org/2000 / SVG імен) бути підтверджено проти SVG схеми. NVDL процесор буде проходити окремо (відправлення) XHTML піддерева (опускаючи піддерево на чолі з SVG: SVG елемент) і SVG піддерево для перевірки рутини. Оскільки кожне піддерево діє сам по собі, документ в цілому справедливо. Найбільш важливою особливістю є те, що NVDL схеми не повинні включати конкретні місця, де елементи і атрибути з іншої схеми можуть бути вставлені. (Наприклад, XS: будь-який елемент схеми XML використовується, щоб зробити це). Замість цього, ви просто вставити елементів і атрибутів в документі XML, куди ви хочете і створити NVDL скрипт щоб визначити, як кожен піддерево буде перевірятися. Це залишає оригінальних схем незмінним - що особливо важливо для стандартних схем - і все ще дозволяє перевіряти документи. Інші особливості NVDL включають в себе: Підтримка будь-якій схемі мовою. Схема мов, визначених URI, так NVDL процесор просто потребує наборі мову схеми URI, і відповідний набір модулів, перевірка схем за допомогою цих мов. Здатність застосовувати кілька схем для одного піддереві. Можливість вказати, що елементи і атрибути в просторі імен XML бути підтверджено схеми, пов'язаної з одним XML простору імен. Це необхідно, коли використовується кілька схем XML простору імен. Підтримка атрибутів тільки схемами. Можливість почати перевірку на певний елемент, як зазначено підмножина XPath. Для отримання додаткової інформації про NVDL см. http://www.nvdl.org/. В якості простого прикладу використання УБЛ, див. Прості робочі демонстрації NVDL - ISO / IEC 19757-4 Г. Ken Holman. 10) статтю 10: Використання документи, які використовують простору імен XML 10,1) Як створити документи, які використовують простору імен XML? Так само, як Ви створюєте документи, які не використовуються простори імен XML. Якщо ви використовуєте Notepad в Windows або Linux на Emacs, ви можете продовжувати використовувати Блокнот або Emacs. Якщо ви використовуєте XML редактор, який не є простори імен, ви можете продовжувати використовувати, що, як повні імена є юридичними імен в XML-документи та XMLNS атрибутами є юридичними атрибутами. І якщо ви використовуєте XML редактор, простору імен, він, ймовірно, забезпечить такі функції, як автоматичне оголошення простору імен XML і відстеження префікси і простору імен XML за замовчуванням для вас. 10,2) Як я можу перевірити, що документ відповідає XML рекомендації імен? На жаль, я не знаю ні програмне забезпечення, яке тільки перевіряє на відповідність XML рекомендація просторів імен. Цілком можливо, що деякі простори імен перевірки аналізаторів (наприклад, від DataChannel (Microsoft), IBM, Oracle, або Сонце) перевірити відповідність імен XML в якості частини аналізу і перевірки. Таким чином, ви могли б запустити свій документ за допомогою таких парсерів як спосіб перевірки відповідності. Зверніть увагу, що пишу додаток, щоб перевірити відповідність XML рекомендації імен не так просто, як може здатися. Проблема в тому, що більшість парсерів не роблять DTD інформації в додаток, тому воно не може бути можливим, щоб перевірити відповідність в DTD. Також зверніть увагу, що написання додатків SAX 1.0, який перевіряє відповідність в тілі документа (на відміну від DTD) повинно бути легко зробити. 10,3) Чи можу я використовувати той же документ з обох простору імен і просторів імен не знають додатків? Так. Така ситуація досить часто, наприклад, коли простори імен додаток побудовано на вершині простору імен не знають аналізатор. Іншою поширеною є ситуація, коли ви створюєте XML-документ з простором імен XML редактор не знає, але обробити його за допомогою простору імен додатка. Використовуючи той же документ з обох простору імен і просторів імен не знають додатками можливо тому, що XML простору імен XML використовувати синтаксис. Тобто, документ XML, яка використовує XML простору імен і раніше XML-документа і визнається в якості такого простору імен не знають програмного забезпечення. Єдине, що ви повинні бути обережні при використанні того ж документа з обох простору імен та імен-додатків не знають, коли не знають імен-додатки вимагається документ в силі. У цьому випадку, ви повинні бути обережні, щоб побудувати свій документ таким чином, що є як дійсний і відповідає рекомендації XML простору імен. (Це можна побудувати документів, які відповідають XML рекомендації імен, але не є дійсними, і навпаки.) Для отримання інформації про те, як це зробити, див питання 7.6. 10,4) Яке програмне забезпечення, необхідне для обробки XML-простору імен? З точки зору автора документа, це, як правило, не відповідне питання. Більшість XML-документи написані в певному XML мову і обробляються додатком, який розуміє, що язик. Якщо мова використовує XML простору імен, то додаток буде вже використовувати цей простір імен - немає необхідності в яких-небудь спеціальних XML програмного забезпечення імен. Для отримання інформації про письменників додаток використовувати для обробки XML-простору імен, див. розділ 11. 10,5) Як я можу використовувати простору імен XML об'єднати документи, які використовують різні типи імен елементів і атрибутів? Перш ніж відповісти на це питання, ми повинні прояснити поширена помилка про XML простору імен. Це часто вважається, що простір імен XML забезпечити свого роду магія, яка дозволяє автоматично об'єднувати XML-документи, які використовують окремий набір типів елементів і атрибутів. Це не вірно. Хоча простору імен XML забезпечують деякі з інструментів, що вам потрібно зробити це, вам все одно доведеться робити велику частину роботи самостійно, як ви побачите в відповідь на це питання. Щоб об'єднати документи, які використовують окремий набір типів елементів і атрибутів, все, що вам потрібно зробити, це вирішити, де елементи та атрибути йти в підсумковому документі. Наприклад, не тип елемента із першого документа зайти всередину елемента типу B? Хіба це брат? Або вони зовсім не пов'язані? Хоча насправді процедура об'єднання двох документів можуть бути легко автоматизований, вирішуючи, як об'єднати їх навряд чи коли-небудь буде автоматизовано. Замість цього, він є суворо людські проблеми, які потребують когось, щоб зробити вибір. Наприклад, припустимо, у нас є документ, який містить адреси:
<Address>
     <Street>Wilhelminenstr. 7</Street>
     <City>Darmstadt</City>
     <State>Hessen</State>
     <Country>Germany</Country>
     <PostalCode>D-64285</PostalCode>
  </Address>
і документ, що містить інформацію веб-сервера:
  <Server>
     <Name>OurWebServer</Name>
     <Address>123.45.67.8</Address>
  </Server>
Тепер припустимо, що ми хотіли документі відомства, їх адреси, і їх веб-серверів, який ми можемо зробити з наведених вище документів, плюс трохи додаткової інформації:
  <Departments>
     <Department>
        <Name>DVS1</Name>
        <Address>
           <Street>Wilhelminenstr. 7</Street>
           <City>Darmstadt</City>
           <State>Hessen</State>
           <Country>Germany</Country>
           <PostalCode>D-64285</PostalCode>
        </Address>
        <Server>
           <Name>OurWebServer</Name>
           <Address>123.45.67.8</Address>
        </Server>
     </Department>
     ...
  </Departments>
На жаль, у нас є проблема: є дві адреси типи елементів і два типи Ім'я елемента. (Хоча типи Ім'я елемента як у моделі змісту PCDATA, вони мають різні значення - одне це назва відділу, а інша ім'я сервера - таким чином, ми хотіли б визнати їх у якості різних типів елементів. ) Для вирішення цих конфліктів, ми можемо використовувати XML простору імен. Ми присвоюємо інформацією звертайтеся до http://www.tu-darmstadt.de/ito/addresses імен, сервер інформацію імен http://www.tu-darmstadt.de/ito/servers, і знову доданих відомча інформація імен http://www.tu-darmstadt.de/ito/depts. Таким чином, наш новий документ виглядає наступним чином:
<dept:Departments
        xmlns:dept="http://www.tu-darmstadt.de/ito/depts
        xmlns:addr="http://www.tu-darmstadt.de/ito/addresses
        xmlns:serv="http://www.tu-darmstadt.de/ito/servers>
     <dept:Department>
        <dept:Name>DVS1</dept:Name>
        <addr:Address>
           <addr:Street>Wilhelminenstr. 7</addr:Street>
           <addr:City>Darmstadt</addr:City>
           <addr:State>Hessen</addr:State>
           <addr:Country>Germany</addr:Country>
           <addr:PostalCode>D-64285</addr:PostalCode>
        </addr:Address>
        <serv:Server>
           <serv:Name>OurWebServer</serv:Name>
           <serv:Address>123.45.67.8</serv:Address>
        </serv:Server>
     </dept:Department>
     ...
  </dept:Departments>
Хоча ми могли б призначити тільки конфліктуючих елементів типу імен XML простору імен, як правило, краще тримати імена типів, пов'язаних з елементом в одному XML простору імен. Це дозволяє уникнути питань, щоб пам'ятати імена яких були поміщені в простір імен XML, а які ні, а також уникнути майбутніх конфліктів, які можуть виникнути, коли ці типи використовуються в інших місцях. (Це не обов'язково означає, що імена всіх пов'язаних типів елементів і атрибутів повинні бути поміщені в одну XML простору імен. Якщо у вас є великий і складний набір типів елементів і атрибутів і чекає повторного підмножин в іншому місці, це може зробити більше сенсу розміщувати імена всіх багаторазових підмножина в своїх імен XML). Цей приклад був досить простий, що вона не вимагає, щоб ми змінили існуючі моделі змісту. Однак припустимо, що ми хотіли зберегти інформацію тільки про сервери: їх імена, IP-адреси та місцезнаходження. У цьому випадку, ми могли б додати тип адреси елемента, який описує поштову адресу з вмістом типу елемента Сервер:
  <serv:Servers
        xmlns:addr="http://www.tu-darmstadt.de/ito/addresses
        xmlns:serv="http://www.tu-darmstadt.de/ito/servers2>
     <serv:Server>
        <serv:Name>OurWebServer</serv:Name>
        <serv:Address>123.45.67.8</serv:Address>
        <addr:Address>
           <addr:Street>Wilhelminenstr. 7</addr:Street>
           <addr:City>Darmstadt</addr:City>
           <addr:State>Hessen</addr:State>
           <addr:Country>Germany</addr:Country>
           <addr:PostalCode>D-64285</addr:PostalCode>
        </addr:Address>
     </serv:Server>
     ...
  </serv:Servers>
Зверніть увагу, що ми змінили ім'я простору імен XML для сервера інформацію http://www.tu-darmstadt.de/ito/servers2. Це тому, що ми змінили модель змісту тип елемента Server. Іншими словами, зміст моделі двох типів серверів елемента різні, тому вони є двома різними типами елементів з однаковим ім'ям і повинні знаходитися в окремому XML простору імен. Якби ми не зробили цього зміни, програма шукає старого типу елемента сервер би неправильно оброблений новий тип елементу сервер і навпаки. Як ви можете бачити, немає нічого магічного поєднання документів. Це просто питання вирішити, як з урахуванням їх разом, і, хоча, ймовірно, будуть інструменти в майбутньому, які роблять це так просто, як перетягнути і падіння, рішення саме про те, як об'єднати їх, швидше за все, завжди вимагають людських втручання. Ви також можете бачити, що простір імен XML відіграє життєво важливу роль в цьому процесі - вони дозволили нам об'єднати документи, не міняючи місцеві назви будь-який з типів елементів. Це важливо, тому що без простору імен XML ми будемо безкінечно доведеться придумувати нові способи перейменування простих типів елементів, як адреси. Тим не менш, це також важливо розуміти, що рішення повторюваних імен є єдиною ролі простору імен XML відіграє в цьому процесі - інше було залишено на людей, які приймають рішення. 10,6) Як використовувати простору імен XML з Internet Explorer 5.0 і / або аналізатор MSXML? УВАГА! Наступне відноситься тільки до ранньої версії MSXML. Це не відноситься до MSXML 4, який є в даний час доставка версія [липні 2002]. Рання версія аналізатора MSXML, який був відправлений у складі Internet Explorer 5.0, потрібно, щоб кожен префікс простору імен XML використовується в тип елемента або атрибута повинно було бути "заявив, що" в оголошенні атрибута для цього типу елемента. Це повинно було бути зроблено з фіксованою декларації атрибуту XMLNS. Наприклад, наступне було прийнято MSXML і обидва XMLNS: Foo атрибути були необхідні:
<!ELEMENT foo:A (#PCDATA)>
   <!ATTLIST foo:A
             xmlns:foo CDATA #FIXED "http://www.foo.org/">
   <!ELEMENT foo:B (#PCDATA)>
   <!ATTLIST foo:B
             xmlns:foo CDATA #FIXED "http://www.foo.org/">
MSXML повертається повідомлення про помилку на наступний, тому що другий префікс Foo не був "оголошений":
   <!ELEMENT foo:A (#PCDATA)>
   <!ATTLIST foo:A
             xmlns:foo CDATA #FIXED "http://www.foo.org/">
   <!ELEMENT foo:B (#PCDATA)>
Причина цього обмеження було так, що MSXML може використовувати розширені імена відповідно до типу елементів і атрибутів для елементів і атрибутів під час перевірки. Хоча це спростило б багато проблем написання документів, які одночасно є дійсними і відповідають XML рекомендація просторів імен (див. питання 7.6), деякі користувачі скаржилися, тому що це не було частиною XML рекомендація просторів імен. У відповідь на ці скарги, Microsoft видалила це обмеження в більш пізніх версіях, які зараз доставці. Як не дивно, ідея була пізніше незалежно отриманих як спосіб вирішення проблем дійсності і простору імен. Тим не менш, вона не була реалізована ніким. 11) РОЗДІЛ 11: Обробка XML простору імен в XML-додатків 11,1) Як додатками процесу документи, які використовують простору імен XML? Додатки обробляти документи, які використовують XML простору імен в майже точно так само, як вони обробляють документи, які не використовуються простори імен XML. Наприклад, якщо простори імен не знають додаток додає новий порядок продажу баз даних при виявленні SalesOrder елемента, еквівалентного простору імен додаток робить те ж саме. Різниця лише в тому, що простори імен програми: Може знадобитися для перевірки атрибутів XMLNS і розбір імен. Якщо він робить це залежить від того, така обробка вже зробили більш низького рівня програмного забезпечення, таких як простору імен реалізації DOM. Використовує розширений (дві частини) імена замість локального (одна частина) імена. Наприклад, простору імен додаток може додати нове замовлення на продаж у відповідь на {} http://www.tu-darmstadt.de/ito/sales SalesOrder елемента замість SalesOrder елемент. 11,2) Як використовувати простору імен XML з SAX 1.0? Найпростіший спосіб використання простору імен XML з SAX 1.0 є використання імен SAX Джон Коуена фільтра. На жаль, це, здається, не бути доступна будь більш (див. http://www.ccil.org/ ~ Коуен / XML). Це SAX фільтр, який відстежує декларацій простору імен XML, аналізує повні імена, і повертається тип імена елементів і атрибутів, як розширених імен у вигляді: <i>URI</i>^<i>local-name</i> Наприклад: http://www.tu-darmstadt.de/ito/sales^SalesOrder Ваш додаток може засновувати свою обробку на ці довгі імена. Наприклад, код: public void startElement(String elementName, AttributeList attrs) throws SAXException { ... if (elementName.equals("SalesOrder")) { // Add new database record. } ... } might become: public void startElement(String elementName, AttributeList attrs) throws SAXException { ... if (elementName.equals("http://www.tu-darmstadt.de/sales^SalesOrder")) { // Add new database record. } ... } або: public void startElement(String elementName, AttributeList attrs) throws SAXException { ... // getURI() and getLocalName() are utility functions // to parse expanded names. if (getURI(elementName).equals("http://www.tu-darmstadt.de/ito/sales")) { if (getLocalName(elementName).equals("SalesOrder")) { // Add new database record. } } ... } Якщо ви не хочете використовувати простір імен SAX Filter (або не можуть її отримати), то вам необхідно зробити наступне на додаток до визначення типів елементів і атрибутів, їх розширили імена: У StartElement, сканування атрибути для оголошення простору імен XML, перш ніж робити будь-яку іншу обробку. Вам потрібно буде підтримувати таблицю поточного префікса до URI посиланням відображення (в тому числі нульовою префікс для простору імен за замовчуванням XML). У StartElement і EndElement, перевірте тип елемента включає в себе префікс. Якщо це так, використовуйте свій відображення зіставити цей префікс URI посилання. В залежності від того, як програма працює, ви можете також перевірити, якщо локальна частина повне ім'я включає в себе будь-які двокрапки, які є незаконними. У StartElement, перевірте імена атрибутів містить префікс. Якщо так, то процес, як і в попередньому пункті. 11,3) Як використовувати простору імен XML з SAX 2.0? SAX 2.0 в першу чергу підтримує простору імен XML за допомогою таких методів: StartElement і EndElement в ContentHandler інтерфейс повернення просторів імен та локальні імена, а також кваліфіковані імена. GetValue, GetType, і GetIndex в інтерфейсі Атрибути можуть отримати інформацію про атрибути по імені простору імен і локального імені, а також імені. Наприклад, простір імен не знають SAX 1.0 код:
 public void startElement(String elementName, AttributeList attrs)
      throws SAXException
   {
      ...
      if (elementName.equals("SalesOrder"))
      {
         // Add new database record.
      }
      ...
   }
might become:
   public void startElement(String namespaceURI,
                            String localName,
                            String qualifiedName,
                            Attributes attrs)
      throws SAXException
   {
      ...
      if (namespaceURI.equals("http://www.tu-darmstadt.de/sales") &amp;&amp;
          localName.equals("SalesOrder"))
      {
         // Add new database record.
      }
      ...
   }
Хоча ці методи достатньо для більшості додатків, SAX 2.0 також підтримує наступні: startPrefixMapping і endPrefixMapping у зворотному ContentHandler інтерфейс сфери інформації про окремих префіксів. Це корисно, наприклад, коли кваліфіковані імена використовуються в елемента або значеннях атрибутів (наприклад, в XML-схем) і додаток повинен проаналізувати ці імена і дозволу префіксів простору імен собі. getURI, getLocalName, і getQName в інтерфейсі атрибути повернутися простору імен, локальне ім'я та повне ім'я атрибута за індексом. Http :/ / xml.org / features / namespaces і http://xml.org/features/namespace-prefixes властивості дозволяють додаткам запитувати чи парсери повертають повні імена і XMLNS атрибути. Для отримання додаткової інформації див SAX сторінки простору імен. Клас NamespaceSupport допомагає відслідковувати додатків в даний час оголошений префікси простору імен і назв. Це корисно, наприклад, коли кваліфіковані імена використовуються в елемента або значеннях атрибутів (наприклад, в XML-схем) і додаток повинен проаналізувати ці імена і дозволу префіксів простору імен собі. Для отримання повної інформації див. опис простору імен обробка в SAX 2.0. 11,4) Як використовувати простору імен XML з DOM Level 1? Це залежить від того, DOM Level 1 здійсненням ви використовуєте. Якщо ви використовуєте простору імен DOM реалізації, такі, як від каналу даних (Microsoft), IBM, Oracle, або Сонце, то все що вам потрібно зробити, це використовувати методи, які надаються тих реалізацій, щоб отримати ім'я простору імен і локальні імена . Наприклад, простір імен не знають код для читання з документа:
 // Check the local name.
  // getNodeName() is a DOM Level 1 method.

  if (elementNode.getNodeName().equals("SalesOrder"))
  {
     // Add new database record.
  }
могли б стати наступні простори імен коду при використанні DOM реалізації Oracle:
  // Check the XML namespace name (URI reference).
  // getNamespace() and NSElement are Oracle-specific.

  String SALES_NS = "http://www.tu-darmstadt.de/ito/sales";
  if ((NSElement)elementNode).getNamespace().equals(SALES_NS))
  {

     // Check the local name.
     // getLocalName() is Oracle-specific.

     if ((NSElement)elementNode.getLocalName().equals("SalesOrder"))
     {
        // Add new database record.
     }
  }
Оскільки DOM Level 1, не включають підтримку XML простору імен, кожне DOM Level 1, реалізація надає дещо інший інтерфейс для доступу до XML інформацію простору імен. Більшість з цих реалізацій включають деякі комбінації методів для отримання повного імені, імені простору імен, локальне ім'я та префікс. Тому, якщо ви пишете DOM-нейтральною додатки, вам необхідно визначити свої власні XML-інтерфейс імен та писати перетворювачі для кожної реалізації DOM ви підтримуєте. На щастя, це легко зробити. Якщо ви використовуєте простір імен не знають DOM реалізації, такі як Docuverse версії 1 або OpenXML версія 1 (вони можуть підтримувати простору імен XML у більш пізньої версії), вам необхідно виконати імен обробку самостійно. Хоча це багато в чому так само, як у додатку SAX 1,0 (див. питання 11,2) - перевірка на XMLNS атрибути для кожного елемента вузла і перетворення кваліфіковані імена елементів і вузлів Attr до розширення імена - це потенційно більш важко визначити, що XML оголошення простору імен в області видимості для будь-якого даного вузла. Якщо ваша заявка проходить дерева DOM в порядку від кореня, це досить легко, так як ви можете підтримувати приставку до URI посиланням відображення, як ви йдете. Однак, якщо ви отримуєте доступ до дерева випадково, ви можете побудувати паралельну дерево з відображенням інформації, перш ніж робити будь-яку іншу обробку або перебудувати дерево DOM використанням префіксів, які зіставляються з відомими посилання URI. 11,5) Як використовувати простору імен XML з DOM Level 2? DOM Level 2 і підтримує простору імен XML за допомогою ряду нових методів і атрибутів. Найбільш важливими з них є NamespaceURI і LocalName атрибути у вузлі інтерфейс, це дозволяє додаткам ідентифікувати вузли по імені простору імен і локального імені, а не по імені. Наприклад, простір імен не знають код для читання з документа:
// Check the local name.
  // getNodeName() is a DOM Level 1 method.

  if (elementNode.getNodeName().equals("SalesOrder"))
  {
     // Add new database record.
  }
могли б стати наступні простори імен код:
  // Check the XML namespace name (URI reference).
  // getNamespaceURI() is a DOM Level 2 method.

  String SALES_NS = "http://www.tu-darmstadt.de/ito/sales";
  if (elementNode.getNamespaceURI().equals(SALES_NS))
  {

     // Check the local name.
     // getLocalName() is a DOM Level 2 method.

     if (elementNode.getLocalName().equals("SalesOrder"))
     {
        // Add new database record.
     }
  }
Ситуація при створенні або зміні документа є більш складним. Це тому, що DOM Level 2 не автоматично підтримувати XML декларації простору імен. Тобто, це не додає автоматично XMLNS атрибути використовуються для оголошення простору імен XML. Замість цього, ви повинні зробити це самі. Наприклад, припустимо, у вас є дерево DOM, який подає такі документи, і ви хочете додати <bar:C> Баз </ бар: C> як дитина Foo: B, де риса префікс відповідає http:/ / www.foo.org / бар імен. <foo:A xmlns:foo="http://www.foo.org/foo"> <foo:B> </foo:B> </foo:A> Наступний код може бути використаний, щоб зробити це: // Створення текстового вузла. Text text = document.createTextNode("baz"); // Створення панелі: C елемент і додати текстовий вузол Element elementbarC = document.createElementNS("http://www.foo.org/bar", "bar:C"); elementbarC.appendChild(text); // Додавання панелі: C елемент в якості дочірнього Foo: B elementfooB.appendChild(elementbarC); На жаль, якщо дерево DOM серіалізуются в цей момент, то результат буде таким, який не оголошує http://www.foo.org/bar імен. <foo:A xmlns:foo="http://www.foo.org/foo"> <foo:B> <bar:C>baz</bar:C> <=== Error! bar prefix never declared </foo:B> </foo:A> Щоб вирішити цю проблему, ви повинні явно додати XMLNS: бар атрибут оголосити http://www.foo.org/bar імен. (На відміну від SAX 2.0, DOM Level 2 відноситься до простору імен декларацій (XMLNS атрибути) як звичайні атрибути.) // Створення текстового вузла. Text text = document.createTextNode("baz"); // Створення панелі: C елемент і додати текстовий вузол Element elementbarC = document.createElementNS("http://www.foo.org/bar", "bar:C"); elementbarC.appendChild(text); / / Додати XMLNS: бар атрибут бару: C елементів. Перший аргумент / / Це простір імен, пов'язане з префіксом XMLNS, другий / / Аргумент є ім'ям атрибута, а третій аргумент є значенням / / Атрибут (імен були оголошені). elementbarC.setAttributeNS("http://www.w3.org/2000/xmlns/", "xmlns:bar", "http://www.foo.org/bar"); / / Додавання панелі: C елемент в якості дочірнього Foo: B elementfooB.appendChild(elementbarC); Дерево DOM тепер буде серіалізуются наступним чином: <foo:A xmlns:foo="http://www.foo.org/foo"> <foo:B> <bar:C xmlns:bar="http://www.foo.org/bar">baz</bar:C> </foo:B> </foo:A> Аналогічна ситуація виникає при копіюванні вузлів з одного документа в інший. Зокрема, якщо елемент або атрибут копіювання залежить від простору імен, оголошених у предка елемента, простору імен повинні бути повторно оголошений в новому документі. Для отримання повної інформації див в DOM Level 2 рекомендації. 11,6) Як використовувати простору імен XML з DOM Level 3? DOM Level 3 підтримує простору імен таким же чином, як DOM Level 2, за винятком того, що він додає кілька нових методів і підтримує версію 1.1 Простори імен у XML-рекомендації. Найбільш важливі новий метод Document.normalizeDocument в якому, серед іншого, очищає оголошення простору імен. Таким чином, більше немає необхідності явно додавати оголошення просторів імен (XMLNS атрибути). Замість цього, ви можете зателефонувати Document.normalizeDocument і реалізації DOM зробить це за вас. (Саме те, що зроблено, залежить від ряду параметрів конфігурації. Див DOMConfiguration подробиці). Наприклад, DOM Level 2 код в питанні 11,5 до додати елемент в новий простір імен в існуюче дерево DOM буде виглядати так: / / Створення текстового вузла. Text text = document.createTextNode("baz"); / / Створення панелі: C елемент і додати текстовий вузол Element elementbarC = document.createElementNS("http://www.foo.org/bar", "bar:C"); elementbarC.appendChild(text); / / Додавання панелі: C елемент в якості дочірнього Foo: B elementfooB.appendChild(elementbarC); / / Виклик Document.normalizeDocument додати декларації (XMLNS атрибутів) для / / Http :/ / www.foo.org / bar імен. document.normalizeDocument (); Для отримання повної інформації див. Додаток A: Зміни в DOM Level 3 рекомендації. 11,7) Чи може процес подачі заявки документи, які використовують простору імен XML і документи, які не використовуються простори імен XML? Так. Це звичайна ситуація для універсальних додатків, таких як редактори, браузери та аналізатори, які не підключені до розумію зокрема XML мову. Такі додатки просто лікувати всіх типів елементів і атрибутів імен, як повні імена. Ті імена, які не відображаються в простір імен XML - тобто, без префікса типу елемента імена у відсутності замовчуванням простір імен XML і атрибут без префікса імена - просто обробляється як одна частина назви, наприклад, за допомогою нульового простору імен XML ім'я. Відзначимо, що такі додатки повинні вирішити, як ставитися до документів, які не відповідають XML рекомендація просторів імен. Наприклад, те, що має робити, якщо додаток тип елемента містить двокрапку (що передбачає наявність префікса), але немає ніяких декларацій простору імен XML у документі? Додаток може ставитися до цього як помилку, або він може трактувати документ як один, що не використовують XML простору імен, ігнорувати "помилку", і продовжити обробку. 11,8) може бути як додатком простору імен і просторів імен не знають? Так. Однак, як правило, немає причин для цього. Причина в тому, що більшість додатків зрозуміти той чи інший мову XML, наприклад, один використовується для передачі замовлень між компаніями. Якщо тип імена елементів і атрибутів в мові належать до простору імен XML, додаток повинен бути простору імен, а якщо ні, то додаток повинен бути простір імен не знають. Наприклад, такі програми ніколи не повинні визнавати типи елементів SalesOrder і {} http://www.tu-darmstadt.de/ito/sales SalesOrder. За кілька додатків, будучи одночасно простору імен і просторів імен не знають сенс. Наприклад, синтаксичний аналізатор може вибрати, щоб переглянути дії відносно розширених імен (див. простір імен Міф № 9) і обидва простору імен і просторів імен не знають режиму перевірки. Тим не менш, такі заяви є рідкістю. 11,9) Що таке простору імен додатка робити, коли він зустрічає помилку? Рекомендації XML Namespaces не уточнює, які простори імен додаток робить, коли він стикається з документом, який не відповідає рекомендації. Таким чином, поведінка в залежності від застосування. Наприклад, додаток може припинити обробку, повідомлення про помилку в журнал і продовжити обробку або проігнорувати помилку. ЧАСТИНА III: імена, префіксів і URI, 12) РОЗДІЛ 12: ІМЕНА 12,1) Що таке повне ім'я? Повне ім'я це назва наступній формі. Він складається з додаткового префікса і товстої кишки, а потім локальна частина, яку іноді називають локальним ім'ям. <i>prefix</i>:<i>local-part</i> --OR-- <i>local-part</i> Наприклад, обидва з наступних імен. Перше ім'я має префікс Serv, друге ім'я не має префікса. Для обох імен, локальна частина (місцева назва), адреса. serv:Address Address У більшості випадків, кваліфіковані імена перетворюються в розширеному імена. Для отримання додаткової інформації див питання 12.6. 12,2) Що таке QName? QName є кваліфікованим ім'ям. Термін походить від БНФ, використовувані в Простори імен у XML-рекомендації, де QName це ім'я не-терміналу використовується, щоб дати синтаксис імені. На жаль, термін QName зазвичай використовується як скорочення для розширеного імені (див. питання 12.12). Це, ймовірно, походить від QName тип даних в XML-схем, який розширив імена, як її простір цінність і кваліфіковані імена, як його лексичного простору. 12,3) Які символи допускаються в повне ім'я? Префікс може містити будь-який символ, допустимий в імені [5] виробництво в XML 1.0, за винятком товстої кишки. Те ж саме відноситься і до локальних ім'ям. Таким чином, може бути не більше одного двокрапки в повне ім'я - двокрапка використовується для відділення префікса з локальним ім'ям. 12,4) Де можна кваліфіковані імена з'являються? Повні імена можуть з'явитися де завгодно тип елемента або ім'я атрибута може з'явитися: в початковий і кінцевий теги, як тип елемента документа, а в типі елементів і атрибутів в ЗТД. Наприклад:
<!DOCTYPE foo:A [
     <!ELEMENT foo:A (foo:B)>
     <!ATTLIST foo:A
               foo:C CDATA #IMPLIED>
     <!ELEMENT foo:B (#PCDATA)>
  ]>
  <foo:A xmlns:foo="http://www.foo.org/" foo:C="bar">
     <foo:B>abcd</foo:B>
  </foo:A>
Повні імена не може виступати як суб'єкт імена, позначення імен, або цільові інструкції по обробці. 12,5) Може повні імена використовуються у значеннях атрибутів? Так, але вони не мають особливого значення. Тобто, вони не завжди визнаються в якості таких і відображається на розширеному імена. Наприклад, значення атрибута C в наступній є рядок "Foo: D", а не розширене ім'я {} http://www.foo.org/ D.
<foo:A xmlns:foo="http://www.foo.org/">
     <foo:B C="foo:D"/>
  </foo:A>
Незважаючи на це, немає нічого, щоб зупинити додаток від визнання повне ім'я в значенні атрибута і обробку його як такий. Це робиться в різних сучасних технологій. Наприклад, в наступному визначенні XML-схеми, XS значення атрибута: рядок визначає тип атрибута Foo як розширене ім'я {} http://www.w3.org/1999/XMLSchema рядок.
  <xs:attribute name="foo" type="xs:string" />
Є два можливих проблем з цим. По-перше, додаток повинен мати можливість отримати приставку відображення діє в даний час. На щастя, обидва SAX 2.0 і DOM рівня 2 і 3 підтримують цю можливість. По-друге, будь загальний інструмент перетворення цілей, таких, як той, який пише XML-документа в канонічній формі і змін префіксів простору імен в процесі, не визнають повних імен у значеннях атрибутів і, отже, не перетворювати їх правильно. Хоча це може бути вирішено в майбутньому шляхом введення QName (повне ім'я) типу даних в XML-схем, це проблема сьогодні. 12,6) Як це кваліфіковані імена відображаються на імена простору імен XML? Якщо повне ім'я в тілі документа (на відміну від DTD) включає в себе префікс, то цей префікс використовується для відображення локальної частини повного імені в розширеному ім'я - тобто, ім'я простору імен XML . (Зауважимо, що префікс повинен знаходитися в області видимості -. Див розділ 6) Наприклад, в наступному, префікс Foo використовується для відображення локальних імен A, B, C і іменам в http://www.foo . ORG / простір імен:
 <?xml version="1.0" ?>
  <foo:A xmlns:foo="http://www.foo.org/" foo:C="bar">
     <foo:B>abcd</foo:B>
  </foo:A>
Якщо повне ім'я в тілі документа не містить префікс і простір імен XML за замовчуванням знаходиться в області, то одна з двох речей відбувається. Якщо ім'я використовується як тег елемента, вона відображається на ім'я в просторі імен за замовчуванням XML. Якщо воно використовується в якості імені атрибута, це не в будь-якому просторі імен XML (див. Простір імен Міф № 4). Наприклад, в наступному, А і В знаходяться в http://www.foo.org/ імен та C немає в жодному XML простору імен: <?xml version="1.0" ?> <A xmlns="http://www.foo.org/" C="bar"> <B>abcd</B> </A> Якщо повне ім'я в тілі документа не містить префікс, а не за замовчуванням простір імен XML знаходиться в області видимості, те, що ім'я не в просторі імен XML. Наприклад, в наступному, A, B, C і ні в якому XML простору імен: <?xml version="1.0" ?> <A C="bar"> <B>abcd</B> </A> Кваліфіковані імена в DTD ніколи не відображається на імена в просторі імен XML, тому що вони ніколи не знаходяться в сфері XML декларації простору імен. (Для отримання додаткової інформації див питання 7.2.) 12,7) Що таке префікс імені? Префікс ім'я повне ім'я (див. питання 12,1), який містить префікс. 12,8) Що таке префікса ім'я? Без префікса ім'я повне ім'я (див. питання 12,1), які не містять префікс. 12,9) готові без префіксів імен в XML імен? Тільки якщо вони використовуються в тілі документа (на відміну від DTD) як елемент тегів та імен XML за замовчуванням знаходиться в області. Для отримання додаткової інформації див питання 5.2. 12,10) Що таке місцева назва? Це ще один термін для локальної частини імені. Для отримання додаткової інформації див питання 12.1. 12,11) Що таке простір імен? Це ім'я використовується для ідентифікації простору імен. Це URI посилання. Для отримання додаткової інформації див питання 14.1. 12,12) Що таке розширене ім'я? Розширено назва складається з двох імен частина, що складається з імен XML простору імен і локального імені. Наприклад, в наступному, розширеному ім'я простору імен "http://www.tu-darmstadt.de/ito/servers" плюс місцева назва "Адреса":
<serv:Address xmlns:serv="http://www.tu-darmstadt.de/ito/servers">
     123.45.67.8
  </serv:Address>
Можливість задати розширені імена єдина функція XML простору імен. 12,13) Що таке розширене QName? Розширено QName являє собою розширену ім'я. Термін походить від рекомендацій XQuery, які, ймовірно, використовує термін замість того, щоб розширити ім'я, тому що вона має справу з іншими іменами. 12,14) Що таке універсальне ім'я? Універсальне ім'я розширене ім'я. Цей термін взятий зі статті Джеймсом Кларком і був використаний в більш ранню версію цього FAQ. (Перше видання імен в рекомендації XML 1.0 не забезпечує термін для цього поняття, термін розширене ім'я було введено у другому виданні). 12,15) Як розширити імена представлені? Існує немає стандартного способу представлення розширеного імені. Тим не менш, три подання є загальними. Перше представлення зберігає XML простору імен і локальну назву окремо. Наприклад, багато DOM Level 1 реалізацій мають різні методи для повернення XML простору імен і локальну назву вузла елемента або атрибута. Друга об'єднує уявлення простору імен і локального імені з кришки (^). В результаті універсальних унікальних (див. питання 12.16) ім'я, так як CARETS не допускається в URI посилання або місцеві назви. Цей метод використовується простір імен SAX Джон Коуена фільтр, який був написаний для обробки XML-простору імен в SAX 1.0. Наприклад, розширене ім'я, яке має URI посиланням http://www.tu-darmstadt.de/ito/servers і місцевого Адреса назву буде представлено як: Адреса http://www.tu-darmstadt.de/ito/servers ^ Третє подання, яке ми використовуємо в цьому документі, були використані в статті Джеймсом Кларком. Він поміщає ім'я простору імен XML у фігурні дужки і поєднує це з локальним ім'ям. Це позначення пропонується тільки для документації та я знаю, немає коду, який використовує його. Наприклад, вказане ім'я буде представлена у вигляді: {} Адреса http://www.tu-darmstadt.de/ito/servers 12,16), розширюються імена універсального унікального? Ні, але є підстави припускати, що вони є. Розширене типу елемента і імена атрибутів не гарантує універсальний унікальний - тобто, унікальний в просторі всіх XML-документів - тому що це можливо для двох різних людей, кожен з яких визначає свій власний простір імен XML, щоб використовувати те ж посилання URI і той же тип елемента або атрибута. Однак це відбувається тільки у випадку, якщо: Один або обидва люди використовують URI посиланням який не знаходиться під їх контролем, такими, як хтось зовні Netscape допомогою http://www.netscape.com/ URI посилання, або І люди мають контроль над URI посилання і як його використовувати. Перший хтось засобів випадок обману при призначенні URI (процес регулюється довіри) і в другому випадку означає, що дві людини в організації, не звертаючи уваги на роботу один одного. Для широко публікуються типу імен елементів і атрибутів, ні в одному випадку досить імовірно. Таким чином, розумно припустити, що розширені імена універсальних унікальних. (Так як обидва випадки, додатків, які представляють загрозу безпеці повинні бути обережні при умові, що розширене імена універсальних унікальних). Для отримання інформації про можливості розширеного імена для ідентифікації типів елементів і атрибутів (на відміну від імен собі є унікальним), см. Простір імен Міф № 2. 13) РОЗДІЛ 13: Префікси простору імен XML 13,1) Що таке префікс простору імен XML? Префікс простору імен XML являє собою префікс, використовуваний для зазначення того, що місцевий тип елемента або атрибута зокрема XML простору імен. Наприклад, в наступному, Serv префікс вказує, що типом елемента адреси ім'я в просторі імен http://www.tu-darmstadt.de/ito/addresses: <serv:Addresses xmlns:serv="http://www.tu-darmstadt.de/ito/addresses"> 13,2) Які символи допускаються в префікс простору імен XML? Префікс може містити будь-який символ, допустимий в імені [5] виробництво в XML 1.0, за винятком товстої кишки. Слід зазначити, що префікс XML може бути пов'язаний з ім'ям простору імен http://www.w3.org/XML/1998/namespace. Префікс XMLNS не можуть бути використані, окрім оголосити простір імен, наприклад, XMLNS: XMLNS = "http://www.w3.org/2000/xmlns/" не є офіційною декларацією простору імен. 13,3) префікси значущим? Ні. Наприклад, наступні умови еквівалентні:
<serv:Addresses xmlns:serv="http://www.tu-darmstadt.de/ito/addresses">
і
  <foo:Addresses xmlns:foo="http://www.tu-darmstadt.de/ito/addresses">
Тим не менш, приставки забезпечують візуальний сигнал для читачів. Через це, програмне забезпечення (особливо редакторів) слід розглянути питання про збереження префіксів. Наприклад, це набагато простіше, таким чином:
  <xsl:stylesheet version="1.0"
                  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                  xmlns:html="http://www.w3.org/TR/xhtml1/strict">
  <xsl:template match="/">
     <html:html>
        <html:head><html:title>Title</html:title></html:head>
        <html:body>
           <xsl:apply-templates/>
        </html:body>
  </xsl:template>
  ...
  </xsl:stylesheet>
ніж це:
  <aaa:stylesheet version="1.0"
                  xmlns:aaa="http://www.w3.org/1999/XSL/Transform"
                  xmlns:bbb="http://www.w3.org/TR/xhtml1/strict">
  <aaa:template match="/">
     <bbb:html>
        <bbb:head><bbb:title>Title</bbb:title></bbb:head>
        <bbb:body>
           <aaa:apply-templates/>
        </bbb:body>
  </aaa:template>
  ...
  </aaa:stylesheet>
або (набагато гірше) це:
  <html:stylesheet version="1.0"
                  xmlns:html="http://www.w3.org/1999/XSL/Transform"
                  xmlns:xsl="http://www.w3.org/TR/xhtml1/strict">
  <html:template match="/">
     <xsl:html>
        <xsl:head><xsl:title>Title</xsl:title></xsl:head>
        <xsl:body>
           <html:apply-templates/>
        </xsl:body>
  </html:template>
  ...
  </html:stylesheet>
Незважаючи на це, люди можуть читати значення в префікси, так що це гарна ідея використовувати префікси, відповідні їх імен XML, таких як XSLT для простору імен XSLT. Нарешті, хоча префікси не є суттєвими в іменах елементів і атрибутів, вони можуть бути істотними при використанні в іншому місці документа XML, наприклад, в DTD (див. питання 7.6) або значення атрибуту. Тому що таке використання загального - наприклад, XML-схеми використовуються повні імена в значеннях атрибутів - це наштовхує на думку, що вона визначається XML рекомендація просторів імен. Це не так: XML рекомендації імен тільки визначає використання префіксів в іменах елементів і атрибутів. Використання префіксів в іншому місці документа XML визначена поза XML рекомендації імен та повністю відповідальність визначенні додатка. Для отримання додаткової інформації див питання 12.5. 13,4) Чи можу я використовувати той же префікс для більш ніж одного простору імен XML? Так. Наприклад, в наступному, B знаходиться в http://www.foo.org/ імен та C в http://www.bar.org/ імен:
 <A>
     <foo:B xmlns:foo="http://www.foo.org/">abc</foo:B>
     <foo:C xmlns:foo="http://www.bar.org/">abc</foo:C>
  </A>
Пам'ятайте, однак, що префікс в XML оголошення простору імен перекриває той же префікс, якщо це префікс заявив предка. Наприклад, в наступному, C знаходиться в http://www.bar.org/ імен, не http://www.foo.org/ імен:
  <A>
     <foo:B xmlns:foo="http://www.foo.org/">
        <foo:C xmlns:foo="http://www.bar.org/">abc</foo:C>
     </foo:B>
  </A>
Загалом, це хороша ідея використовувати префікс тільки для одного простору імен XML, так як це зменшує плутанину при читанні документа. Незважаючи на це, є дуже реальна можливість того, що той же префікс буде використовуватися для декількох просторів імен XML при об'єднанні фрагментів з різних документів. Для отримання додаткової інформації див питання 4.9. 13,5) Чи можу я використовувати більше одного префікса простору імен XML ж? Так. Наприклад, в наступному, як B і C знаходяться в http://www.foo.org/ імен:
<A xmlns:foo="http://www.foo.org/"
     xmlns:bar="http://www.foo.org/">
     <foo:B>abc</foo:B>
     <bar:C>abc</bar:C>
  </A>
Більш розумно, така ситуація може виникнути, коли копіювання або вирізання та вставка фрагментів з одного документа в інший, де кожен документ використовує інший префікс для тих самих імен. Наприклад, припустимо, http://www.foo.org/ імен використовується префікс Foo в одному документі, а в барі префікс в іншому документі. Копіювання елементів з одного документа в інший може призвести до документа, такі як наступні. Хоча це може ввести в оману, щоб читати, це абсолютно законно.
  <A xmlns:foo="http://www.foo.org/">
     <foo:B>abc</foo:B>
     <bar:C xmlns:bar="http://www.foo.org/">abc</bar:C>
  </A>
Загалом, це хороша ідея, щоб використовувати тільки один префікс для простору імен XML, так як це зменшує плутанину при читанні документа. 13,6) Як префікси оголосили? Префікси оголошені в декларації XML простір імен (XMLNS атрибут). Для отримання додаткової інформації див питання 4.1. 13,7) Чи можу я undeclare префікс - тобто, відділити префікс простору імен XML? Так, і ні. Це підтримується у версії 1.1, але не в версії 1.0. На момент написання статті [Січень, 2007], більшість програмного забезпечення мабуть, підтримує версію 1.0, так що ви не повинні розраховувати на цю можливість. Для отримання інформації про те, як undeclare префікс, див. питання 4.7. Зверніть увагу, що в обох версіях 1.0 і 1.1, можна перевизначити префікс (див. питання 4.5) або нехай XML оголошення простору імен, який оголошує префікс виходять з області видимості (див. питання 6.4). Ви також можете undeclare за замовчуванням простір імен XML (див. питання 4.8). 13,8) Що станеться, якщо використовувати префікс, який не оголошений? Це призводить до простору імен помилки. Наприклад, такі документи не відповідають XML рекомендація просторів імен.
<?xml version="1.0" ?>
  <foo:A />
Тим не менш, рекомендація XML простір імен не вказано, що простори імен додаток робить, коли він стикається з не-сумісних документів, тому поведінку залежно від застосування. Наприклад, додаток може припинити обробку, повідомлення про помилку в журнал і продовжити обробку або проігнорувати помилку. 13,9) Що станеться, якщо немає префікса ім'я типу елемента? Якщо за умовчанням простір імен XML декларації знаходиться в області, то тип елемента в просторі імен за замовчуванням XML. В іншому випадку, ім'я типу елемента немає в жодному XML простору імен. Наприклад, в наступному, B і C знаходяться в http://www.foo.org/ імен та ні в якому XML простору імен:
 <A>
     <B xmlns="http://www.foo.org/">
        <C>abc</C>
     </B>
  </A>
13.10) Що станеться, якщо немає префікса імені атрибута? Ім'я атрибуту немає ні в одному XML простору імен. Тобто, за умовчанням простір імен XML не поширюється на префіксів імен атрибутів. Для отримання додаткової інформації див Простір імен Міф № 4. 14) РОЗДІЛ 14: XML імена простору імен (URI) 14,1) Що таке XML простору імен? Назва XML простір імен URI посилання, який однозначно визначає простору імен. URI посилання використовуються, тому що вони зрозумілі і добре документовані. (Зауважимо, що посилання URI відрізняється від URI, в тому, що вони дозволяють ідентифікатори фрагмента (#)). Бо люди можуть тільки виділити URI, що перебувають під їх контролем, то легко переконатися, що немає двох просторів імен XML визначаються за тією ж посиланням URI. Примітка: Версія 1.1 XML рекомендації імен використовує IRI (Міжнародні ідентифікатори ресурсів) посилання замість URI посилання. 14,2) Що таке URI простору імен XML? URI простору імен XML є XML простору імен. Хоча термін формально не визначені в Простори імен у XML-рекомендації, воно зазвичай використовується. 14,3) Які символи допускаються в XML імена простору імен? Імен XML простору імен може містити будь-які символи дозволені у URI посилання. URI посилання порівнянні за принципом символ-за-символ, таким чином, капіталізація і використання знака відсотка (%) є значними. Наприклад, наступний визначити все той же ресурс відповідно до URI специфікації, але різні назви простору імен: http://www.example.org/wine http://www.example.org/wine # http://www.Example.org/wine http://www.example.org/win% 65 14,4) Чи можу я використовувати відносні посилання URI в якості імен назви? У версії 1.1, відповіді немає. У версії 1.0, так. Тим не менш, таке використання є застарілим, так що ви ніколи не повинні це робити. Оригінальний XML рекомендації імен прямо не забороняє використання відносних посилань URI в якості імен назви. Замість цього, він стверджує, що два імені простору імен є ідентичними, якщо їх посилання URI відповідає посимвольно. Потім він відзначає, що неідентичних посилання URI може бути функціонально еквівалентні, наприклад, коли вони відрізняються тільки в тому випадку. У поєднанні з специфікації URI (RFC2396), в якому говориться, що відносні посилання URI приймати на основі URI з того документа, це дає лазівку, з якою використовуються відносні посилання URI. Коли це було виявлено більш ніж через рік після рекомендація була випущена вона виявилася надзвичайно суперечливою. Наприклад, деякі люди хотіли використовувати відносні посилання URI простору імен, як імена, так що елементи і атрибути будуть мати різні імена простору імен XML в залежності від того, що документ, який вони були дюйма заперечень проти цього було те, що це підірве цілі XML простору імен. Тобто, простору імен XML більше не буде надавати універсальні унікальні імена. Після більш ніж двох місяців обговорень було вирішено, що відносні посилання URI не розширюються при використанні в якості простору імен, і що їх використання не рекомендується. Тобто, припустимо, що наступний документ має URI з "http://www.foo.org/xml/relativeExample.xml".
 <A xmlns:foo="../relativeURI">
     <foo:B>abc</foo:B>
     <bar:C>abc</bar:C>
  </A>
Хоча URI посилання ".. / RelativeURI" не розширюватиметься на URI посилання "http://www.foo.org/relativeURI", ім'я XML імен, пов'язане з префіксом Foo є ".. / RelativeURI", не розширений посиланням URI. Було також вирішено, що: Infoset рекомендації не визначають набір відомостей для документів, які використовуються відносні посилання URI в якості імен XML простору імен. Значення атрибута NamespaceURI з вузлів інтерфейсу DOM не визначений, якщо URI посилання є відносною. Значення, що повертається простору імен URI () в XPath не визначений, якщо URI посилання є відносною. Всі нові рекомендації W3C має включати заяву про те, що вони не відносяться до XML-документів, які використовуються відносні посилання URI в якості імен XML простору імен. Для архівах списку розсилки обговорює використання відносних посилань URI простору імен, як імена, див http://lists.w3.org/Archives/Public/xml-uri/. За результатами W3C XML Пленарне голосування по використанню відносні посилання URI в XML імена простору імен, див http://www.w3.org/2000/09/xppa. 14,5) Що означає посилання URI використовується як XML точці простору імен, щоб? URI посиланням використовуватися в якості простору імен XML є просто ідентифікатором. Він не гарантовано, щоб вказати на що-небудь, і, загалом, це погана ідея, щоб припустити, що він робить. Цей момент викликає багато плутанини, тому ми будемо повторювати його тут: URI REFERNECESs використовуються для позначення простору імен XML тільки ідентифікатори. ВОНИ не гарантується вказує ні на що. Хоча це може ввести в оману, коли URL-адреси використовуються в якості імен назви, це очевидно, коли інші типи URI посилання використовуються в якості імен назви. Наприклад, наступне оголошення простору імен використовуються URN ISBN: XMLNS: XBE = "урни: ISBN :0-7897-2504-5" і наступне оголошення простору імен використовує UUID URN: XMLNS: Foo = "урни: UUID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6" Очевидно, що ні простору імен вказує на щось в Інтернеті. ПРИМІТКА: Імена просторів імен URL-адрес, які можуть указувати на RDDL документів, хоча це, здається, не буде широко реалізовано. Для отримання додаткової інформації див наступне питання. ПРИМІТКА: ранню версію XML-схеми W3C, використовувати простору імен, щоб вказати на XML документ схема, що містить визначення типів елементів і атрибутів, зазначених у просторі імен. Тим не менш, це виявилося дуже спірним, і ідея була знята. 14,6) Чи можу я вирішити URI посиланням використовуватися в якості простору імен XML? Так. Ви також можете їсти трактор, але це не означає, що це гарна ідея. URI посилання, які використовуються в якості імен XML простору імен не гарантується, щоб вказати на щось, так що, як правило, немає підстав для їх вирішення. Крім того, немає нічого в обробці XML простору імен, які вимагає від вас, щоб вирішити ці URI посилання. Нарешті, як було зазначено в попередньому питанні, багато типів імен імена нерозв'язних в Інтернеті. Тим не менш, деякі люди виступають за розміщення RDDL (Resource Description Language каталогів, вимовляється як "загадка") документів на місцях, на яку вказує простору імен. RDDL документ "надає текстовий опис деяких класів ресурсів і окремих ресурсів, що відносяться до цього класу", в тому числі такі речі, як людського розуміння опис того, що описує простір імен і посилання на ресурси, такі як схеми (в різних мовах ), таблиць стилів та коду. RDDL документів, по-видимому, використовуються, хоча і не ясно, наскільки широко. Для отримання додаткової інформації про RDDL та ідеї, за нею див.:
  • Каталог ресурсів Description Language
  • RDDL мені: Що таке простір імен URL Знайдіть?
  • Архітектурний Тези про Простори назв та імен документів
  • Використовуйте RDDL з XML і веб-служб імен
14,7) Чи існують XML імена простору імен захищені? Так. Http :/ / www.w3.org/XML/1998/namespace простору імен, по визначенню, пов'язаного з XML префікс. Це не можуть бути скасовані або пов'язаний з будь-яким іншим префіксом, не може префікс XML бути пов'язаний з будь-яким іншим ім'ям простору імен. Зверніть увагу, що це не потрібно оголосити цей простір імен, хоча він є законним для цього. Http :/ / www.w3.org/2000/xmlns/ простору імен, по визначенню, пов'язаного з префіксом XMLNS. Вона не може бути оголошену або фактичну, і не може префікс XMLNS бути пов'язаний з будь-яким іншим ім'ям простору імен. 14,8) Чому XML рекомендації імен використовувати як префікси і простору імен? Чому б не використати один або інший? Використовуючи тільки імена простору імен не працює з технічних причин: URI посилання можуть містити символи не допускаються в XML імена. Наприклад, припустимо, що простір імен рекомендації використовуються тільки URI посилання. Це призведе до документів, таких як:
 <http://www.foo.org/:foo>
      <http://www.foo.org/:bar />
   </http://www.foo.org/:foo>
Цей документ є незаконним, так як слеш (/) характеру не допускаються в імена елементів. Дві додаткові проблеми в тому, що (а) воно неможливо відрізнити двокрапка (:) в URL з товстої кишки використовується для поділу простору імен з локального імені, і (б) неможливо відрізнити слеш в URL з коса риса використовується для завершення порожнім {} http://www.foo.org бар елемент. Нетехнічних проблема в тому, що імена елементів важко читати. Використовуючи тільки префікси не працює з політичних причин: немає імен орган, який призначає префікси, так що немає нічого, щоб запобігти дві людини від вибору і той же префікс. Наприклад, два різних компаніях створення схем для замовлень може і хочуть використати "порядок" префікс. Без центрального органу імен, цей спір не може бути вирішено. Використання URI посилань дозволяє уникнути цієї проблеми, так як URI, знаходяться під контролем існуючих організацій, таких, як доменне ім'я реєстрів та Міжнародним агентством ISBN. ЧАСТИНА IV: РІЗНЕ 15) РОЗДІЛ 15: ПОЛІТИКА І РЕВОЛЮЦІЇ 15,1) Чому XML простору імен так важко зрозуміти? Простору імен XML насправді не так вже важко зрозуміти, - все це вказує рекомендація спосіб відображення кваліфікований (з префіксом) імена універсальних імен. Ось і все. Ніщо інше. На жаль, більшість людей, які дізнаються про XML простору імен мають в анамнезі з іменування і принести багато ідей з ними. Ці ідеї зробити це важко зрозуміти, XML простору імен. Навіть термін імен викликає проблеми. Простір імен XML являє собою набір імен, але Простори імен у XML рекомендації навіть не говорити про цю колекції за межі свого первісного визначення. (Насправді, ця колекція не має значення так, що він навіть не згадується у версії 1.1 рекомендацій.) Ми всі були б набагато краще, якби рекомендації були викликані "Universal імен в XML" або щось подібне, що підкреслюється Ідея універсального унікальні імена, а будь-яка колекція таких назв. Тим не менш, ми можемо тепер обговорити основні пункти відключення при вивченні XML простору імен. Є два основних пункти, які плутають людей:
  • URL-адреси, імена XML простору імен. Більшість XML імена простору імен URL-адрес. Це тому, що URL-адреси є найбільш широко відомі і використовуються вид URI посилання. На жаль, люди очікують URL-адреси, щоб вказати на щось в Інтернеті. Коли йому сказали, що вони не роблять, вони цілком обгрунтовано плутають. Так що давайте просто підтвердити цю точку зору: XML імена простору імен (навіть якщо вони і URL), не вказує ні на що. Вони просто ідентифікатори.
  • Простота. Простору імен XML набагато простіше, ніж можна було очікувати. Як було згадано вище, простору імен в XML рекомендації дійсно тільки забезпечує одне: спосіб відображення повних імен до розширення імена. На жаль, більшість людей намагаються, щоб прочитати більше у рекомендації, ніж дійсно існує. Для пояснення багатьох з цих речей, побачити простір імен Міфи підірвано.
Є цілий ряд інших заплутаною пунктів, а також:
  • Відсутність підтримки DTD. DTD, не підтримують XML простору імен. Хоча це можна перевірити документ, який використовує XML простору імен з DTD, яким чином це буде зроблено порушує дух Простори імен у XML-рекомендації. Для отримання додаткової інформації див питання 7.6.
  • Попереднє правил. Хоча це не особливо важко, оглядового правила не викликати деяку плутанину. Для отримання додаткової інформації про визначення сфери охоплення, див. Розділ 6: Сфера XML декларації простору імен.
  • Без префікса атрибути не є в будь-якому просторі імен. Ця невідповідність між тим, що імена елементів і атрибутів розглядаються. Це, здається, був естетичний, а не технічні, вибір. На жаль, це викликає нескінченну плутанину. Для отримання додаткової інформації див Простір імен Міф № 4.
  • Невідповідність між технологіями. Різні специфікації лікування простору імен XML-різному. Наприклад, декларації простору імен XML атрибути в DOM Level 2, але не в SAX 2.0, і декларації простору імен за замовчуванням не застосовується до QNames у виразах XPath 1.0.
  • QNames в якості елемента або значеннях атрибутів. QNames часто використовується в елементі або атрибуті значення. Наприклад, у XML-схем, вони використовуються для посилання на складних типів або імена елементів, що входять у зміст моделі. Проблема полягає в тому, що ці цінності не розглядаються як QNames по технології, такі як DOM або SAX. Це означає, що додатки повинні відслідковувати поточний декларацій простору імен і вирішити ці QNames себе.
Додаткові джерела плутанини, див. простір імен безлад? Майкл Кей. 15,2) Чи існують які-небудь альтернативи XML простору імен? Так. Ви могли б дозволити ім'я зіткнення просто перейменування порушника типів елементів і атрибутів, а потім, в процесі обробки, використовуючи архітектурні форми, щоб перетворити їх на імена, які є пізнавана різних модулів додатка. Хоча ви, можливо, доведеться перейменувати деякі типи елементів або атрибутів, вам не доведеться змінити свій модулів додатка. Обговорення архітектурних форм виходить за рамки цієї статті. Для отримання додаткової інформації див архітектурних форм та SGML / XML архітектури на XML сторінки Робін кришки кришки. Що стосується фактичного синтаксису, використовуваного простору імен XML, ідея декларування префікси простору імен XML в інструкції обробки на початку документа XML іноді підняті. Обробка інструкції були використані в перших проектів XML специфікації простору імен і мають перевагу простоти (див. питання 4.9). Пізніше вони були замінені більш гнучкими XMLNS атрибути. Хоча ви могли б спробувати завдати удару по своїм розсудом і використовувати інструкції обробки або іншої стратегії, це, ймовірно, погана ідея, хоча і не обов'язково з технічних причин. Реальною проблемою є те, що XML простору імен вже широко використовуються і підтримуються, так що будь XML документи, які будуть виробляти нестандартні й нестерпною. 15,3) Як спірним є простору імен XML? Необхідність в XML простору імен і основна ідея про те, що з двох частин система іменування (або щось подібне) потрібно не є спірним. Тим не менш, дизайн простору імен XML - тобто, те, як XML простору імен оголошуються і використовуються в документі XML - має, часом, було дуже спірним. (Якщо ви хочете, щоб побачити, наскільки спірним, перейдіть в архіві XML-DEV розсилку, і пошук за словом «простір імен» або подивитися на деякі статті на простір імен Robin Cover сторінку в XML.) Незважаючи на ці проблеми, і те, що XML простору імен завжди буде мати деякі дуже вокальні недоброзичливці, більшість людей взяли і використовують їх. Крім того, практично у всіх комерційних XML-інструментів і технологій, підтримує їх. 16) РОЗДІЛ 16: простір імен XML РЕСУРСИ 16,1) Які ресурси доступні для вивчення простору імен XML? Рекомендації та інші офіційні кілька речей: Посилання на статті про XML простору імен: Статті про XML простору імен: Ще посилання вітаються. 16,2) Які утиліти для роботи з XML простору імен? Практично всі комерційне програмне забезпечення XML тепер підтримує простору імен XML. Нижче наведені присвячений утиліти для роботи з XML простору імен: XML Прибиральник "Утиліта командного рядка для фільтрації і перевірки XML-файлів", яка також видаляє зайві декларацій простору імен. 16) РОЗДІЛ 17: зауваження, скарги та пропозиції Якщо у вас є зауваження, скарги або пропозиції щодо нового питання, ви можете відправити їх мені (Ronald Bourret) на [email protected]. Завдяки Петтер айстри, Юрген Ауер, Адріан Бойко, Тім Брей, Дерек Денні-Браун, Боб ДюШарм, Жан-Поль Coenen, Кен Goldman, Сем Полювання, Мадхава Lakkapragada, Андрій Layman, Густав Liljegren, Крістофер Лотт, Марк Макдональд, Anders Moller Ренді Nichols, Джим Палмер, Ganesan Радхакрішнан, Arjun Ray, Арон Робертс, Уейн Стіл, Річард Тобін, Ерік Уайльд, і Diwakar Yammanuru за їх внесок.   Переведено з http://www.rpbourret.com/xml/NamespacesFAQ.htm На головну
JEWeell

Technical support by @ReuN

Contact Form | Privacy policy | Cookie policy