Читать онлайн «Технология XSLT». Страница 8

<aaa:element

 xmlns:aaa="http://www.ааа.com"

 xmlns:bbb="http://www.bbb.com"

 xmlns:ccc="http://www.ccc.com">

 <aaa:anotherelement/>

 <ccc:element/>

 <bbb:anotherelement/>

 ...

</aaa:element>

Весьма удобной является возможность использования пространства имен по умолчанию. Определение пространства имен в виде

<элемент xmlns="URI">

 ...

</элемент>

позволяет опускать префиксы в именах элементов.

Документ в предыдущем примере может быть переписан следующим образом:

<element xmlns="http://www.aaa.com">

 <anotherelement/>

 <ссс:element xmlns:ccc="http://www.ccc.com"/>

 <anotherelement xmlns="http://www.bbb.com"/>

 ...

</element>

Обратим внимание, что пространство имен по умолчанию может быть изменено повторным использованием атрибута xmlns в дочерних элементах.

Документ

<element xmlns="http://www.ааа.com">

 <element/>

 <element xmlns="http://www.bbb.com">

  <element/>

  <element xmlns="http://www.ccc.com"/>

 </element>

</element>

эквивалентен документу

<aaa:element

 xmlns:aaa="http://www.aaa.com"

 xmlns:bbb="http://www.bbb.com"

 xmlns:ccc="http://www.ccc.com">

 <aaa:element/>

 <bbb:element>

  <bbb:element/>

  <ccc:element/>

 </bbb:element>

</aaa:element>

Таким образом, пространства имен — это механизм выделения в тексте XML-документа элементов и атрибутов, принадлежащих различным логическим схемам документов. Более того, термин "пространство имен" часто используется как эквивалент логической схеме документа, например, когда говорят "элемент template принадлежит пространству имен XSLT", подразумевается, что элемент template определен в языке XSLT и описывается в соответствующей схеме.

Синтаксические правила, которые описывают определения пространств имен, задаются не в спецификации XML, а в другом документе — в технической рекомендации "Namespaces in XML" (пространства имен в XML), которая доступна по адресу http://www.w3.org/TR/REC-xml-names. Для того чтобы отличать эти продукции от продукций языка XML, мы будет давать им номера вида [NS1], [NS2] и так далее.

Продукция NSAttName описывает имена атрибутов, декларирующих пространства имен:

[NS1] NSAttName       ::= PrefixedAttName | DefaultAttName

[NS2] PrefixedAttName ::= 'xmlns:' NCName

[NS3] DefaultAttName  ::= 'xmlns'

Имя NCName, которое использовалось в правиле PrefixedAttName, — это имя префикса, который будет использоваться для обозначения принадлежности элементов определенному пространству имен. Это имя отличается от имен, которые отвечают продукции Name тем, что оно не может содержать двоеточия:

[NS4] NCName     ::= (Letter | '_') (NCNameChar)*

[NS5] NCNameChar ::= Letter | Digit | '.' | '-' | '_'

                     | CombiningChar | Extender

Использование пространств имен значительно изменяет понятие имени. Действительно, если www:template, xsl:template или просто template могут быть одинаковыми именами, то именем в таком случае должна считаться не просто символьная последовательность, которая его составляет, а нечто большее.

Вследствие этого в спецификациях группы XML-языков вводится такое понятие, как расширенное имя, которое состоит из двух частей: локальной части и идентификатора пространства имен, которое соответствует префиксу имени.

Представим себе элемент вида

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"/>

Расширенное имя этого элемента будет состоять из локальной, части stylesheet и идентификатора пространств имен http://www.w3.org/1999/XSL/Transform.

Расширенные имена считаются совпадающими, если их локальные части равны и, при этом, они относятся к одному пространству имен.

Префикс в расширенном имени может быть опущен. В таком случае идентификатор пространства имен будет либо выбран по умолчанию (если имеется соответствующее объявление), либо будет нулевым.

