2.1 Корректные XML документы

[Определение: Текстовый объект становится корректным (well-formed) XML документом, если:]

1. как единое целое, он соответствует сценарию document.

2. отвечает всем ограничениям корректности, представленным в этой спецификации.

3. Все разобранные сущности, на которые в данном документе прямо или косвенно делается ссылка, являются корректными (well-formed).

Документ

Соответствие сценарию document подразумевает следующее:

1. В данном объекте содержится один или несколько элементов.

2. [Определение: В объекте имеется в точности один элемент, называемый корневым или элементом документа, ни одна из частей которого не попадает в содержимое какого-либо еще элемента.] Для всех остальных элементов действует правило, что если начальный тэг находится в содержимом некого элемента, то и конечный тэг должен находиться среди содержимого того же элемента. Проще говоря, элементы, маркируемые начальными и конечными тэгами, должны быть вложены друг в друга правильным образом.

[Определение: Из вышесказанного следует что в документе для любого некорневого элемента C имеется другой элемент P из этого же документа, такой что C находится в содержимом P, но при этом не попадает в содержимое какого-либо третьего элемента, также находящегося в содержимом элемента P. В таком случае об элементе P говорят как о родителе элемента C, а элемент C называют непосредственным потомком элемента P.]

2.2 Символы

[Определение: Разобранная сущность (parsed entity) содержит текст - последовательности символов, образующие разметку и символьные данные.] [Определение: символ - это элементарная единица текста, описанная в ISO/IEC 10646 [ISO/IEC 10646] (см. также [ISO/IEC 10646-2000]). Допустимы символы табуляции, возврата каретки, конца строки, а также разрешенные символы из наборов Unicode и ISO/IEC 10646. Последние версии указанных стандартов, актуальные на момент подготовки данного документа, перечислены в Приложении A.1 Нормативные ссылки. Перечисленные стандарты могут быть дополнены новыми символами в ходе обновления или при написании для них новых редакций. Соответственно, XML процессоры должны принимать любой символ из диапазона, указанного для Char. Использовать "символы совместимости", описанные в главе 6.8 из [Unicode] (см. также D21 в главе 3.6 из [Unicode3]), нежелательно.]

Диапазон символов

Механизм шифрования символьных кодов использует битовые шаблоны, которые могут меняться от сущности к сущности. Все XML процессоры должны иметь возможность работать с кодировками UTF-8 и UTF-16 из набора 10646. Механизм для указания используемой кодировки и подключения новых кодировок обсуждается позднее в главе 4.3.3 Кодирование символов в сущностях.

2.3 Общие синтаксические конструкции

В данной главе определяются некоторые символы, широко используемые в грамматике XML.

