Простір імен в XML World Wide Web Консорціум, 14 січня 1999 року Даний документ являє собою переклад специфікації Namespaces in XML (W3C Recommendation) українською мовою. При цьому нормативним документом вважається оригінальна специфікація англійською мовою, яку можна знайти за адресою: http://www.w3.org/TR/REC-xml-names Переклад специфікації українською мовою розміщено за адресою: http://bold.com.ua/publication/content/25.html Переклад виконала Панченко Наталія, Bold Endeavours Дана версія: http://www.w3.org/TR/1999/REC-xml-names-19990114 http://www.w3.org/TR/1999/REC-xml-names-19990114/xml-names.xml http://www.w3.org/TR/1999/REC-xml-names-19990114/Overview.html Остання версія: http://www.w3.org/TR/REC-xml-names Попередня версія: http://www.w3.org/TR/1998/PR-xml-names-19981117 Редактори: Tim Bray (Textuality) mailto:tbray@textuality.com Dave Hollander (Hewlett-Packard Company) mailto:dmh@corp.hp.com Andrew Layman (Microsoft) mailto:andrewl@microsoft.com Статус даного документу Даний документ був розглянутий членами W3C, а також іншими зацікавленими сторонами і затверджений Директором в якості Рекомендації W3C. Даний документ являє собою кінцевий варіант і може використовуватись як нормативний матеріал для посилань и цитування в інших документах. Участь W3C в просуванні представленої Рекомендації зводиться до залучення до неї уваги і сприянню її широкому поширенню. Тим самим нарощуються функціональні можливості і підвищується ступінь універсальності Мережі. Резюме Простір імен XML забезпечує просту методику отримання назв для елементів і атрибутів в документах, які використовують мову розмітки, що розширюється. Це здійснюється шляхом прив'язування останніх до просторів імен, які ідентифікуються за допомогою посилань URL. Зміст 1. Причини виникнення і короткий опис   1.1. Зауваження по нотації та використанню 2. Декларування простору імен 3. Повні імена 4. Використання повних імен 5. Простір імен для елементів та атрибутів   5.1. Область дії простору імен   5.2. Простір імен за умовчанням   5.3. Унікальність атрибутів 6. Узгодженість документів Додатки І. Внутрішня структура простору імен XML (обговорення стандарту) 1. Недолік звичайного простору імен 2. Розділи простору імен XML 3. Розширені типи елементів та назви атрибутів ІІ. Подяки (обговорення стандарту) ІІІ. Посилання ІV. Словник 1. ПРИЧИНИ ВИНИКНЕННЯ І КОРОТКИЙ ОПИС Ми передбачаємо появу такого додатку для обробки розширеної мови розмітки (XML), коли в одному XML документі (звичайно називається "словник розмітки") зібрані елементи і атрибути, які обумовлені та використовуються в багатьох програмних модулях. Привід для появи такої модульності: якщо є зрозумілий словник розмітки і є програмне забезпечення, що використовує його, то простіше використовувати таку розмітку ще раз, ніж займатися винахідництвом для її нової обробки. Подібні документи, які містять декілька словників розмітки, породжують проблеми розпізнавання і колізії. Програмні модулі повинні вміти розпізнавати теги та атрибути, для обробки яких вони створені, навіть якщо і є колізії, коли стає зрозумілим, що розмітка, яка розроблена для двох різних програмних пакетів, використовує одні й ті ж типи елементів і назви атрибутів. Подібні роздуми виводять певні вимоги, щоб конструкції документа використовували універсальні імена, область дії яких виходить за рамки того документа, де вони були визначені. Дана специфікація описує механізм - простору імен XML, який дозволяє виконати цю умову. (Визначення:) Простір імен XML - це ідентифікуюча з допомогою посилання URL (RFC 2396) колекція імен, які використовуються в XML документах для визначення типів елементів та іменування атрибутів. Простір імен XML відрізняється від тих "просторів імен", які зазвичай використовуються в комп'ютерних дисциплінах тим, що у варіанті для XML воно має внутрішню структуру, і, з математичної точки зору, набором не є. Дані питання обговорюється в Додатку "І. Внутрішня структура простору імен XML (обговорення стандарту)". (Визначення:) Посилання URL, що використовуються для ідентифікації просторів імен, вважаються ідентичними, якщо вони співпадають з точністю до символу. Зауважимо, що посилання URL, які не являються ідентичними за вказаним змістом, в дійсності по функціональності можуть бути еквівалентними. Прикладом можуть стати посилання, які відрізняються тільки регістром, а також посилання в зовнішніх сутностях, які мають іншу базову адресу URL. Назви в просторі імен XML можуть бути представлені у вигляді повних імен (qualified names), які містять єдиний символ двокрапки, що ділить таке ім'я на префікс простору імен і локальну частину. За допомогою префікса, який прив'язаний до посилання URL, здійснюється вибір простору імен. Поєднання URL простору імен і власного простору імен документу, що оброблюється одноманітно, формує ідентифікатор, унікальний усюди. Даються методика визначення області видимості префікса і значення за умовчанням. Посилання URL може мати в собі символи, які є недопустимими для імен, тому саме посилання не можна використовувати в якості префікса простору імен. Таким чином, префікс простору імен служить замінювачем посилання URL. Далі описується побудований на атрибутах синтаксис, який дозволяє декларувати зв'язок префікса простору імен з посиланням URL. Програмне забезпечення, що підтримує вказаний сценарій використання імен, повинне вміти аналізувати і використовувати описані вище декларації та префікси. 1.1. Зауваження по нотації та використанню Відмітимо, що багато використовувані в сценаріях цієї специфікації нетермінальні конструкції визначаються не тут, а в специфікаціях XML[XML]. Якщо визначена тут нетермінальна конструкція має те ж саме ім'я, що було визначене для нетермінала в специфікації XML, то множина рядків, які відповідають даному сценарію тут, є лише підмножиною всіх рядків, які відповідають сценарію там. В сценаріях цього документу абревіатура NSC розшифровується як "Namespace Constraint" (обмеження на простір імен), одне з правил, якому повинні слідувати документи, що відповідають потребам даної специфікації. Відмітимо, що всі використані в прикладах назви доменів Internet (за виключенням w3.org) вибрані випадково і їх не слід сприймати за джерело інформації. 2. ДЕКЛАРУВАННЯ ПРОСТОРУ (Визначення:) Простір імен декларується за допомогою набору зарезервованих атрибутів. Назвою такого атрибуту повинно бути xmlns, або воно повинно використовуватись в якості префікса xmlns: Вказані атрибути, як і будь-які інші атрибути XML, можуть бути вказані явно, або за умовчанням.

