Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://zajtcev.org/docs/w3c/ua/xml-names11-second-edition.html below:

Простір імен в XML 1.1 (Друге видання)

Цей документ документ є не офіційним перекладом початкової англійської версії. Зверніть увагу на те, що оригінальна версія документа існує тільки англійською мовою Може містити неточності та помилки. © Зайцев Дмитро, 2011. За підтримкою сайту arc floor lamp. Коментарі до перекладу залишайте тут | | На головну

Цей розділ описує статус даного документа на час його публікації. Інші документи можуть заміняти цей документ. Зі списком поточних публікацій W3C та останньою ревізією цього технічного докладу можна ознайомитися в індексі технічних докладів W3C на http://www.w3.org/TR/.

Цей документ був підготовлений Рабочою Групою XML Core у межах діяльності W3C XML. Англійська версія цієї спеціфікації являє собою єдину нормативну версію. Тим не менш, переклади даного документу див. http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-names-11 .

Відомі реалізації описані в доповіді про реалізації Простору імен 1.1 (усі відомі реалізації Простору імен 1.1 також підтримують Простори імен 1.0) . Також доступні набори тестів на сторінці XML Test Suite .

Це друге видання включає у себе усі відомі виправлення станом на дату публікації. Воно заміняє попередню Рекомендацію W3C від 4 лютого 2004. Для зручності читачів, також надається XHTML версія з кольоровим переглядом показників.

Будь ласка, повідомте про помилки в даному документі [email protected]; за посиланням, доступні публічні архіви. Ознайомитись зі списком виправлень для цього документу можна на http://www.w3.org/XML/2006/xml-names11-errata .

Цей документ було розглянуто членами W3C, розробниками програмного забезпечення, а також іншими групами W3C та зацікавленими сторонами, та схвалений Директором у якості Рекомендації W3C. Це стабільний документ і може бути використаний у якості довідкового матеріалу або цитат в іншому документі. Роль W3C у розробці Рекомендації, полягає в залученні уваги до специфікації та сприяти її широкому поширенню. Це підвищує функціональність та сумісність у Веб(Web).

Цей документ керується 24 Січня 2002 CPP зі змінами, внесеними згідно з Перехідною Процедурою Патентної Політики. W3C підтримує публічний перелік відкритих патентів, зроблений у зв'язку з результатами діяльності групи; ця сторінка також включає в себе інструкції з розкриття патенту. Особи, що володіють актуальною інформацією про патент, який задовольняє основним вимогам повинні розкрити цю інформацію згідно до пункту 6, патентної політики W3C.

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

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

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

У тих місцях, де зустрічаються ВИДІЛЕНІ, ключові слова ПОВИНЕН, НЕ ПОВИНЕН, НЕОБХІДНО, СЛІД, НЕ СЛІД, ЙМОВІРНЕ у цьому документі повинні тлумачитися, як описано в [Ключові слова].

Зверніть увагу, що не термінальні конструкції в даній специфікації визначаються не тут, а в специфікації XML[XML]. Коли не термінальні конструкції, визначені тут, мають такі ж імена, як нетермінали визначені в специфікації XML, тоді сценарії, використані тут, у всіх випадках будуть підмножиною рядків, які відповідають сценарію там.

У сценаріях цього документа абревіатура NSC, що означає "Обмеження простору імен" ("Namespace Constraint"), це одне з правил, якому ПОВИННІ слідувати документи відповідні до цієї специфікації.

[Визначення: Простір імен XML ідентифікується посиланням IRI [RFC3987]; імена елементів та атрибутів можуть бути поміщені в простір імен XML за допомогою механізмів, описаних в цій специфікації.]

