Расширяемый язык разметки (XML) 1.0 (вторая редакция)

1.1 Возникновение языка XML и его задачи

Язык XML был разработан группой XML Working Group (первоначально называемой SGML Editorial Review Board), сформированной в 1996 году под патронажем World Wide Web Consortium (W3C). Председательствует в группе Jon Bosak из Sun Microsystems, принимающий также активное участие в работе группы XML Special Interest Group (ранее известной как SGML Working Group), которая тоже была сформирована W3C. Список членов XML Working Group представлен в Приложении. Связь группы с W3C обеспечивает Dan Connolly.

При разработке языка XML ставились следующие задачи:

1. XML должен быть пригоден для непосредственного использования в Интернет.

2. XML должен иметь широкий круг применения.

3. XML должен быть совместим с SGML.

4. Обработчики документов XML должны быть просты в написании.

5. Количество факультативных свойств в XML должно быть сведено к абсолютному минимуму, в идеале число их вообще должно быть нулевым.

6. XML документы должны быть удобны для чтения и достаточно понятны.

7. Подготовка XML документа должна осуществляться быстро.

8. Процедура построения XML документа должна быть формальной и точной.

9. Процедура создания XML документов должна быть проста.

10. Краткость при разметке XML документа имеет минимальное значение.

Данная спецификация в сочетании с остальными связанными с нею стандартами (Unicode и ISO/IEC 10646 для символов, Internet RFC 1766 для тэгов идентификации языка, ISO 639 для кодов с названием языка и ISO 3166 для кодов с названием страны) дает всю необходимую информацию для понимания языка XML (версия 1.0) и создания компьютерных программ для его обработки.

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

1.2 Терминология

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

может (may)

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

должен (must)

[Определение: Документы и XML процессоры обязаны действовать именно так, как было описано. В противном случае имеет место ошибка.]

ошибка (error)

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

фатальная ошибка (fatal error)

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

по выбору пользователя (at user option)

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

ограничение действительности (validity constraint, VC)

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

ограничение корректности (well-formedness constraint, WFC)

[Определение: Правило, относящееся ко всем корректным XML документам. Нарушение ограничения корректности классифицируется как фатальная ошибка.]

соответствие (match)

[Определение: (Для строк или имен:) Две сравниваемые строки или имени должны быть идентичны. Символы с несколькими возможными представлениями в ISO/IEC 10646 (например, символы, имеющие обе формы представления precomposed и base+diacritic) считаются совпадающими только тогда, когда в обеих строках они имеют одну и ту же форму представления. Преобразование регистра не производится. (Для строк и правил грамматики:) Строка отвечает сценарию грамматики если она принадлежит языку, генерируемому по этому сценарию. (Для содержимого и моделей содержимого:) Элемент соответствует своей декларации если он отвечает положениям, описанным в соответствующем ограничении [VC: Действительный элемент].]

для совместимости (for compatibility)

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

для взаимодействия (for interoperability)

[Определение: Выделяет фразу, описывающую необязательную рекомендацию, которая была включена в спецификацию для увеличения возможности обработки XML документов с помощью уже установленных SGML процессоров, указанных в Приложении WebSGML Adaptations к ISO 8879.]

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'>

3.1 Начальные тэги, конечные тэги и тэги пустых элементов

[Определение: Начало любого непустого XML элемента помечается начальным тэгом.]

Начальный тэг