Для описания имен элементов и атрибутов, которые должны иметь расширенное представление, используется продукция QName:

[NS6] QName ::= (Prefix ':')? LocalPart

Нетерминалу Prefix соответствует префикс имени, который может быть опущен вместе со следующим за ним разделяющим двоеточием, LocalPart соответствует локальной части имени.

[NS7] Prefix    ::= NCName

[NS8] LocalPart ::= NCName

В погоне за выразительной мощностью XML не следует забывать один из основополагающих принципов — нужно не просто выражать информацию, нужно выражать ее стандартным образом. Это включает в себя не только синтаксические принципы разметки текста, изложенные выше, но и ограничения, накладываемые на логическую структуру документов. Изобретая свой собственный набор элементов и атрибутов, мы вместе с этим набором изобретаем логический формат, а именно то, каким образом элементы и атрибуты должны формировать документ, какая информация должна присутствовать обязательно, а какая является опциональной, какие данные должны содержать те или иные атрибуты и элементы.

В первой версии XML для определения логической структуры документов использовался набор формальных правил, называемый DTD — декларацией типа документа (document type declaration). Помимо этого, в начале мая 2001 года была принята новая техническая рекомендация языка под названием XML-схема (XML Schema), которая также формально задает логическую структуру документа, определяет используемые типы данных, количество повторений и многое другое.

В этой главе мы разберем основы логического построения ХМL-документов с использованием DTD.

Декларация типа документа состоит из одного или нескольких правил-ограничений структуры документа. В частности, DTD позволяет задавать следующие правила:

□ ELEMENT — определение элемента;

□ ATTLIST — определение списка атрибутов элемента;

□ ENTITY — определение сущности;

□ NOTATION — определение нотации.

Эти определения могут быть заданы с использованием конструкции DOCTYPE непосредственно в документе:

<!DOCTYPE advert [

<!-- определение -->

<!-- определение -->

и т.д.

]>

Другой возможностью определения декларации документа является использование внешнего файла:

<!DOCTYPE advert SYSTEM "advert.dtd">

В этом случае можно также дополнять внешние определения внутренними:

<!DOCTYPE advert SYSTEM "advert.dtd" [

<!-- определение -->

<!-- определение -->

и т.д.

]>

Декларация типа документа определяется следующей EBNF-продукцией:

[28] doctypedecl ::= '<!DOCTYPE' S Name (S ExternalID)? S?

                     ('[' (markupdecl | DeclSep)* ']' S?)? '>'

Имя, соответствующее продукции Name, которая идет следом за ключевым словом DOCTYPE, определяет имя корневого элемента ХМL-документа. В предыдущем примере в корне документа должен стоять элемент advert.

Выражение (S ExternalID) ? указывает на то, что декларация типа документа может указываться во внешнем источнике (например, в файле), который описывается внешним идентификатором ExternalID.

[75] ExternalID ::= 'SYSTEM' S SystemLiteral

                    | 'PUBLIC' S PubidLiteral S SystemLiteral

В случае системного идентификатора ("SYSTEM"), SystemLiteral определяет URI определения типа документа. В случае публичного идентификатора, к этому параметру добавляется PubidLiteral, сообщающий дополнительную информацию о ресурсе. Обрабатывающее программное обеспечение может включать в себя DTD для заданного публичного идентификатора. Например, документы, написанные на языке XHTML, должны начинаться следующим объявлением:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"

 "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">

Программа, обрабатывающая документ с таким заголовком, сможет по публичному идентификатору понять, что документ создан на языке XHTML, а значит, обрабатывать его нужно в соответствии со стандартом этого языка. Если же обрабатывающая программа не в курсе определений XHTML, она сможет загрузить декларацию типа по адресу http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd. Публичные идентификаторы, как правило, используются в языках, получающих широкое распространение, поскольку в этом случае формат логической структуры будет известен и без загрузки DTD.