Алексей Валиков - Технология XSLT

[6] Names ::= Name (S Name)*

Кроме того, техническая рекомендация определяет так называемый именной токен NmToken— строку, которая может состоять из одного или более именных символов и последовательности таких токенов, NmTokens.

[7] NmToken ::= (NameChar)+

[8] NmTokens ::= NmToken (S NmToken)*

Символьные данные могут заключаться в кавычки для того, чтобы формировать литералы. В XML определены следующие литералы: значение сущности ( EntityValue), значение атрибута ( AttValue), системный литерал ( SystemLiteral), а также PubidLiteral— литерал, определяющий публичный идентификатор ресурса ( см. раздел "Определение сущности" данной главы ):

[9] EntityValue ::= '"' ([^%&"] | PEReference | Reference)* '"'

| "'" ([^%&'] | PEReference | Reference)* "'"

[10] AttValue ::= '"' ([^<&"] | Reference)* '"'

| ([^<&"] | Reference)* "'"

[11] SystemLiteral ::= ('"' [^"]* '"')

| ("'" [^']* "'")

[12] PubidLiteral ::= '"' PubidChar* '"'

| "'" (PubidChar - "'")*

[13] PubidChar ::= #x20 | #xD | #xA

| [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]

В литералах EntityValueи AttValueдопустимо использовать продукции сущностей ( PEReference, Reference). Это означает, что при определении значений сущностей и атрибутов можно использовать ссылки на сущности, например, в элементе заданном как:

атрибут titleимеет значение крейсер "Аврора". Двойные кавычки были определены посредством встроенных сущностей.

Символьные данные, которые задаются продукцией CharData, могут состоять из любых символов, кроме символов " <" и " &", которые используются в XML в качестве управляющих. CharDataглавным образом используется в секциях CDATA, и, соответственно, не может содержать терминирующую последовательность " ]]>".

[14] CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*)

Теперь, когда мы разобрали практически все структурные единицы XML, осталось определить стандартным образом синтаксис для самих XML-документов. Им соответствует продукция document:

[1] document ::= prolog element Misc

Итак, XML-документ состоит из пролога, единственного корневого элемента и дополнительного нетерминала Misc, который может включать инструкции по обработке, комментарии и пробельные символы:

[27] Misc ::= Comment | PI | S

Остановимся отдельно на прологе XML-документа. Пролог состоит из необязательной декларации XML ( XMLDecl), необязательной декларации типа документа ( doctypedecl), инструкций, комментариев и пробельных символов:

[22] prolog ::= XMLDeci? Misc* (doctypedecl Misc*)?

В зависимости от того, насколько строго документы соответствуют спецификации XML и собственным DTD-объявлениям, они могут быть хорошо оформленными (well-formed) и правильными (valid).

Хорошо оформленный документ соответствует всем синтаксическим правилам XML и некоторым дополнительным ограничениям, например:

□ имя открывающего тега элемента должно совпадать с именем его закрывающего тега;

□ имена атрибутов элемента не должны повторяться;

□ в значении атрибута нельзя использовать символ " <". Этот символ должен обязательным образом заменяться на сущность;

□ сущности должны быть определены до использования;

□ сущности-параметры могут быть использованы только в блоках DTD;

□ документ должен иметь единственный корневой элемент, содержащий все остальные элементы и символьные данные этого документа. Вне корневого документа допускаются только комментарии, инструкции по обработке, декларация XML и блок DTD.

Правильные документы должны быть хорошо оформленными, и при этом их логическая структура должна удовлетворять объявлениям, которые содержатся в декларации типа документа (DTD).

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

Требование правильности означает четкое соответствие выбранной логической схеме документа. Объявления декларации типа документа накладывают на логическую структуру документа определенные ограничения с тем, чтобы он мог быть стандартным образом обработан не только синтаксическими, но и семантическими процессорами, то есть программами, которые не только могут распознать синтаксис XML-документа, но и "понять" его смысл, переданный разметкой.

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

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

В качестве типичного примера можно привести язык XSLT (язык расширяемых стилей для преобразований, extensible Stylesheet Language for Transformations), который находится в фокусе этой книги. Программы, написанные на XSLT, называются преобразованиями, и они являются в прямом смысле XML-документами, но при этом удовлетворяют логической схеме языка XSLT. При этом преобразования не имели бы смысла без XSLT-процессора, который может применять их к другим документам. Они были бы просто текстом.

Создание XML-документов без программного обеспечения, которое будет понимать их семантику — это все равно, что писать программы на языке программирования, для которого не существует трансляторов и интерпретаторов. Они могут быть безупречно корректными, но совершенно бесполезными.

Стандартизированный и совсем не сложный синтаксис XML позволил многим компаниям разработать средства для синтаксического разбора XML-документов. Программы такого рода называют XML-парсерами (англ. parse — разбирать, анализировать). В настоящее время существует два основных типа XML-парсеров: SAX-парсеры и DOM-парсеры. Оба типа широко используются в различных приложениях — парсеры избавляют от необходимости писать собственные синтаксические анализаторы, штудировать спецификации и так далее. Мы коротко опишем каждый из этих типов.