REC-xml-names-19990114 |
Данный документ представляет собой перевод спецификации Namespaces in XML (W3C Recommendation) на русский язык. При этом нормативным документом
считается оригинальная спецификация на английском языке, которую можно найти по адресу
Представленный документ может содержать ошибки перевода. |
Copyright © 1999 W3C (MIT, INRIA, Keio ). Все права защищены. В отношении данного документа действуют правила W3C, касающиеся ответственности, торговой марки, использования документа и лицензирования программного обеспечения.
Данный документ был рассмотрен членами W3C, другими заинтересованными сторонами и утвержден Директором в качестве Рекомендации W3C. Данный документ является окончательным и может использоваться как нормативный материал для ссылки и цитирования в других документах. Участие W3C в продвижении представленной Рекомендации заключается в привлечении к ней внимания и способствовании ее широкому распространению. Тем самым наращиваются функциональные возможности и повышается степень универсальности Сети.
Перечень ошибок, обнаруженных в данной спецификации, представлен на странице http://www.w3.org/XML/xml-names-19990114-errata.
Об ошибках, обнаруженных в данном документе, просьба сообщать по адресу xml-names-editor@w3.org.
Пространство имен XML обеспечивает простую методику получения названий для элементов и атрибутов в документах, использующих расширяемый язык разметки. Осуществляется это путем привязки последних к пространствам имен, идентифицируемым с помощью ссылок URI.
D. Словарь |
Мы предвидим появление таких приложений для обработки расширенного языка разметки (XML), когда в одном XML документе (обычно называемом "словарем разметки") собраны элементы и атрибуты, определяемые и используемые во многих программных модулях. Повод для появления такой модульности: если имеется понятный словарь разметки и есть использующее его программное обеспечение, то проще использовать такую разметку еще раз, чем изобретать ее заново.
Подобные документы, содержащие несколько словарей разметки, порождают проблемы распознания и коллизии. Программные модули должны уметь распознавать тэги и атрибуты, для обработки которых они созданы, даже если имеют место "коллизии", когда выясняется, что разметка, разработанная для двух различных программных пакетов, использует одни и те же типы элементов и названия атрибутов.
Подобные соображения выдвигают требование, чтобы конструкции документа использовали универсальные имена, область действия которых выходит за рамки того документа, где они были определены. Данная спецификация описывает механизм - пространства имен XML - позволяющий выполнить это условие.
[Определение:] Пространство имен XML - это идентифицируемая с помощью ссылки URI [RFC2396] коллекция имен, используемых в XML документах для обозначения типов элементов и именования атрибутов. Пространство имен XML отличается от тех "пространств имен", которые обычно используются в компьютерных дисциплинах, тем, что в варианте для XML оно имеет внутреннюю структуру, и, с математической точки зрения, набором не является. Данные вопросы обсуждаются в Приложении "A. Внутренняя структура пространства имен XML".
[Определение:] Используемые для идентификации пространств имен ссылки URI считаются идентичными, если они совпадают с точностью до символа. Заметим, что ссылки URI, не являющиеся идентичными в указанном смысле, в действительности по функциональности могут быть эквивалентны. Примером могут служить ссылки, отличающиеся только регистром, а также ссылки во внешних сущностях, имеющие иной базовый адрес URI.
Названия в пространстве имен XML могут быть представлены в виде полных имен (qualified names), содержащих единственный символ двоеточия, делящий такое имя на префикс пространства имен и локальную часть. С помощью префикса, привязанного к ссылке URI, осуществляется выбор пространства имен. Сочетание единообразно обрабатываемого URI пространства имен и собственного пространства имен документа формирует идентификатор, уникальный повсюду. Дается методика определения области видимости префикса и значения по умолчанию.
Ссылка URI может содержать символы, недопустимые для имен, поэтому саму ссылку нельзя использовать в качестве префикса пространства имен. Таким образом, префикс пространства имен служит заменителем ссылки URI. Далее описывается построенный на атрибутах синтаксис, позволяющий декларировать связь префикса пространства имен со ссылкой URI. Программное обеспечение, поддерживающее указанный сценарий использования пространства имен, должно уметь анализировать и использовать описанные декларации и префиксы.
Отметим, что многие используемые в сценариях этой спецификации нетерминальные конструкции определяются не здесь, а в спецификации XML [XML]. Если определенная здесь нетерминальная конструкция имеет то же самое имя, что было определено для нетерминала в спецификации XML, то множество строк, соответствующих сценарию здесь, является лишь подмножеством всех строк, соответствующих сценарию там.
В сценариях этого документа аббревиатура NSC
расшифровывается как "Namespace Constraint" (ограничение на пространство имен), одно из правил, которому должны следовать документы, отвечающие требованиям данной спецификации.
Заметим, что все использованные в примерах названия доменов Internet (за исключением w3.org
) выбраны случайным образом и их не следует принимать за источник информации.
[Определение:] Пространство имен декларируется с помощью набора зарезервированных атрибутов. Названием такого атрибута должно быть xmlns
, либо оно должно использовать в качестве префикса xmlns:
. Указанные атрибуты, как и любые другие атрибуты в XML, могут быть указаны явно, либо быть назначены по умолчанию.
Названия атрибутов для декларации пространства имен | ||||||||||||||||||||||||||||
|
[Определение:] Значением атрибута для ссылки URI является название пространства имен, используемое для его идентифицикации. Чтобы название пространства имен могло служить указанной цели, оно должно обладать свойствами уникальности и постоянства. Не ставится задачи непосредственного получения по этому имени схемы отображения (если таковая существует). Примером синтаксиса, построенного с подобными целями, может служить синтаксис Uniform Resource Names [RFC2141]. Однако следует заметить, что и обычными адресами URL можно точно так же манипулировать для достижения тех же самых целей.
[Определение:] Если название атрибута соответствует сценарию PrefixedAttName
, то поле NCName
определяет префикс пространства имен. В область видимости того элемента, в котором эта декларация была дана, указанный префикс используется для привязки имен элементов и атрибутов к названию пространства имен, указанному в значении декларирующего атрибута. В таких декларациях название пространства имен пустым быть не может.
[Определение:] Если название атрибута соответствует сценарию DefaultAttName
, то указанное в значении атрибута название пространства имен в область видимости того элемента, где эта декларация была дана, становится названием пространства имен по умолчанию. В декларации по умолчанию значение атрибута может быть нулевым. Пространства имен по умолчанию и переопределение деклараций обсуждаются в главе "5. Пространство имен для элементов и атрибутов".
Пример декларации, связывающей префикс edi
с пространством имен, имеющим название http://ecommerce.org/schema
:
<x xmlns:edi='http://ecommerce.org/schema'> |
Ограничение для пространства имен: Начальный "XML"
Префиксы, начинающиеся с последовательности из трех букв x
, m
, l
(в любом регистре), зарезервированы для использования в XML и связанных с ним спецификациях.
[Определение:]
В XML документах, отвечающих требованиям данной спецификации, часть имен (конструкций, соответствующих нетерминальному Name
) может быть представлено в виде полных имен (qualified names), определяемых следующим образом:
Полное имя | ||||||||||||
|
Поле Prefix
определяет в полном имени префикс пространства имен и должно быть связано со ссылкой URI в декларации пространства имен. [Определение:] Поле LocalPart
определяет локальную часть (local part) полного имени.
Заметим, что префикс используется только для хранения названия пространства имен. При построении имен, область действия которых выходит за пределы первоначального документа, приложения должны использовать название пространства имен, а не префикс.
В XML документах, отвечающих требованиям данной спецификации, полные имена даются для следующих типов элементов:
Типы элементов | ||||||||||||||||||
|
Пример использования полного имени в качестве типа элемента:
<x xmlns:edi='http://ecommerce.org/schema'> |
Атрибут либо декларирует пространство имен, либо его название дается как полное имя:
Атрибут | ||||||||||
|
Пример использования полного имени в качестве названия атрибута:
<x xmlns:edi='http://ecommerce.org/schema'> |
Ограничение пространства имен: Декларированный префикс
Префикс пространства имен, если это ни xml
и ни xmlns
, должен быть объявлен в атрибуте, декларирующем пространство имен и находящемся в начальном тэге либо того элемента, где этот префикс используется, либо элемента, являющегося его предком (то есть, находиться в элементе, в содержимом которого действует префиксная разметка). Префикс xml
по определению связан с названием пространства имен http://www.w3.org/XML/1998/namespace
. Префикс xmlns
используется только для привязки к пространству имен, но сам с каким-либо названием пространства имен не связан.
Такое ограничение может привести к трудностям в работе, если атрибут, декларирующий пространство имен, не был представлен непосредственно в сущности документа XML, а был декларирован во внешней сущности как атрибут по умолчанию. Подобные декларации могут быть недоступны для программ, использующих непроверяющий XML процессор. Многие XML приложения, очевидно включая и те, которые зависят от пространства имен, не могут использовать проверяющий процессор. Для того, чтобы такие приложения работали корректно, декларации пространств имен должны даваться либо непосредственно, либо через атрибуты по умолчанию, объявленные во внутреннем наборе DTD.
Если название элемента или тип атрибутов появляются в декларациях DTD, они могут быть представлены при этом в виде полного имени.
Полные имена в декларациях | ||||||||||||||||||||||||||||
|
Считается, что декларация пространства имен относится к тому элементу, где она была указана, и всем элементам в содержимом этого элемента (если она не была переопределена другой декларацией пространства имен с таким же полем NSAttName
):
<?xml version="1.0"?> |
Как показано в следующем примере, в атрибутах одного элемента может быть декларировано сразу несколько префиксов пространства имен:
<?xml version="1.0"?> |
Считается, задаваемое по умолчанию пространство имен относится к тому элементу, где оно декларировано (если этот элемент не имеет префикса пространства имен), а также ко всем элементам в содержимом этого элемента, не имеющим префикса. Если поле ссылки URI в декларации пространства имен по умолчанию оказалось пустым, считается, что все элементы без префиксов в области видимости этой декларации вообще не принадлежат ни одному пространству имен. Заметим, что пространства имен, задаваемые по умолчанию, непосредственно на атрибуты не распространяются.
<?xml version="1.0"?> |
<?xml version="1.0"?> |
Более развернутый пример, показывающий область действия пространства имен:
<?xml version="1.0"?> |
Пространство имен по умолчанию может быть задано пустой строкой. Это будет иметь тот же самый эффект, словно в пределах видимости этой декларации пространства имен, используемого по умолчанию, вообще не было декларировано.
<?xml version='1.0'?> |
В документе XML, отвечающем требованиям данной спецификации, ни один тэг не может иметь два атрибута
Так, в следующем примере все начальные тэги bad
неправильные:
<!-- http://www.w3.org связано с n1 и n2 --> |
Однако в другом примере все тэги правильны (во втором случае потому, что пространство имен по умолчанию не относится к названиям атрибутов):
<!-- по умолчанию http://www.w3.org связано с n1 --> |
В XML документах, отвечающих требованиям данной спецификации, названия атрибутов и типов элементов должны соответствовать сценарию QName
и отвечать требованиям "Namespace Constraints".
Документ XML соответствует требованиям данной спецификации, если в нем все те лексемы, которые, согласно требованиям XML, должны отвечать сценарию Name
из XML, в действительности соответствуют сценарию NCName
из этой спецификации.
Для документа согласованность дает следующее:
Строго говоря, значения атрибутов, декларируемые для типов ID
, IDREF(S)
, ENTITY(IES)
и NOTATION
, также относятся к сценарию Names
, а потому тоже не должны содержать символа двоеточия. Однако декларированный тип значений атрибутов доступен только для тех процессоров, которые читают декларации разметки, например для проверяющих процессоров. Таким образом, если не было заявлено использование проверяющего процессора, нельзя гарантировать, что содержимое значения атрибута будет проверено на соответствие требованиям данной спецификации.
В компьютерных дисциплинах термин "пространство имен" обычно сопоставлется с набором имен, то есть, коллекцией, не содержащей дубликатов. Однако, если бы названия, используемые в разметке XML, привязывались к такому пространству имен, это сильно уменьшило бы их полезность. В основном такие названия используются в XML документах для того, чтобы программные модули, такие как процессоры запросов, управляемые стилями машины рендеринга и управляемые схемами программы проверки, могли распознавать логические структуры документа. Рассмотрим следующий пример:
<section><title>Book-Signing Event</title> |
В данном примере название title
появляется в разметке три раза, однако очевидно, что само по себе оно дает недостаточно информации для правильной обработки документа программным модулем.
Другая проблемная область происходит от использования "глобальных" атрибутов, что иллюстрируется следующим примером, в котором фрагмент XML документа необходимо вывести на экран с помощью стиля CSS:
<RESERVATION> |
В этом случае атрибут CLASS
, описывающий класс пассажира и принимающий такие значения, как "J", "Y" и "C", на всех уровнях семантики отличается от атрибута HTML:CLASS
, который используется для моделирования всего синтаксического богатства HTML путем замены ограниченного набора элементов иерархией подклассов.
Язык XML 1.0 не имеет встроенного механизма декларирования "глобальных" атрибутов. Такие конструкции, как атрибут CLASS
в HTML, становятся глобальными только при их тщательном описании и соответствующей интерпретации со стороны HTML приложений. Вместе с тем, атрибуты, главной отличительной чертой которых является уникальность имен, как правило, можно найти во многих приложениях.
Для того, чтобы создание полных и неполных имен могло соответствовать своему назначению, каждое имя, появляющееся в пространстве имен XML, мы сопоставляем с одним из нескольких обычных непересекающихся (то есть, структурирующих) пространств, называемых разделами пространства имен. Перечень этих разделов:
В XML документах, отвечающих требованиям данной спецификации, названия всех полных (с префиксом) атрибутов относены к разделу глобальных атрибутов, тогда как названия всех неполных атрибутов помещаются в раздел соответствующего типа элемента.
Чтобы было проще задавать правила и выполнять сравнение, для каждого типа элементов и названия атрибутов в XML документе мы определяем расширенный формат, описываемый здесь средствами синтаксиса элементов XML.
[Определение:] Расширенный тип элемента представлен как пустой элемент XML типа ExpEType
. Он имеет обязательный атрибут type
, определяющий в этом типе локальную часть
, и необязательный атрибут ns
, определяющий название пространства имен, если данный элемент является полным.
[Определение:] Расширенное имя атрибута представлено как пустой элемент XML типа ExpAName
. Оно имеет обязательный атрибут name
, определяющий название. Если атрибут является глобальным, он имеет обязательный атрибут ns
, определяющий название пространства имен. В противном случае имеется обязательный атрибут eltype
, определяющий тип задействованного элемента, а также необязательный атрибут elns
, определяющий название пространства имен для этого элемента, если таковое известно.
Небольшое изменение приведенных ранее примеров проиллюстрирует работу расширенных типов элементов и названий атрибутов. Ниже представлены два фрагмента, сопровождаемые таблицей, показывающей обработку имен:
<!-- 1 --> <section xmlns='urn:com:books-r-us'> |
Названия должны обрабатываться следующим образом:
Строка | Имя | Результат |
1 | section | <ExpEType type="section" ns="urn:com:books-r-us" /> |
2 | title | <ExpEType type="title" ns="urn:com:books-r-us" /> |
3 | signing | <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"> |
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" /> |
Ограничение, описанное ранее в главе "5.3 Уникальность атрибутов", может быть реализовано непосредственно в виде требования, что элементу не разрешается иметь два атрибута, расширенные имена которых эквивалентны, то есть имеют одинаковую пару атрибут-значение.
Данный материал является результатом деятельности большого количества людей, особенно членов Рабочей Группы XML из консорциума World Wide Web, Special Interest Group и участников W3C Metadata Activity. Особенно был ценен вклад Чарльза Франксона (Charles Frankston) из компании Microsoft.
D. СловарьПри переводе спецификации на русский язык для ряда терминов был выбран следующий вариант перевода:
conformance document - согласованный документ; документ, отвечающий требованиям спецификации |
Если у вас возникли какое-либо замечания, мы будем рады их получить по адресу radik_u@mail.ru.