S (пробельный символ, white space) состоит из одного или нескольких символов пробела (#x20), возврата каретки, конца строки или табулятора.

Пробельный символ

Для удобства символы делятся на буквы, цифры и остальные символы. Буквы состоят из алфавитных, слоговых и идеографических символов. Полное определение конкретных символов из каждого класса дается в Приложении B Классы символов.

[Определение: Имя (name) - это лексема (token), начинающаяся с буквы, либо одного из нескольких символов пунктуации, за которыми следуют буквы, цифры, дефисы, символы подчеркивания, двоеточия или точки (все они называются name character - символами имени).] Имена, начинающиеся с комбинации "xml" или какой-либо из строк, соответствующих шаблону (('X'|'x') ('M'|'m') ('L'|'l')), зарезервированы под стандартизацию в этой спецификации и ее последующих версиях.

Nmtoken (лексема имени) - это произвольное сочетание символов имени.

Имена и лексемы

Строковые данные (literal data) - это любая заключенная в кавычки строка, внутри которой нет кавычек, которые можно было бы принять за разделители этой строки. Строковые данные, или литералы (literals), применяются для указания содержимого внутренних сущностей (EntityValue), значений атрибутов (AttValue) и внешних идентификаторов (SystemLiteral). Заметим, что идентификатор SystemLiteral может быть обработан без проверки разметки.

Литералы

2.4 Символьные данные и разметка

Текст документа образуется сочетанием символьных данных и разметки. [Определение: Разметка принимает форму начальных тэгов, конечных тэгов, тэгов пустых элементов, ссылок на сущности, ссылок на символы, комментариев, разделителей секций CDATA, объявлений типов документов, инструкций обработки, деклараций XML, деклараций текста и любых пробельных символов, которые располагаются на верхнем уровне сущности документа (то есть, вне элемента document и за пределами иных элементов разметки).]

[Определение: Текст, который не относится к разметке, формирует символьные данные документа (character data).]

Символ амперсанта (&) и левая угловая скобка (<) могут появиться в своем обычном текстовом виде только в том случае, если используются в качестве ограничителя разметки, либо находятся в пределах комментария, инструкции обработки или секции CDATA. Если же эти символы потребовались в документе где-либо еще, их следует маскировать, воспользовавшись для этого либо соответствующей числовой ссылкой на символ (numeric character reference), либо строками "&" и "<" соответственно. Правая угловая скобка (>) может быть представлена в виде строки ">". Кроме того, если правая угловая скобка в содержимом элемента попадает в комбинацию символов "]]>", которая не соответствует окончанию секции CDATA, то, в целях совместимости, эту скобку необходимо заменить ссылкой на символ либо комбинацией ">".

Символьные данные в содержимом элемента - это любая строка символов, которая не содержит начальных ограничителей какой-либо разметки. Символьные данные в секции CDATA - это любая строка символов, которая не содержит закрывающего ограничителя секции CDATA (комбинации символов "]]>").

Если в значение атрибута необходимо поместить символ одинарной или двойной кавычки, то апостроф или символ одинарной кавычки (') следует представить комбинацией "'", а символ двойной кавычки (") - как """.

Символьные данные

2.5 Комментарии

[ Определение: Комментарий может размещаться в любом месте документа при условии, что он не попадает в границы какого-либо элемента разметки. Комментаций может также появляться в тех местах декларации типа документа, где это разрешено грамматикой. Комментарии не относятся к символьным данным документа, однако XML процессоры могут (но не обязаны) передавать приложению текст полученных комментариев. Для сохранения совместимости, в комментарии не следует пользоваться комбинацей символов "--" (двойной дефис).] Ссылка на сущность параметра в комментариях не распознается.

Комментарии

Пример комментария:

<!-- declarations for <head> & <body> -->

Заметим, что, согласно требованиям обсуждаемой грамматики, комментарий не может завершаться комбинацией символов --->. Поэтому следующий пример корректным уже не будет.

<!-- B+, B, or B--->

2.6 Инструкции обработки

[Определение: Инструкции обработки (processing instruction, PI) позволяют размещать в документе инструкции для приложений.]

Инструкции обработки

Хотя PI не относятся к символьным данным документа, они точно так же должны быть переданы приложению. Инструкция PI начинается с указания адреса (PITarget), используемого для идентификации приложения, которому предназначается эта инструкция. Адреса с названиями "XML", "xml" и аналогичными зарезервированы для стандартизации в текущей и последующих версиях спецификации. Для формального декларирования адресата инструкции PI может использоваться механизм нотаций XML. Ссылки на сущность параметра в инструкциях обработки не распознаются.

2.7 Секции CDATA

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

Секции CDATA

В секции CDATA распознается только один элемент разметки - строка CDEnd. Поэтому все символы левой угловой скобки и амперсанта могут предстать здесь в своем обычном текстовом виде. Эти символы не нужно (да и невозможно) маскировать с помощью комбинаций "<" и "&". Секции CDATA не могут быть вложенными.

Пример секции CDATA, в которой строки "<greeting>" и "</greeting>" будут распознаваться не как разметка, а как обычные символьные данные:

<![CDATA[<greeting>Hello, world!</greeting>]]>

2.8 Пролог и декларация типа документа

[Определение: Документ XML должен начинаться с декларации XML, указывающей версию используемого языка XML.] Например, в следующем примере представлен полноценный XML документ, корректный, но недействительный:

<?xml version="1.0"?> <greeting>Hello, world!</greeting>

таким образом, имеем:

<greeting>Hello, world!</greeting>

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

Задачей разметки XML документа должно быть описание схемы его размещения и логической структуры, а также связывание пар атрибут-значение с их логической структурой. XML предоставляет механизм для определения логических ограничений для логической структуры и формирования предопределенных единиц размещения - декларацию типа документа. [Определение: XML документ является действительным, если с ним связана декларация типа документа и если этот документ отвечает представленным в ней ограничениям.]

Декларация типа должна располагаться в документе до первого элемента.

Пролог

[Определение: В языке XML декларация типа документа либо сама содержит, либо ссылается на декларации разметки, которые определяют грамматику некого класса документов. Такую грамматику называют декларацией типа документа, или DTD (document type definition). Декларация типа документа может ссылаться на внешний набор, который также содержит декларацию разметки (специальный тип - внешняя сущность), может содержать свой внутренний набор деклараций разметки, а может сочетать оба варианта. DTD документа формируется из обоих этих наборов, обрабатываемых совместно.]

[Определение: Декларация разметки - это декларация типа документа, декларация списка атрибутов, декларация сущности или декларация нотации.] Перечисленные декларации могут целиком, либо частично располагаться в сущности параметра в соответствии с приводимыми далее ограничениями корректности и действительности. Дальнейшие подробности см. в главе 4 Физические структуры.

Декларация типа документа

Отметим, что можно создать корректный документ, который включал бы doctypedecl, не ссылающийся на внешний набор деклараций и не содержащий своего внутреннего набора.

Декларации разметки могут полностью или частично состоять из текста замены для сущностей параметров. Сценарии, приводимые далее в спецификации для конкретных неграничных элементов (elementdecl, AttlistDecl и так далее), описывают декларации уже после подстановки всех сущностей параметров.

Ссылка на сущность параметра распознается в любом месте DTD (внутреннем и внешнем наборах, внешних сущностях параметров) за исключением текстовых данных, инструкций обработки, комментариев и содержимого игнорируемых условных секций (см. главу 3.4 Условные секции). Распознается она также и в тексте значения сущности. Использование сущностей параметров во внутреннем наборе деклараций подчиняется следующим ограничениям:

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

Внешний набор

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

Пример XML документа с декларацией типа документа:

<?xml version="1.0"?> <!DOCTYPE greeting SYSTEM "hello.dtd"> <greeting>Hello, world!</greeting>

Системный идентификатор "hello.dtd" указывает адрес DTD этого документа (ссылку URI).

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

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE greeting [ <!ELEMENT greeting (#PCDATA)> ]> <greeting>Hello, world!</greeting>

Если используются и внешний, и внутренний наборы деклараций, то внутренний набор рассматривается прежде внешнего. Как следствие этого, декларации сущностей и списка атрибутов во внутреннем наборе имеют приоритет над аналогичными декларациями во внешнем наборе.

2.9 Декларация одиночного документа

Декларации разметки, которые XML процессор передает приложению, могут оказывать влияние на содержимое документа. Примером могут служить атрибуты по умолчанию и декларации сущностей. Декларация одиночного документа, которая может быть представлена в составе XML декларации, указывает, могут ли возникать декларации в сущностях параметров, а также декларации, внешние по отношению к сущности документа. [Определение: Внешняя декларация разметки определяется как декларация разметки, встретившаяся во внешнем наборе или в сущности параметра (внешней или внутренней, последний вариант был включен в спецификацию только потому, что непроверяющие процессоры читать их не обязаны).]

Декларация одиночного документа

Значение "yes" в декларации одиночного документа говорит об отсутствии внешних деклараций разметки, которые оказывали бы влияние на информацию, которую XML процессор передает приложению. Значение "no" указывает на то, что такие внешние декларации разметки имеются, либо могут быть появиться. Заметим, что декларация одиночного документа всего лишь свидетельствует о присутствии внешних деклараций. Наличие же в документе ссылок на внешние сущности, если последние уже были декларированы в самом документе, статуса одиночного документа не отменяет.

Если внешние декларации разметки отсутствуют, то декларация одиночного документа теряет смысл. Если присутствуют внешние декларации разметки, но отсутствует декларация одиночного документа, подразумевается что она имеет значение "no".

Любой XML документ, для которого было указано standalone="no", может быть алгоритмическим путем приведен к одиночному документу, что может потребоваться для некоторых приложений, получающих данные по сети.

Пример декларации XML с декларированием одиночного документа:

<?xml version="1.0" standalone='yes'?>

2.10 Обработка пробельных символов

В ходе редактирования XML документов часто бывает удобно воспользоваться "пробельными символами" (white space - пробелы, табуляторы и пустые строки) для выделения разметки для лучшей читаемости. Такие пробельные символы обычно не должны попадать в ту версию документа, которая передается в приложение. С другой стороны, часто встречаются "значимые" пробельные символы, которые должны быть оставлены в передаваемом документе, например если это стихи или исходный код программы.

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

К элементу может быть приставлен специальный атрибут, называемый xml:space, для того чтобы показать, что пробельные символы в этом элементе должны быть сохранены. Если этот атрибут используется в действительных документах, то, как и любой другой, он должен быть декларирован. Будучи декларирован, он должен быть представлен как перечислимый тип, значениями которого являются одно или оба значения "default" и "preserve". Например:

<!ATTLIST poem xml:space (default|preserve) 'preserve'> <!-- --> <!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

Значение атрибута "default" говорит о том, что для данного элемента используется режим обработки пробельных символов, применяемый в приложениях по умолчанию. Значение "preserve" говорит о том, что приложения должны сохранить все пробельные символы. Декларированное таким образом правило относится ко всем элементам, находящимся среди содержимого того элемента, которому был назначен данный атрибут (при условии что это правило не было затем переопределено другим экземпляром атрибута xml:space).

Считается что корневой элемент любого документа не имеет указаний о том, каким образом приложение будет обрабатывать пробелы, если для этого атрибута не было дано соответствующего значения и этот атрибут не был представлен среди значений по умолчанию.

2.11 Обработка концов строк

Часто разобранные сущности XML, помещенные в компьютерные файлы, для удобства редактирования представляются в виде набора строк. В качестве разделителя для таких строк обычно используется некая комбинация символов возврата каретки (#xD) и конца строки (#xA).

Чтобы облегчить работу приложений, текст, который им передает XML процессор, должен быть таким, как если бы этот процессор при выводе перед обработкой нормализовал все концы строк во внешних разобранных сущностях (а также сущности самого документа). Осуществляться это должно путем замены последовательности из двух символов #xD #xA (а также одиночного #xD, за которым не следует #xA) одним символом #xA.

2.12 Идентификация языка

В ходе обработки документа часто бывает полезным идентифицировать, на каком из естественных или формальных языков он был записан. Для идентификации языка, который использовался при записи содержимого и значений атрибутов любого элемента, в документе может быть указан специальный атрибут с названием xml:lang. Если этот атрибут используется в действительном документе, то, как и любой другой, он должен быть декларирован. Значением этого атрибута являются идентификаторы языков, определенные в документе [IETF RFC 1766] (Тэги для идентификации языков) или наследующих его стандартах IETF.

(Сценарии грамматики с 33 по 38 изъяты из спецификации.)

Например:

<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p> <p xml:lang="en-GB">What colour is it?</p> <p xml:lang="en-US">What color is it?</p> <sp who="Faust" desc='leise' xml:lang="de"> <l>Habe nun, ach! Philosophie,</l> <l>Juristerei, und Medizin</l> <l>und leider auch Theologie</l> <l>durchaus studiert mit heiЯem Bemьh'n.</l> </sp>

Предполагается, что информация, представленная в xml:lang, относится ко всем атрибутам и всему содержимому элемента, где этот атрибут был указан (при условии, что в содержимом этого элемента она не была затем переопределена новым экземпляром атрибута xml:lang в другом элементе).

Простая декларация атрибута xml:lang может иметь вид

xml:lang NMTOKEN #IMPLIED

Если это необходимо, для этого атрибута могут быть представлены значения по умолчанию. В сборнике французской поэзии (poem) для английских студентов, содержащем глоссарий (gloss) и пометки на английском языке (note), атрибут xml:lang может быть декларирован следующим образом:

<!ATTLIST poem xml:lang NMTOKEN 'fr'> <!ATTLIST gloss xml:lang NMTOKEN 'en'> <!ATTLIST note xml:lang NMTOKEN 'en'>