Назва атрибутів для декларації простору імен [1] NSAttNam ::= PrefixedAttName         | DefaultAttName   [2] PrefixedAttNam ::= 'xmlns:' NCName [ NSC: Начальный "XML" ] [3] DefaultAttNam ::= 'xmlns'   [4] NCNam ::= (Letter | '_') (NCNameChar)* /* Имя XML за вычетом ":" */ [5] NCNameCha ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender

(Визначення:) Значенням атрибута для посилання URL є назва простору імен, яке використовується для його ідентифікації. Щоб назва простору імен могла служити для вказаної цілі, вона повинна мати властивості унікальності і постійності. Не ставляться завдання безпосереднього отримання по цьому імені схеми відображення (якщо така існує). Прикладом синтаксису, побудованого з подібними цілями, може служити синтаксис Uniform Resource Names [RF 2141]. Однак слід зауважити, що і звичайними адресами URL можна точно таким чином маніпулювати для досягнення тих же цілей. (Визначення:) Якщо назва атрибута відповідає сценарію PrefixedAttName, то поле NCName визначає префікс простору імен. В область видимості того елемента, в якому ця декларація була дана, вказаний префікс використовується для прив'язки імен елементів та атрибутів до назви простору імен, вказаній в значенні атрибуту, що декларується. В таких деклараціях назва простору імен пустою не може бути. (Визначення:) Якщо назва атрибуту відповідає сценарію DefaultAttName, то вказане в значенні атрибута назва простору імен в область видимості того елемента, де ця декларація була подана, стає назва простору імен за умовчанням. В декларації по умовчанню значення атрибута може бути нульовим. Простори імен за умовчанням і перевизначенням декларацій обговорюються в розділі "5. Простір імен для елементів та атрибутів". Приклад декларації, що зв'язує префікс edi з простором імен, що має назву http://ecommerce.org/schema:

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