[Визначення: Розширене ім'я це пара, що складається з назви простору імен та локального ім'я.] [Визначення: Для ім'я N в просторі імен визначеному за допомогою IRI як I, Назвою простору імен буде I. Для ім'я N яка не перебуває у просторі імен, назва простору імен буде не визначено.] [Визначення: У кожному з випадків локальним ім'ям буде N.] Саме це поєднання з універсально керованих IRI простору імен з локальними іменами лексики, є ефективним у запобіганні конфліктів імен.

IRI посилання можуть містити символи не допустимі в іменах, і дуже часто занадто довгі, тому розширені імена не використовуються безпосередньо для назви елементів та атрибутів в XML-документах. Замість цього використовуються повні імена. [Визначення: Повне ім'я це ім'я суб'єкта в інтерпретації простора імен.] У документах, що відповідають цій специфікації, імена елементів та атрибутів відображаються як повні імена. Синтаксично, вони являють собою префіксні імена або безпрефіксні імена. Опис синтаксису на підставі атрибутів забезпечує зв'язок префіксів простору імен та зв'язок простору імен за замовчуванням, що застосовується до безпрефіксних імен елементів; ці описи знаходяться в області видимості елементами, на яких вони з'являються, так що різні прив'язки можуть застосовуватися в різних частинах документа. Процесори відповідні даній специфікації, ПОВИННІ розпізнати і діяти на підставі цих описів і префіксів.

Порожній рядок, хоча це й законне посилання IRI, не може бути використаний як ім'я простору імен.

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

Примітка:

Це несхвалення відносних посилань URI було прийнято на Пленарному голосуванні W3C XML (W3C XML Plenary Ballot) [несхвалення відносних посилань URI]. У ньому також заявлено, що "наступні характеристики, такі як DOM, XPath, та інші будуть визначати без розшифрування до них".

IRI посилання, ідентифікуючи простори імен, порівнюють при визначенні, ім'я на приналежність до даного простору імен та, чи відносяться два ім'я до одного й того ж простору імен. [Визначення: Два посилання IRI розглядаються як рядки, і вони вважаються ідентичними тільки в тому випадку, якщо ці рядки ідентичні, тобто, вони мають однакову послідовність символів.] Порівняння відбувається з урахуванням регістру символів, й без виконаного або виконаного %-маскування.

Наслідком цього є те, що IRI посилання, які не є ідентичними в цьому сенсі, можуть бути віднесені до одного і того ж ресурсу. Приклади включають в себе посилання IRI, які відрізняються тільки регістром, %-маскуванням або коли посилання існують в зовнішніх об'єктах, які мають різні базові URI (але майте на увазі, що відносні IRI є застарілими, як назви простору імен).

У декларації простору імен, посилання IRI є нормованим значенням атрибуту, тому заміна символу XML й посилання на об'єкти були вже зроблені раніше, перед всіма порівняннями.

Приклади:

Посилання IRI, подані нижче, всі різні для ідентифікації просторів імен, оскільки вони відрізняються регістром:

• http://www.example.org/wine

• http://www.Example.org/wine

• http://www.example.org/Wine

IRI посилання, представлені нижче, також всі різні для ідентифікації просторів імен:

• http://www.example.org/rosé

• http://www.example.org/ros%c3%a9

• http://www.example.org/ros%c3%A9

• http://www.example.org/ros%C3%a9

• http://www.example.org/ros%C3%A9

Як і цей приклад:

• http://www.example.org/~wilbur

• http://www.example.org/%7ewilbur

• http://www.example.org/%7Ewilbur

Якщо об'єкт з ім'ям eacute був визначений як é, то нижче, при оголошенні просторів імен, початок міток містять обов'язковий префікс p на теж саме посилання IRI, http://example.org/rosé.

• <p:foo xmlns:p="http://example.org/rosé">

• <p:foo xmlns:p="http://example.org/ros&#xe9;">

• <p:foo xmlns:p="http://example.org/ros&#xE9;">

• <p:foo xmlns:p="http://example.org/ros&#233;">

• <p:foo xmlns:p="http://example.org/ros&eacute;">

Через ризик плутанини між IRI, які будуть еквівалентні при разіменуванні, використання %-маскованих символів в іменах простору імен настійно не рекомендується.

[Визначення: Простір імен (або якщо точніше, обов'язковий простір імен) оголошується за допомогою сімейства зарезервованих атрибутів. Таке ім'я атрибута повинно бути або xmlns або початися з xmlns:. Ці атрибути, як і будь-які інші XML-атрибути, можуть бути представлені безпосередньо або бути за замовчуванням.]

Нормалізоване значення атрибуту ПОВИННО бути або посиланням IRI — назва простору імен визначає простір імен — або пустим рядком. Щоб ім'я простору імен, слугувало за прямим своїм призначенням, йому СЛІД мати характеристики унікальності та постійності. Це не основна мета, яка буде безпосередньо використовуватися для пошуку схеми (якщо така існує). Uniform Resource Names [RFC2141] є прикладом синтаксису, який розроблено з урахуванням цих цілей. Однак слід зазначити, що звичайними URL-адресами можна управляти таким чином, щоб досягти цих же цілей.

[Визначення: Якщо ім'я атрибута відповідає PrefixedAttName, в такому випадку, NCName дає префікс простору імен, який використовується для зв'язування імен елементів та атрибутів з вказаним в значенні атрибуту ім'ям простору імен в межах елементу, де ця декларація була подана.]

[Визначення: Якщо ім'я атрибута відповідає DefaultAttName, в такому випадку, вказане у значенні атрибуту назва простору імен в області видимості елемента, де ця декларація була подана, стає простором імен за замовчуванням.] Простори імен за замовчуванням і перевизначення декларацій обговорюються в 6 Застосування простору імен до елементів та атрибутів.

Приклад декларації простору імен, який пов'язує префікс простору імен edi з назвою простору імен http://ecommerce.example.org/schema:

<x xmlns:edi='http://ecommerce.example.org/schema'>
  <!-- "edi" префікс зв'язан з http://ecommerce.example.org/schema
       для елементу "x" та його вмісту -->
</x>

Обмеження для простору імен: Захищені префікси і назви просторів імен

Префікс xml, за визначенням, пов'язаний з назвою простору імен http://www.w3.org/XML/1998/namespace. Він МОЖЕ, але в цьому немає потреби, бути оголошеним, та НЕ ПОВИНЕН бути скасований або пов'язаний з будь-якою іншою назвою простору імен. Інші префікси НЕ ПОВИННІ бути пов'язані з цією назвою простору імен, та він НЕ ПОВИНЕН бути декларований як простір імен за замовчуванням.

Префікс xmlns служить тільки оголошення зв'язку з простором імен та, за визначенням, пов'язаний з назвою простору імен http://www.w3.org/2000/xmlns/. Він НЕ ПОВИНЕН бути оголошений або не оголошений. Інші префікси НЕ ПОВИННІ бути пов'язані з цією назвою простору імен, і він НЕ ПОВИНЕН бути оголошений як простір імен за умовчанням. Імена елементів НЕ ПОВИННІ мати префікс xmlns.

Всі інші префікси, що починаються з трьох букв x, m, l, в будь-яких комбінаціях регістру, зарезервовані. Це означає, що:

• користувачам НЕ СЛІД використовувати їх, за винятком, випадків визначених у наступних специфікаціях

• процесори НЕ ПОВИННІ розглядати їх як фатальні помилки.

Хоча самі вони не зарезервовані, недоцільно використовувати імена префіксів, локальна частина(LocalPart) яких починаються з букв x, m, l, в будь-яких комбінаціях регістру, оскільки ці імена будуть зарезервовані, якщо використовувати їх без префікса.

У документах XML відповідних до даної специфікації, деякі імена (конструкції, які відповідають нетермінальному Name) ПОВИННІ бути передані як повні імена, які визначаються наступним чином:

Поле Prefix визначає з частини повного ім'я префікс простору імен, та ПОВИНЕН бути пов'язаний з посиланням IRI зазначеної в декларації простору імен. [Визначення: Поле LocalPart визначає локальну частину повного ім'я.]

Відзначте, що префікс використовується тільки для збереження назви простору імен. Програмам СЛІД використовувати тільки назву простору імен, а не префікс, при побудові імен, область дії яких виходить за межі первісного документа.

У документах XML відповідних до даної специфікації, імена елементів вказані як повні імена, а саме:

Приклад використання повного ім'я, що виступає в якості імені елементу:

  <!-- простір імен елементу 'price' є http://ecommerce.example.org/schema -->
  <edi:price xmlns:edi='http://ecommerce.example.org/schema' units='Euro'>32.18</edi:price>

Атрибути або декларують простори імен або їх імена зазначені як повні імена:

Приклад використання повного ім'я, в якості ім'я атрибута:

<x xmlns:edi='http://ecommerce.example.org/schema'>
  <!-- простір імен атрибуту 'taxClass' - http://ecommerce.example.org/schema -->
  <lineItem edi:taxClass="exempt">Baby food</lineItem>
</x>

Обмеження простору імен: Декларований Префікс

Префікс простору імен, за винятком xml або xmlns, ПОВИНЕН бути оголошений в атрибуті, який декларує простір імен, в будь-якому початковому тегу елементу, де використовується префікс або в той елемент, який є його предком (тобто елемент, в змісті якого діє префіксна розмітка). Крім того, всередині такої декларації, значення атрибуту НЕ ПОВИННО бути порожнім рядком.

Це обмеження може призвести до експлуатаційних труднощів, коли атрибут, який декларує простір імен, не був представлений безпосередньо в сутності документа XML, але був декларований у зовнішній сутності за допомогою атрибуту за замовчуванням. Такі декларації не можуть бути прочитані програмним забезпеченням заснованому на неперевіряючому процесорі XML. Багато інших програм XML, ймовірно включаючи і ті, які залежать від простору імен, не можуть використовувати перевіряючи процесори. Якщо потрібно правильність роботи з такими програмами, декларації просторів імен ПОВИННІ бути представлені або безпосередньо або за допомогою атрибутів за умовчанням, які декларовані у внутрішній підмножині DTD.

Імена елементів та імена атрибутів, також наводяться як повні імена, коли вони з'являються в деклараціях у DTD:

Зверніть увагу, що перевірка, яка заснована на DTD це незнайомий простір імен в наступному сенсі: DTD обмежує елементи та атрибути, які можуть з'явитися в документі за їх не інтерпретованими іменами, а не за (назва простору імен, локальне ім'я) парами. Щоб перевірити документ, який використовує простори імен у відношенні DTD необхідно, щоб префікси, використані в DTD, були такі ж, як і в документі. Однак DTD може опосередковано обмежувати простори імен, що використовуються в валідному документі, шляхом надання #FIXED значень для атрибутів, які декларують простори імен.

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

Така декларація простору імен поширюється на всі імена елементів та атрибутів у своїй області дій, чиї префікси відповідають тому, який зазначений у декларації.

Розширене ім'я яке відповідає префіксному елементу або імені атрибута має посилання IRI, в якій префікс пов'язан, як його назва простору імен, а локальна частина, як його локальне ім'я.

<?xml version="1.1"?>

<html:html xmlns:html='http://www.w3.org/1999/xhtml'>

  <html:head><html:title>Frobnostication</html:title></html:head>
  <html:body><html:p>Moved to 
    <html:a href='http://frob.example.com'>here.</html:a></html:p></html:body>
</html:html>

Декілька префіксів в просторі імен можуть бути оголошені, як атрибути одного елемента, приклад:

<?xml version="1.1"?>
<!-- обидва префікса простору імен доступні звідусіль -->
<bk:book xmlns:bk='urn:loc.gov:books'
         xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <bk:title>Cheaper by the Dozen</bk:title>
    <isbn:number>1568491379</isbn:number>
</bk:book>

Значення префікса в декларації простору імен для префікса МОЖЕ бути порожнім. Це ефективно, в рамках декларації, при усуненні будь-яких асоціацій префікса з ім'ям простору імен. Подальші декларації МОЖУТЬ повторно оголосити префікс знову:

<?xml version="1.1"?>
<x xmlns:n1="http://www.w3.org">
    <n1:a/>               <!-- вірно, префікс n1 пов'язаний з http://www.w3.org -->
    <x xmlns:n1="">
        <n1:a/>           <!-- невірно, префікс n1, тут, ні з чим не пов'язаний -->
	<x xmlns:n1="http://www.w3.org">
            <n1:a/>       <!-- вірно, префікс n1 знову визначений -->
        </x>
    </x>
</x>

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

Декларація простору імен за замовчуванням відноситься до всіх імен елементів без префікса в межах своєї області. Декларації просторів імен за замовчуванням не відносяться безпосередньо до імен атрибутів; інтерпретації атрибутів без префікса визначаються елементом, в якому вони виникають.

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

<?xml version="1.1"?>
<!-- елементи в просторі імен HTML, в цьому випадку за замовчуванням -->
<html xmlns='http://www.w3.org/1999/xhtml'>
  <head><title>Frobnostication</title></head>
  <body><p>Moved to 
    <a href='http://frob.example.com'>here</a>.</p></body>
</html>

<?xml version="1.1"?>
<!-- типи елемента без префікса з простору імен "books" -->
<book xmlns='urn:loc.gov:books'
      xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <title>Cheaper by the Dozen</title>
    <isbn:number>1568491379</isbn:number>
</book>

Розширений приклад, який показує область дій простору імен:

<?xml version="1.1"?>
<!-- початковим простором імен за замовчуванням, є "books" -->
<book xmlns='urn:loc.gov:books'
      xmlns:isbn='urn:ISBN:0-395-36341-6'>
    <title>Cheaper by the Dozen</title>
    <isbn:number>1568491379</isbn:number>
    <notes>
      <!-- для деяких коментарів, зробимо простір імен HTML, за замовчуванням -->
      <p xmlns='http://www.w3.org/1999/xhtml'>
          This is a <i>funny</i> book!
      </p>
    </notes>
</book>

Значення атрибуту в декларації простору імен за замовчуванням МОЖЕ бути порожнім. Це буде мати такий самий ефект, як ніби в межах дії цієї декларації, простору імен за замовчуванням, взагалі не було задекларовано.

<?xml version='1.1'?>
<Beers>
  <!-- всередині таблиць, за замовчуванням простором імен використовується HTML -->
  <table xmlns='http://www.w3.org/1999/xhtml'>
   <th><td>Name</td><td>Origin</td><td>Description</td></th>
   <tr> 
     <!-- всередині елементів таблиці немає простору імен, який використовується за замовчуванням -->
     <td><brandName xmlns="">Huntsman</brandName></td>
     <td><origin xmlns="">Bath, UK</origin></td>
     <td>
       <details xmlns=""><class>Bitter</class><hop>Fuggles</hop>
         <pro>Wonderful hop, light alcohol, good summer beer</pro>
         <con>Fragile; excessive variance pub to pub</con>
         </details>
        </td>
      </tr>
    </table>
  </Beers>

У документах XML відповідних до даної специфікації, немає тега, що містить два атрибути, які:

1. мають однакові імена, або

2. мають повні імена з однаковою локальною частиною та з префіксами пов'язаними с іменами простору імен, які ідентичні.

Це обмеження рівнозначно тому, що немає елемента який має два атрибути з однаковим розширеним ім'ям.

Наприклад, кожен з bad тегів порожнього елементу невірний, в наступних тегах:

<!-- http://www.w3.org пов'язано з n1 та n2 -->
<x xmlns:n1="http://www.w3.org" 
   xmlns:n2="http://www.w3.org" >
  <bad a="1"     a="2" />
  <bad n1:a="1"  n2:a="2" />
</x>

Однак, кожен з наступних тегів вірний, тому що простір імен за замовчуванням, не поширюється на імена атрибутів:

<!-- http://www.w3.org пов'язано з n1 та є простором за замовчуванням -->
<x xmlns:n1="http://www.w3.org" 
   xmlns="http://www.w3.org" >
  <good a="1"     b="2" />
  <good a="1"     n1:a="2" />
</x>

Ця специфікація відноситься до документів XML 1.1. Щоб відповідати даній специфікації, документ ПОВИНЕН бути правильно сформований у відповідності зі специфікацією XML 1.1 [XML 1.1].

У XML-документах, які відповідають цій специфікації, імена елементів та атрибутів ПОВИННІ відповідати конструкції для QName та ПОВИННІ задовольняти "обмеженням простору імен ". Щоб відповідати конструкції XML для Name (Імені), всі інші лексеми у документі, які НЕОБХІДНІ для забезпечення коректності XML 1.1, ПОВИННІ відповідати конструкції цієї специфікації для NCName.

[Визначення: Документ стає коректно сформованим, по відношенню до простору імен, якщо він відповідає даній специфікації.]

З цього випливає, що в коректно сформованому, по відношенню до простору імен, документі:

• Всі імена елементів та атрибутів містять у собі одну двокрапку, або не містять її взагалі;

• Імена сутностей, інструкції з обробки цілей або імена позначень, не містять жодної двокрапки.

Окрім того, коректно сформованим, по відношенню до простору імен, документ також може бути валідним.

[Визначення: коректно сформований, по відношенню до простору імен, документ буде валідним, якщо він діє у відповідності з XML 1.1 специфікацією і всі лексеми, за винятком, імен елементів та атрибутів, які НЕОБХІДНІ для валідності XML 1.1, відповідно до конструкції XML для Name (Імені) відповідають конструкції цієї специфікації для NCName.]

З цього випливає, що у валідному, по відношенню до простору імен, документі:

• Жоден атрибут з оголошеними типами ID, IDREF(S), ENTITY(IES), або NOTATION не містить двокрапок.

Щоб відповідати даній специфікації, процесор ПОВИНЕН повідомляти про порушення в коректно-сформованому просторі імен, за винятком, коли немає НЕОБХІДНОСТІ перевіряти, що назви простору імен є легальними посиланнями IRI.

[Визначення: Процесор перевірки коректності XML, який відповідає цій специфікації, є перевіркою коректності простору імен, якщо, крім того, він повідомляє про порушення коректності простору імен. ]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3