Технология XSLT

[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 не следует забывать один из основополагающих принципов — нужно не просто выражать информацию, нужно выражать ее стандартным образом. Это включает в себя не только синтаксические принципы разметки текста, изложенные выше, но и ограничения, накладываемые на логическую структуру документов. Изобретая свой собственный набор элементов и атрибутов, мы вместе с этим набором изобретаем логический формат, а именно то, каким образом элементы и атрибуты должны формировать документ, какая информация должна присутствовать обязательно, а какая является опциональной, какие данные должны содержать те или иные атрибуты и элементы.

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

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

Декларация типа документа (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.

Выражение ('[' (markupdecl | DeclSep) * ']' S?) ? в продукции doctypedecl означает, что в декларации типа документа в квадратных скобках может содержаться последовательность нетерминалов markupdecl и DeclSep.

Первый из этих нетерминалов, markupdecl, показывает, определения какого вида содержатся в DTD:

[29] markupdecl ::= elementdecl
 | AttlistDecl
 | EntityDecl