Обмеження для простору імен: Початковий "XML" Префікси, які починаються з послідовності трьох літер x,m,l (в будь-якому регістрі), зарезервовані для використання в XML і пов'язаних з ним специфікаціях. 3. ПОВНІ НАЗВИ (Визначення:) В XML документах, які відповідають вимогам даної специфікації, частина імен (конструкцій, які відповідають нетермінальному Name) може бути представлено у вигляді повних імен (qualified names), які визначаються наступним чином: Повне ім'я

[6] QName ::= (Prefix ':')? LocalPart [7] Prefix ::= NCName [8] LocalPart ::= NCName

Поле Prefix визначає в повному імені префікс простору імен і повинне бути пов'язаним з посиланням URL в декларації простору. (Визначення:) Поле LocalPart визначає локальну частину (local part) повного імені. Зауважимо, що префікс використовується тільки для збереження назви простору імен. При побудові імен, область дії яких виходить за рамки початкового документа, додатки повинні використовувати назву простору імен, а не префікс. 4. ВИКОРИСТАННЯ ПОВНИХ ІМЕН В XML документах, які відповідають потребам даної специфікації, повні імена даються для наступних типів елементів: Типи елементів

[9] STag ::= '<' QName (S Attribute)* S? '>' [ NSC: Декларированный префикс ] [10] ETag ::= '</' QName S? '>' [ NSC: Декларированный префикс ] [11] EmptyElemTag ::= '<' QName (S Attribute)* S? '/>' [ NSC: Декларированный префикс ]

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

<x xmlns:edi='http://ecommerce.org/schema'> <!-- пространство имен элемента 'price' - http://ecommerce.org/schema --> <edi:price units='Euro'>32.18</edi:price> </x>

Атрибут або декларує простір повного імені, або його назва дається як повне ім'я: Атрибут

[12] Attribute ::= NSAttName Eq AttValue | QName Eq AttValue [ NSC: Декларированный префикс ]

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

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

Обмеження простору імен: Декларований префікс Префікс простору імен, якщо це не xml та xmlns, повинен бути об'явлений в атрибуті, який декларує простір імен і знаходиться в початковому тегі або того елемента, де цей префікс використовується, або елемента, який являється його предком (тобто знаходиться в елементі, у вмісті якого діє префіксна розмітка). Префікс xml за визначенням пов'язаний з назвою простору імен http://www.w3.org/XML/1998/namespace. Префікс xmlns використовується тільки для прив'язки до простору імен, але самостійно з якою-небудь назвою простору імен не пов'язується. Таке обмеження може призвести до труднощів у роботі, якщо атрибут, який декларує простір імен, не був представлений безпосередньо в сутності документа XML, а був декларований у зовнішній сутності як атрибут за умовчанням. Подібні декларації можуть бути недоступними для програм, які використовують неперевіряючий XML процесор. Багато XML додатків, очевидно включаючи і ті, які залежать від простору імен, не можуть використовувати перевіряючий процесор. Для того, щоб такі додатки працювали коректно, декларації просторів імен повинні даватися або безпосередньо, або через атрибути за умовчанням, об'явлені у внутрішньому наборі DTD. Якщо назва елемента або тип атрибутів з'являються в деклараціях DTD, то вони можуть бути представлені при цьому у вигляді повного імені.

Повні імена в деклараціях [13] doctypedecl ::= '<!DOCTYPE' S QName (S ExternalID)? S? ('[' (markupdecl | PEReference | S)* ']' S?)? '>' [14] elementdecl ::= '<!ELEMENT' S QName S contentspec S? '>' [15] cp ::= (QName | choice | seq) ('?' | '*' | '+')? [16] Mixed ::= '(' S? '#PCDATA' (S? '|' S? QName)* S? ')*' [17] | '(' S? '#PCDATA' S? ')' [18] AttlistDecl ::= '<!ATTLIST' S QName AttDef* S? '>' AttDef ::= S (QName | NSAttName) S AttType S DefaultDecl