Параметр Name в начальном и конечном тэгах определяет тип элемента. [Определение: Пара Name - AttValue называется спецификацией атрибута для данного элемента], [Определение: Параметр Name в каждой такой паре называется именем атрибута], а [Определение: содержимое поля AttValue - текст в одинарных (') или двойных (") кавычках - называется значением атрибута.] Заметим, что очередность появления спецификаций атрибутов в начальном тэге или тэге пустого элемента значения не имеет.

Пример начального тэга:

<termdef id="dt-dog" term="dog">

[Определение: Любой элемент, чье начало отмечено начальным тэгом, должен завершиться конечным тэгом, имя которого повторяет тип элемента, указанный в начальном тэге:]

Конечный тэг

Пример конечного тэга:

</termdef>

[Определение: Текст, заключенный между начальным и конечным тэгами, называется содержимым элемента:]

Содержимое элементов

[Определение: Элемент без содержимого называется пустым элементом.] Пустой элемент может быть представлен либо в виде начального тэга, за которым сразу же следует конечный тэг, либо как тэг пустого элемента. [Определение: Тэг пустого элемента имеет специальный формат:]

Тэги пустых элементов

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

Примеры пустых элементов:

<IMG align="left"
 src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/>

3.2 Декларации типа элемента

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

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

[Определение: Декларация типа элемента имеет вид:]

Декларация типа элемента

где параметр Name определяет декларируемый тип элемента.

Примеры деклараций типа элемента:

<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY>

<!ELEMENT spec (front, body, back?)>
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>

<!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
<!ELEMENT b (#PCDATA)>

3.3 Декларации списка атрибутов

Атрибут используется для того, чтобы связать с элементом пару имя-значение. Спецификация атрибута может быт дана только в начальном тэге, либо тэге пустого элемента. Таким образом, сценарии ее обработки следует искать в главе 3.1 Начальные тэги, конечные тэги и тэги пустых элементов. Декларация списка атрибутов может быть использована для:

• формирования перечня атрибутов, относящихся к определенному типу элементов.

• ограничения по типу атрибутов.

• формирования значений по умолчанию для атрибутов.

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

Декларация списка атрибутов

В поле Name в правиле AttlistDecl указывается тип элемента. По выбору пользователя, XML процессор может генерировать предупреждение, если атрибуты, декларированные для такого типа элементов, сами декларированы не были, однако ошибкой такая ситуация не считается. Параметр Name в правиле AttDef соответствует имени описываемого атрибута.

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

<!ATTLIST termdef
          id      ID      #REQUIRED
          name    CDATA   #IMPLIED>
<!ATTLIST list
          type    (bullets|ordered|glossary)  "ordered">
<!ATTLIST form
          method  CDATA   #FIXED "POST">

<!ENTITY d "&#xD;">
<!ENTITY a "&#xA;">
<!ENTITY da "&#xD;&#xA;">

a="

xyz"

a="&d;&d;A&a;&a;B&da;"

a=
"

A

B
"

3.4 Условные секции

[Определение: Условная секция является фрагментом внешнего набора для декларации типа документа, которая включается или исключается из логической структуры DTD в зависимости от значения управляющего ею ключевого слова.]

Условная секция

Подобно внутреннему и внешнему наборам DTD, условная секция тоже может содержать одну или несколько полных деклараций, комментариев, инструкций обработки или же вложенных условных секций, перемежаемых пробельным символом.

Если ключевым словом условной секции является INCLUDE, то содержимое этой секции становится частью DTD. Если же ключевым словом условной секции является IGNORE, то содержимое секции логической частью DTD не становится. Если условная секция с ключевым словом INCLUDE была представлена в составе более крупной условной секции с ключевым словом IGNORE, то игнорируются обе внутренняя и внешняя секции. Содержимое игнорируемой условной секции обрабатывается путем изъятия всех символов, стоящих после скобки "[", следующей за ключевым словом, и до того как будет найден конец условной секции (исключение составляет условная секция, начинающияся с "<![" и заканчивающаяся "]]>"). При этом ссылки на сущности параметров не распознаются.

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

Например:

<!ENTITY % draft 'INCLUDE' >
<!ENTITY % final 'IGNORE' >

<![%draft;[
<!ELEMENT book (comments*, title, body, supplements?)>
]]>
<![%final;[
<!ELEMENT book (title, body, supplements?)>
]]>

4.1 Ссылки на символ и сущность

[Определение: Ссылка на символ относится к определенному символу из набора ISO/IEC 10646, например, к такому символу, который невозможно получить непосредственно с имеющихся устройств ввода.]

Ссылка на символ

Если ссылка на символ начинается с комбинации "&#x", то все последующие цифры и буквы вплоть до завершающего символа ; образуют шестнадцатеричное представление для кода этого символа, указанного в ISO/IEC 10646. Если же ссылка начинается с комбинации "&#", то все последующие цифры вплоть до завершающего ; образуют десятичное представление кода символа.

[Определение: Ссылка на сущность обращается к содержимому именованной сущности.] [Определение: Ссылка на разобранные общие сущности использует в качестве ограничителей амперсант (&) и символ точки с запятой (;).] [Определение: Ссылка на сущность параметра используют в качестве ограничителей символы процента (%) и точки с запятой (;).]

Ссылка на сущность

Примеры ссылок на символ и сущность:

Type <key>less-than</key> (&#x3C;) to save options.
This document was prepared on &docdate; and
is classified &security-level;.

Пример ссылки на сущность параметра:

<!-- declare the parameter entity "ISOLat2"... -->
<!ENTITY % ISOLat2
         SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
<!-- ... now reference it. -->
%ISOLat2;

4.2 Декларации сущности

[Определение: Сущности декларируются следующим образом:]

Декларация сущности

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

<!ENTITY Pub-Status "This is a pre-release of the specification.">

<!ENTITY open-hatch
         SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY open-hatch
         PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
         "http://www.textuality.com/boilerplate/OpenHatch.xml">
<!ENTITY hatch-pic
         SYSTEM "../grafix/OpenHatch.gif"
         NDATA gif >

4.3 Разобранные сущности

<?xml encoding='UTF-8'?>
<?xml encoding='EUC-JP'?>

4.4 Обработка XML процессором сущностей и ссылок

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

Ссылка в содержимом

Ссылка в любом месте элемента в интервале между начальным и конечным тэгами. Соответствует незавершенному (nonterminal) контенту.

Ссылка в значении атрибута

Ссылка либо в значении атрибута начального тэга, либо в значении по умолчанию из декларации атрибута. Соответствует незавершенному AttValue.

Значение атрибута

Это не ссылка, а лексема типа Name. Выступает либо как значение атрибута, декларированного с типом ENTITY, либо как одна из лексем, перечисленных через пробел в значении атрибута, декларированного с типом ENTITIES.

Ссылка в значении сущности

Ссылка из параметра или строкового значения внутренней сущности, находящихся в декларации сущности. Соответствует незавершенной EntityValue.

Ссылка в DTD

Ссылка во внутреннем или внешнем наборе DTD, не попавшая в конструкции EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral, а также содержимое игнорируемой условной секции (см. главу 3.4 Условные секции).

<!--  -->
<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" >

<!ENTITY EndAttr "27'" >
<element attribute='a-&EndAttr;>

4.5 Построение текста замены для внутренней сущности

Обсуждая процедуру обработки внутренних сущностей, полезно различать два вида значений сущности. [Определение: Строковое значение сущности - это строка в кавычках, которая реально присутствует в декларации сущности и соответствует незавершенному EntityValue.] [Определение: Текст замены - это содержимое сущности после подстановки всех ссылок на символ и сущность параметра.]

Строковое значение сущности, данное в декларации внутренней сущности (EntityValue), может содержать ссылки на символ, на сущность параметра и на общую сущность. Такие ссылки должны целиком содержаться в строковом значении сущности. Реально подставляемый текст замены должен содержать текст замены для всех сущностей параметров и все символы, на которые делалась ссылка, причем в тех местах строкового значения сущности, где эти ссылки находились. Вместе с тем, ссылки на общие сущности должны оставаться без изменений. Например, даны следующие декларации:

<!ENTITY % pub    "&#xc9;ditions Gallimard" >
<!ENTITY   rights "All rights reserved" >
<!ENTITY   book   "La Peste: Albert Camus,
&#xA9; 1947 %pub;. &rights;" >

тогда текст замены для сущности "book":

La Peste: Albert Camus,
© 1947 Éditions Gallimard. &rights;

Ссылка на общую сущность "&rights;" должна расшифроваться только тогда, когда ссылка "&book;" попадает в содержимое документа или значение атрибута.

Эти простые правила могут иметь сложные взаимоотношения. Детальное обсуждение сложного примера этого см. в Приложении D Обработка ссылок на сущность и символ.

4.6 Предопределенные сущности

[Определение: Ссылки на сущность и символ могут быть использованы для маскирования левой угловой скобки, амперсанта и других ограничителей. Для этой цели сформирован целый набор общих сущностей (amp, lt, gt, apos, quot). Также может использоваться числовая ссылка на символ, которая должна обрабатываться как символьные данные и заменяться соответствующим символом сразу по обнаружении. Таким образом, числовые ссылки "<" и "&" могут быть использованы для маскирования символов < и &, встречающихся среди символьных данных.]

Независимо от того, были ли указанные сущности декларированы, они должны распознаваться всеми XML процессорами. Чтобы обеспечить взаимодействие, действительные XML документы перед использованием должны декларировать эти сущности, как и любые другие. Если сущности lt или amp были декларированы, то они должны быть объявлены как внутренняя сущность, чей текст замены - это ссылка на соответствующий маскируемый символ (знак меньше или амперсант). Для этих сущностей необходимо двойное маскирование, чтобы ссылка на них давала корректный результат. Если декларируются сущности gt, apos или quot, то они должны быть представлены как внутренняя сущность, текст замены которой - это одиночный маскируемый символ (либо ссылка на этот символ, двойное маскирование здесь хотя и допустимо, но необязательно). Например:

<!ENTITY lt     "&#38;#60;">
<!ENTITY gt     "&#62;">
<!ENTITY amp    "&#38;#38;">
<!ENTITY apos   "&#39;">
<!ENTITY quot   "&#34;">

4.7 Декларирование нотаций

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

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

Декларации нотации

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

4.8 Сущность документа

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

5.1 Проверяющие и непроверяющие процессоры

XML процессоры, отвечающие требованиям спецификации, делятся на два класса: проверяющие и непроверяющие.

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

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

Для проверки корректности от непроверяющего процессора требется проанализировать лишь сущность документа, включая полный внутренний набор DTD. [Определение: Хотя непроверяющий процессор и не обязан проверять действительность документа, он должен обработать все декларации, найденные во внутреннем наборе DTD, а также во всех прочитанных им сущностях параметров, но только до первой ссылки на сущность параметра, которую он уже не должен читать. Иными словами, он должен использовать сведения из этих деклараций для нормализации значений атрибутов, подстановки текста замены для внутренних сущностей и предоставления значений по умолчанию для атрибутов.] За исключением случая standalone="yes", процессорам запрещается обрабатывать декларации сущностей и списков атрибутов, расположенные после ссылки на сущность параметра, последняя не читается, поскольку может содержать переопределяющие декларации.

5.2 Использование XML процессоров

Поведение проверяющего XML процессора в значительной мере предсказуемо: он должен почесть все части документа и сообщить обо всех нарушениях правил корректности и действительности. Меньшее требуется от непроверяющего процессора: он не должен читать какие-либо части документа кроме сущности документа. Для использования XML процессоров существенное значение могут иметь два эффекта:

• Непроверяющим процессором могут не распознаваться определенные ошибки корректности, особенно те, которые требуют прочтения внешних сущностей. Примером здесь служит нарушение ограничений Entity Declared, Parsed Entity и No Recursion, а также некоторые варианты, описанные в качестве запрещенных в главе 4.4 Обработка XML процессором сущностей и ссылок.

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

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