5. ПРОСТІР ІМЕН ДЛЯ ЕЛЕМЕНТІВ ТА АТРИБУТІВ 5.1. Область дії простору імен Вважається, що декларація простору імен відноситься до того елементу, де вона була вказана, і всім елементам в складі цього елемента (якщо вона не була перевизначена іншою декларацією простору імен з таким же полем NSAttName):

<?xml version="1.0"?> <v!-- все элементы здесь явно соотнесены с пространством имен HTML --> <html:html xmlns:html='http://www.w3.org/TR/REC-html40'> <html:head><html:title>Frobnostication</html:title></html:head> <html:body><html:p>Moved to <html:a href='http://frob.com'>here.</html:a></html:p></html:body> </html:html>

Як показано в наступному прикладі, в атрибутах одного елемента може бути задекларовано зразу декілька префіксів простору імен:

<?xml version="1.0"?> <!-- оба префикса пространства имен доступны отовсюду --> <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>

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

<?xml version="1.0"?> <!-- в данном случае элементы по умолчанию относятся к пространству имен HTML --> <html xmlns='http://www.w3.org/TR/REC-html40'> <head><title>Frobnostication</title></head> <body><p>Moved to <here.</p></body> </html> <?xml version="1.0"?> <!-- типы элементов без префикса из "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.0"?> <!-- первоначально по умолчанию используется пространство имен "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='urn:w3-org-ns:HTML'> This is a <i>funny</i> book! </p> </notes> </book>

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

<?xml version='1.0'?> <Beers> <!-- здесь по умолчанию используется пространство имен HTML --> <table xmlns='http://www.w3.org/TR/REC-html40'> <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>

5.3. Унікальність атрибутів В документі XML, який відповідає вимогам даної специфікації, жоден тег не може мати два атрибута З однаковими іменами, або З повними іменами, локальна частина яких співпадає, а префікси прив'язані до назв простору імен, які ідентичні. Так, в наступному прикладі всі початкові теги 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>

6. УЗГОДЖЕНІСТЬ ДОКУМЕНТІВ В XML документах, які відповідають вимогам даної специфікації, назви атрибутів і типів елементів повинні відповідати сценарію OName, а також вимогам "Namespace Constraints". Документ XML відповідає вимогам даної специфікації, якщо в ньому є всі ті лексеми, які, згідно потребам XML, повинні відповідати сценарію Names, а тому теж не повинні мати в собі символу двокрапки. Однак декларований тип значень атрибутів доступний тільки для тих процесорів, які читають декларації розмітки, наприклад для перевіряючих процесорів. Таким чином, якщо не було заявлено використання перевіряючого процесора, неможливо гарантувати, що вміщене значення атрибута буде перевірено на відповідність вимогам даної специфікації. ДОДАТКИ І. ВНУТРІШНЯ СТРУКТУРА ПРОСТОРУ ІМЕН В XML (ОБГОВОРЕННЯ СТАНДАРТУ) 1. Недолік звичайного простору імен В комп'ютерних дисциплінах термін "простір імен" звичайно зіставляється з набором імен, тобто, колекцією, яка не вміщає дублікатів. Однак якби всі назви, які використовуються в розмітці XML прив'язувались до такого простору імен, то це б сильно зменшило б їх корисність. Взагалі такі назви використовуються в XML документах для того, щоб програмні модулі, такі як процесори запитів, що управляються стилями машини рендерингу і ті, що управляються схемами програми перевірки, могли розпізнавати логічні структури документа. Розглянемо наступний приклад:

<section><title>Book-Signing Event</title> <signing> <author title="Mr" name="Vikram Seth" /> <book title="A Suitable Boy" price="$22.95" /></signing> <signing> <author title="Dr" name="Oliver Sacks" /> <book title="The Island of the Color-Blind" price="$12.95" /></signing> </section>

В даному прикладі назва title з'являється в розмітці тричі, однак очевидно, що сам по собі вона дає недостатню інформацію для правильної обробки документа програмним модулем. Інша проблемна область виникає від використання "глобальних" атрибутів, що ілюструється в наступному прикладі, в якому фрагмент XML документа необхідно вивести на екран за допомогою стиля CSS:

<RESERVATION> <NAME HTML:CLASS="largeSansSerif">Layman, A</NAME> <SEAT CLASS="Y" HTML:CLASS="reallyImportant">33B</SEAT> <DEPARTURE>1997-05-24T07:55:00+1</DEPARTURE></RESERVATION>

В цьому випадку атрибут CLASS, який описує клас пасажира і приймає такі значення, як "J", "Y", та "C" на всіх рівнях симантики відрізняється від атрибута HTML: CLASS, який використовується для моделювання всього синтаксичного багатства HTML шляхом заміни обмеженого набору елементів ієрархією підкласів. Мова XML 1.0 не має вбудованого механізму декларування "глобальних" атрибутів. Такі конструкції, як атрибут CLASS в HTML, стають глобальними тільки за їх детального опису і відповідній інтерпретації зі сторони HTML додатків. Разом з тим, атрибути, головною відрізняючою рисою яких є унікальність імен, як правило, можна знайти в багатьох додатках. 2.Розділи простору імен XML Для того, щоб створення повних і неповних імен могло відповідати своєму значенню, кожне ім'я, яке з'являється в просторі імен XML, ми спів ставляємо з одним із деяких звичайних непересічних (тобто, структуруючи) просторів, які називаються розділами простору імен. Перелік цих розділів: Розділ для всіх типів елементів: - В цьому розділі опиняються всі типи елементів, які задані в просторі імен XML. Кожний тип має унікальну локальну частину, сполучення назви простору імен та локальної частини унікальним чином ідентифікує тип елемента. Розділ глобальних атрибутів: - В цьому розділі знаходяться назви всіх атрибутів, які визначені в даному просторі імен як глобальні. Єдине, що необхідно від глобального атрибуту - його ім'я повинне бути унікальним для всього розділу глобальних атрибутів. Дана специфікація не містить показань щодо порядку використання таких атрибутів. Сполучення назви простору імен і назви глобального атрибута ідентифікує глобальний атрибут унікальним чином. Розділи для кожного типу елементів: - З кожним типом в розділі всіх типів елементів пов'язано простір імен, в якому знаходяться назви неповних атрибутів елемента. Це звичайний простір імен, оскільки виникнення в одному і тому ж елементі декількох атрибутів з однаковими іменами XML 1.0 заборонено. Сполучення імені атрибута, типу елемента і назви простору імен унікальним чином ідентифікує кожний неповний атрибут. В XML документах, що відповідають вимогам даної специфікації, назви всіх повних (з префіксом) атрибутів віднесені до розділу глобальних атрибутів, тоді як назви всіх неповних атрибутів поміщаються в розділ відповідного типу елемента. 3. Розширені типи елементів та назви атрибутів Для того, щоб було простіше задавати правила і виконувати порівняння, для кожного типу елементів і назви атрибутів у XML документі ми визначаємо розширений формат, який описується тут засобами синтаксису елементів XML. (Визначення:) Розширений тип елемента представлений як пустий елемент XML типу ExpEType. Він має обов'язковий атрибут type, який визначає в цьому типі локальну частину, і необов'язковий атрибут ns, визначаючий назву простору імен, якщо даний елемент являється повним. (Визначення:) Розширене ім'я атрибута представлено як пустий елемент XML типу ExpAName. Воно має обов'язковий атрибут name, який визначає назву. Якщо атрибут є глобальним, він має обов'язковий атрибут ns, який визначає назву простору імен. В іншому випадку є обов'язковий атрибут eltype, який визначає тип задіяного елемента, а також необов'язковий атрибут elns, який визначає назву простору імен для цього елемента, якщо такий відомий. Найбільша зміна приведених раніше прикладів проілюструє роботу розширених типів елементів і назв атрибутів. Нижче подано два фрагмента, які супроводжуються таблицею, яка показує обробку імен:

<!-- 1 --> <section xmlns='urn:com:books-r-us'> <!-- 2 --> <title>Book-Signing Event</title> <!-- 3 --> <signing> <!-- 4 --> <author title="Mr" name="Vikram Seth" /> <!-- 5 --> <book title="A Suitable Boy" price="$22.95" /> </signing> </section>

Назви повинні оброблюватись наступним чином:

Рядок Ім'я Результат 1 section <ExpEType type="section" ns="urn:com:books-r-us" /> 2 title <ExpEType type="title" ns="urn:com:books-r-us" /> 3 singing <ExpEType type="signing" ns="urn:com:books-r-us" /> 4 author <ExpEType type="author" ns="urn:com:books-r-us" /> 4 title <ExpAName name='title' eltype="author" elns="urn:com:books-r-us" /> 4 name <ExpAName name='name' eltype="author" elns="urn:com:books-r-us" /> 5 book <ExpEType type="book" ns="urn:com:books-r-us" /> 5 title <ExpAName name='title' eltype="book" elns="urn:com:books-r-us" /> 5 price <ExpAName name='price' eltype="book" elns="urn:com:books-r-us" />

<!-- 1 --> <RESERVATION xmlns:HTML="http://www.w3.org/TR/REC-html40"> <!-- 2 --> <NAME HTML:CLASS="largeSansSerif">Layman, A</NAME> <!-- 3 --> <SEAT CLASS="Y" HTML:CLASS="largeMonotype">33B</SEAT> <!-- 4 --> <HTML:A HREF='/cgi-bin/ResStatus'>Check Status</HTML:A> <!-- 5 --> <DEPARTURE>1997-05-24T07:55:00+1</DEPARTURE></RESERVATION>

1 RESERVATION <ExpEType type="RESERVATION" /> 2 NAME <ExpEType type="NAME" /> 2 HTML:CLASS <ExpAName name="CLASS" ns=http://www.w3.org/TR/REC-html40 /> 3 SEAT <ExpEType type="SEAT" /> 3 CLASS <ExpAName name="CLASS" eltype="SEAT"> 3 HTML:CLASS <ExpAName name="CLASS" ns="http://www.w3.org/TR/REC-html40" /> 4 HTML:A <ExpEType type="A" ns="http://www.w3.org/TR/REC-html40" /> 4 HREF <ExpAName name="HREF" eltype="A" elns="http://www.w3.org/TR/REC-html40" /> 5 DEPARTURE <ExpEType type="DEPARTURE" />

4. Унікальність розширених імен атрибутів Обмеження, описане раніше в розділі "5.3. Унікальність атрибутів", може бути реалізоване безпосередньо у вигляді вимог, що елементу не дозволяється мати два атрибути, розширені імена яких еквівалентні, тобто мають однакову пару атрибут-значення. ІІ. ПОДЯКИ (ОБГОВОРЕННЯ СТАНДАРТУ) Даний матеріал є результатом діяльності великої кількості людей, особливо членів Робочої Групи XML з консорціуму WORLD WIDE WEB, Special Interest Group та учасників W3C Metadata Activity. Особливо цінним був вклад Чарльза Франксона (Charles Frankston) з компанії Microsoft. ІІІ. ПОСИЛАННЯ RFC2141 IETF (Internet Engineering Task Force) RFC 2141: URN Syntax, ред. R. Moats., травень 1997. RFC2396 IETF (Internet Engineering Task Force) RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, ред. T. Berners-Lee, R. Fielding, L. Masinter., серпень 1998. XML Extensible Markup Language (XML) 1.0, ред. Tim Bray, Jean Paoli и C. M. Sperberg-McQueen. 10 лютого 1998. Доступна за адресою http://www.w3.org/TR/REC-xml. ІV. СЛОВНИК При перекладі специфікації українською мовою для деяких термінів було обрано наступний варіант перекладу: conformance document - погоджений документ; документ, що відповідає вимогам специфікації document entity - сутність документа entity - сутність markup vocabulary - словник розмітки namespace - простір імен nonterminal - нетермінальна конструкція production - сценарій qualified name - повне ім'я start-tag - початковий тег validating processor - перевіряючий процесор (XML)