Расширяемый Язык Разметки (XML) 1.0 (Второе Издание)

1 Введение

Extensible Markup Language, сокращённо XML, описывает класс объектов данных, называемых XML-документы, и частично описывает поведение обрабатывающих их компьютерных программ. XML является профилем приложения или ограниченным вариантом SGML - The Standard Generalized Markup Language [ISO 8879]. По структуре документы XML являются "соответствующими" документами SGML.

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

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

1.1 Происхождение и цели создания

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

Цели создания XML:

XML будет широко распространён в Internet.
XML будет поддерживать большой диапазон приложений.
XML будет совместим с SGML.
Он будет лёгким для написания программ, обрабатывающих документы XML.
Количество свойств по выбору (optional) в XML будет сведено к абсолютному минимуму, в идеале - к нулю.
Документы XML должны быть разборчивыми и ясными по смыслу.
Дизайн XML должен выполняться быстро.
Дизайн XML должен быть формальным и кратким.
Документы XML должны легко создаваться.
Краткость в разметке 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\ограничение правильности: [Определение: Правило, применимое ко всем правильным документам XML. Нарушение ограничений правильности является ошибкой; она обязана, по выбору пользователя, выдавать сообщение проверяющими процессорами XML.]
well-formedness constraint\ограничение правильного формирования: [Определение: Правило, применимое ко всем правильно сформированным документам XML. Нарушение ограничений правильного формирования является фатальной ошибкой.]
match\совпадает: [Определение:
(Для строки или имени:) Две строки или два имени при сравнении должны быть идентичными - совпадать полностью. Символы, имеющие различные варианты представления в ISO/IEC 10646 (например, символы, имеющие предопределённую или "база+диакритический знак" формы), совпадают только тогда, когда они имеют одинаковое представление в обеих строках. Приведение регистра не выполняется.
(Для строк и грамматических правил:) Строка совпадает с грамматическим объектом, если она принадлежит к языку, генерируемому этим объектом.
(Для содержимого и моделей содержимого:) Элемент совпадает со своим объявлением, если он соответствует по форме описанию в ограничении [ОП(ограничение правильности): Элемент Верен].]
for compatibility\для совместимости: [Определение: Помечает предложение, описывающее свойство XML, включённое только для того, чтобы удостовериться, что XML остаётся совместимым с SGML.]
for interoperability\для обеспечения взаимодействия: [Определение: Помечает предложение, описывающее необязывающие рекомендации, включаемые для того, чтобы увеличить шансы того, что документы XML могут быть обработаны существующей установленной базой процессоров SGML, которые существовали до WebSGML Adaptations Annex/Адаптивного дополнения к ISO 8879.]

2 Документы

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

Каждый документ XML имеет логическую и физическую структуру.
Физически документ состоит из единиц, называемых экземплярами. Экземпляр может ссылаться на другие экземпляры, что вызывает их включение в документ. Документ начинается в "корне" - экземпляре документа.
Логически документ состоит из объявлений, элементов, комментариев, символьных мнемоник и инструкций процесса, и каждый вышеуказанный элемент обозначается в документе определённой разметкой. Логическая и физическая структуры обязаны соответствующим образом вкладываться, как описано в разделе 4.3.2 Правильно сформированные разбираемые экземпляры.

2.1 Правильно сформированные документы XML

[Определение: Текстовый объект является правильно сформированным документом XML, если:]

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

Document\Документ

[1] document ::= prolog element Misc*

Совпадение с объектом документа предполагает, что:

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

[Определение: Как следствие этого, для каждого некорневого элемента C в документе имеется элемент P в таком документе, что C находится в содержимом элемента P, но не в содержимом любого другого элемента, который находится в содержимом P.
P называется parent/родителем C, а C - child/потомком P.]

2.2 Символы

[Определение: Разбираемый экземпляр содержит текст, последовательность символов, которая может представлять символьные данные или разметку.]
[Определение: character/символ это атомарная (первичная) единица текста, как специфицировано в 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]), не рекомендовано.]

Character Range\Диапазон символов

[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* любой символ Unicode, исключая суррогатные блоки, FFFE и FFFF. */

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

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

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

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

White Space\Пробел

[3] S ::= (#x20 | #x9 | #xD | #xA)+

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

[Определение: Name\Имя это лексическая единица, начинающаяся буквой или одним из символов пунктуации и продолжающаяся буквами, цифрами, дефисами, символами подчёркивания, двоеточием или full stops, известными как символы именования.]
Имена, начинающиеся строкой "xml" или любой строкой, совпадающей с (('X'|'x') ('M'|'m') ('L'|'l')), зарезервированы для целей стандартизации в этой или последующих версиях данной спецификации.

Примечание:

Пространство Имён в Рекомендациях XML [XML Names] устанавливает значения именам, содержащим символы двоеточия. Следовательно, авторы не должны использовать двоеточие в именах XML, исключая использование для целей пространства имён, но процессоры XML обязаны принимать двоеточие как символ именования.

Nmtoken (лексема именования) состоит из символов именования.

Names and Tokens\Имена и Лексемы

[4]	`NameChar`	::=	`Letter \| Digit \| '.' \| '-' \| '_' \| ':' \| CombiningChar \| Extender`
[5]	`Name`	::=	`(Letter \| '_' \| ':') (NameChar)*`
[6]	`Names`	::=	`Name (S Name)*`
[7]	`Nmtoken`	::=	`(NameChar)+`
[8]	`Nmtokens`	::=	`Nmtoken (S Nmtoken)*`

Литерные данные это любая строка, заключённая в кавычки и не содержащая знаков кавычки, которые используются в качестве ограничителей этой строки. Литеры используются для специфицирования содержимого внутренних экземпляров/internal entities (EntityValue), значений атрибутов (AttValue) и внешних идентификаторов (SystemLiteral). Обратите внимание, что SystemLiteral может быть разобран без сканирования разметки.

Literals\Литеры

[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 допускает определение экземпляра, состоящего из одиночного < в литерале (напр., <!ENTITY mylt "<">), настоятельно рекомендуется исключить такое использование, поскольку любое обращение к такому экземпляру вызовет ошибку "правильности формирования" (well-formedness).

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

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

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

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

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

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

Character Data\Символьные Данные

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

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

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

Comments/Комментарии

[15] Comment ::= ''

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

<!-- объявления <head> и <body> -->

Заметьте, что грамматика не допускает заканчивать комментарии сочетанием --->.
Следующий пример сформирован неправильно.

<!-- B+, B или B--->

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

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

Processing Instructions\Инструкции Процесса

[16]	`PI`	::=	`'<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'`
[17]	`PITarget`	::=	`Name - (('X' \| 'x') ('M' \| 'm') ('L' \| 'l'))`

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

2.7 Разделы CDATA

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

CDATA Sections/Разделы CDATA

[18]	`CDSect`	::=	`CDStart CData CDEnd`
[19]	`CDStart`	::=	`'<![CDATA['`
[20]	`CData`	::=	`(Char* - (Char* ']]>' Char*))`
[21]	`CDEnd`	::=	`']]>'`

Внутри раздела CDATA только строка CDEnd распознаётся как разметка, так что амперсанд и левая угловая скобка могут появляться в своей литеральной форме: они не должны (и не могут) быть указаны в escape-последовательности с использованием "<" и "&".
Раздел 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 является правильным/valid, если он имеет ассоциированное объявление типа документа и если документ выполняет ограничения, выраженные в нём.]

Объявление типа документа обязано появляться перед первым элементом в документе.

Prolog\Пролог

[22]	`prolog`	::=	`XMLDecl? Misc* (doctypedecl Misc*)?`
[23]	`XMLDecl`	::=	`'<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'`
[24]	`VersionInfo`	::=	`S 'version' Eq ("'" VersionNum "'" \| '"' VersionNum '"')/* */`
[25]	`Eq`	::=	`S? '=' S?`
[26]	`VersionNum`	::=	`([a-zA-Z0-9_.:] \| '-')+`
[27]	`Misc`	::=	`Comment \| PI \| S`

[Определение: объявление типа документа XML содержит или указывает на объявления разметки, предоставляющие грамматику для класса документов. Эта грамматика известна как определение типа документа или ОТД/DTD. Объявление типа документа может указывать на внешний поднабор (особый вид внешнего экземпляра), содержащий объявления разметки, или может непосредственно содержать объявления разметки во внутреннем поднаборе, или может иметь и то, и другое. ОТД документа состоит из обоих соединённых поднаборов.]

[Определение: объявление разметки это объявление типа элемента, объявление списка атрибутов и объявление экземпляра, или объявление нотации.] Эти объявления могут полностью или частично содержаться внутри экземпляров параметров, как описано ниже в разделах о правильном формировании и ограничениях правильности.
Дополнительную информацию см. в 4 Физических Структурах.

Document Type Definition\Определение Типа Документа

[28]	`doctypedecl`	::=	`'<!DOCTYPE' S Name (S ExternalID)? S? ('[' (markupdecl \| DeclSep)* ']' S?)? '>'`	[ОП (ограничение правильности): тип Root Element]
				ОПС (ограничение правильной сформированности): Внешний Поднабор]
				/ /
[28a]	`DeclSep`	::=	`PEReference \| S`	[ОПС: PE/ЭП (экземпляры параметров) между объявлениями]
				/ /
[29]	`markupdecl`	::=	`elementdecl \| AttlistDecl \| EntityDecl \| NotationDecl \| PI \| Comment`	[ОП: соответствующее объявление/вложение ЭП]
				[ОПС: ЭП во внутреннем поднаборе]

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

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

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

Ограничение правильности: Тип Корневого Элемента

Имя в объявлении типа документа обязано совпадать с типом элемента корневого элемента.

Ограничение правильности: Соответствующее Объявление/Вложение ЭП

Замещающий текст экземпляра параметра обязан правильно вкладываться в объявления разметки. То есть, если первый или последний символ объявления разметки (markupdecl выше по тексту) содержится в замещающем тексте для ссылки на ЭП, то оба они обязаны содержаться в одном и том же замещающем тексте.

Ограничение правильной сформированности: ЭП во Внутреннем Поднаборе

Во внутреннем поднаборе ОТД, ссылки на ЭП могут появляться только там, где могут появляться объявления разметки, но не внутри объявлений разметки. (Это не относится к ссылкам, появляющимся во внешних ЭП, или ко внешним поднаборам.)

Ограничение правильной сформированности: Внешний Поднабор

Внешний поднабор, если он имеется, обязан совпадать с продукцией для extSubset.

Ограничение правильной сформированности: ЭП между Объявлениями

Замещающий текст ссылки ЭП в DeclSep обязан совпадать с продукцией extSubsetDecl.

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

External Subset\Внешний Поднабор

[30]	`extSubset`	::=	`TextDecl? extSubsetDecl`
[31]	`extSubsetDecl`	::=	`( markupdecl \| conditionalSect \| DeclSep)*`	/ /

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

Пример документа XML с объявлением типа документа:

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

Системный идентификатор "hello.dtd" задаёт адрес (ссылку URI) на ОТД для данного документа.

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

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

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

2.9 Отдельное объявление документа

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

Standalone Document Declaration\Отдельное Объявление Документа

[32] SDDecl ::= S 'standalone' Eq (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"')) [ОП: Отдельное Объявление Документа]

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

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

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

Ограничение правильности: Объявление Отдельного Документа

Объявление отдельного документа обязано иметь значение "no", если любое из внешних объявлений разметки содержит объявления:

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

Пример объявления XML с объявлением отдельного документа:

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

2.10 Обработка пробелов

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

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

Специальный атрибут, называемый xml:space, может быть присоединён к элементу для того, чтобы сигнализировать о намерении сохранить пробел в данном элементе для использования приложением. В правильных/valid документах этот атрибут, как и некоторые другие, обязан быть объявлен, если он используется. Если объявлен, он обязан быть дан как перечисляемый тип, значения которого - одно или оба - "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, обязаны быть таким, как если бы процессор XML нормализовал все разрывы строк во внешних разбираемых экземплярах (включая экземпляр документа) при вводе, перед разбором, транслируя обе двухсимвольные последовательности - #xD #xA и любые #xD, после которых не идёт символ #xA, в одиночный символ #xA.

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

При обработке документа часто используется идентификация естественного или формального языка, на котором написано содержимое. Специальный атрибут, называемый xml:lang, может быть вставлен в документ, чтобы специфицировать язык, используемый в содержимом и значениях атрибутов любого элемента в документе XML. В правильных документах этот атрибут, как и некоторые другие, обязан быть объявлен, если используется. Значениями атрибута являются идентификаторы языка, как определено в [IETF RFC 1766], Tags for the Identification of Languages, или его преемниках в IETF Standards Track.

Примечание:

Тэги [IETF RFC 1766] состоят из двухбуквенных кодов языка, как определено в [ISO 639], из двухбуквенных кодов страны, как определено в [ISO 3166], или из идентификаторов языка, зарегистрированных Internet Assigned Numbers Authority [IANA-LANGCODES].
Ожидается, что преемник [IETF RFC 1766] введёт трёхбуквенные коды языка для языков, не представленных в настоящее время в [ISO 639].

(Продукты с 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

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

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

3 Логические структуры

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

Element\Элемент

[39]	`element`	::=	`EmptyElemTag`
			`\| STag content ETag`	[ОПС: Совпадение типа элемента]
				[ОП: Элемент верен (правильный)]

Данная спецификация не вводит ограничений семантики, использования или (синтаксически) именования типов и атрибутов элементов, за исключением того, что имена начинающиеся с (('X'|'x')('M'|'m')('L'|'l')), зарезервированы для целей стандартизации этой и последующих версий данной спецификации.

Ограничение правильной сформированности: Соответствие Типа Элемента

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

Ограничение правильности: Элемент верен

Элемент является верным (правильным), если имеется объявление, соответствующее elementdecl, где Name соответствует типу элемента и выдерживается одно из следующих условий:

Объявление соответствует EMPTY, и элемент не имеет содержимого.
Объявление соответствует children, и последовательность дочерних элементов принадлежит языку, генерируемому регулярным выражением в модели содержимого, при наличии возможных пробелов (символами, соответствующими нетерминальному S) между начальным тэгом и первым дочерним элементом, между дочерними элементами или между последним дочерним элементом и конечным тэгом. Обратите внимание, что раздел CDATA, содержащий только пробелы, не соответствует нетерминальному S, и , следовательно, не может появляться в этих позициях.
Объявление соответствует Mixed, и содержимое состоит из символьных данных и дочерних элементов, чьи типы соответствуют именам в модели содержимого.
Объявление соответствует ANY (Любой), и типы каждого из дочерних элементов объявлены.

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

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

Start-tag\Начальный тэг

[40]	`STag`	::=	`'<' Name (S Attribute)* S? '>'`	[ОПС: Уникальный Att Spec]
[41]	`Attribute`	::=	`Name Eq AttValue`	[ОП: Тип Значения Атрибута]
				[ОПС: Нет Ссылок на Внешние Объекты]
				[ОПС: Нет < в Значениях Атрибутов]

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

Ограничение правильной сформированности: Уникальный Att Spec

Имя атрибута не может появляться более одного раза в одном начальном тэге или тэге пустого элемента.

Ограничение правильности: Тип Значения Атрибута

Атрибут обязан быть объявлен; значение обязано быть того типа, который для него объявлен. (о типах атрибутов см. 3.3 Объявления Списка Атрибутов.)

Ограничение правильной сформированности: Нет Ссылок на Внешние Объекты

Значения атрибутов не могут содержать прямые или косвенные объектные ссылки на внешние объекты.

Ограничение правильной сформированности: Нет < в Значениях Атрибутов

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

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

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

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

End-tag\Конечный Тэг

[42] ETag ::= '</' Name S? '>'

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

</termdef>

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

Content of Elements\Содержимое Элемента

[43] content ::= CharData? ((element | Reference | CDSect | PI | Comment) CharData?)* /* */

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

Tags for Empty Elements\Тэги пустых Элементов

[44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>' [ОПС: Уникальный Att Spec]

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

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

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

3.2 Объявления типа элемента

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

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

[Определение: Объявление Типа Элемента имеет форму:]

Element Type Declaration\Объявление Типа Элемента

[45]	`elementdecl`	::=	`'<!ELEMENT' S Name S contentspec S? '>'`	[ОП: Уникальное Объявление Типа Элемента]
[46]	`contentspec`	::=	`'EMPTY' \| 'ANY' \| Mixed \| children`

где Name задаёт тип объявляемого элемента.

Ограничение правильности: Уникальное Объявление Типа Элемента

Тип элемента может быть объявлен только однократно.

Примеры объявлений типов элементов:

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

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

[Определение: Тип элемента имеет содержимое элемента, если элементы данного типа обязаны содержать только дочерние элементы (а не символьные данные), которые могут быть, по усмотрению, разделены пробелами (символами, соответствующими нетерминальному S).]
[Определение: В этом случае ограничение включает модель содержимого, простую грамматику, управляющую разрешёнными типами дочерних элементов и порядком, в котором они могут появляться.] Грамматика построена на content particles (cp)/частицах содержимого и состоит из имён, списков выбора частиц содержимого или списков последовательностей частиц содержимого:

Element-content Models\Модели Содержимого Элемента

[47]	`children`	::=	`(choice \| seq) ('?' \| '*' \| '+')?`
[48]	`cp`	::=	`(Name \| choice \| seq) ('?' \| '*' \| '+')?`
[49]	`choice`	::=	`'(' S? cp ( S? '\|' S? cp )+ S? ')'`	/ /
				/ /
				[ОП: Соответствующее Вложение Групп/Экземпляров Параметров]
[50]	`seq`	::=	`'(' S? cp ( S? ',' S? cp )* S? ')'`	/ /
				[ОП: Соответствующее Вложение Групп/Экземпляров Параметров]

где каждое Name - это тип элемента, который может появляться как дочерний. Любая частица содержимого в списке выбора может появляться в содержимом элемента в том месте, где список выбора появляется в грамматике; частицы содержимого, появляющиеся в списке последовательностей, обязаны появляться в содержимом элемента в том порядке, в котором они даны в списке. Необязательные символы после имени или списка управляют тем, может ли элемент или частицы содержимого в списке появляться один или более раз (+), ноль или более (*) или ноль или один (?) раз. Отсутствие такого оператора означает, что элемент или частица содержимого обязан/а появиться только однократно. Этот синтаксис и значения идентичны таковым, используемым в продуктах/productions в данной спецификации.

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

Ограничение правильности: Соответствующее вложение Групп/Экземпляров Параметров

Замещающий текст экземпляра параметра обязан быть вложен соответствующим образом с помощью групп скобок. Можно сказать , что, если закрывающие или открывающие скобки конструкций choice, seq или Mixed содержатся в замещающем тексте экземпляра параметра, то оба (тэга) обязаны содержаться в одном и том же замещающем тексте.

Для целей взаимодействия, если ссылка на экземпляр параметра появляется в конструкции choice, seq или Mixed, его замещающий текст должен содержать как минимум один непробельный символ, и ни первый, ни последний непробельный символ замещающего текста не должен быть коннектором (| или ,).

Примеры моделей содержимого элементов:

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

3.2.2 Смешанное содержимое

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

Mixed-content Declaration\Объявление Смешанного Содержимого

[51]	`Mixed`	::=	`'(' S? '#PCDATA' (S? '\|' S? Name)* S? ')*'`
			`\| '(' S? '#PCDATA' S? ')'`	[ОП: Соответствующее Вложение Групп/Экземпляров Параметров]
				[ОП: Отсутствие Дубликатов Типов]

Name задаёт тип элемента, который может появляться в качестве потомка. Ключевое слово #PCDATA исторически произошло от термина "parsed character data/разбираемые символьные данные."

Ограничение правильности: Отсутствие Дубликатов Типов

Одно и то же имя обязано не появляться более чем однократно в одном объявлении смешанного содержимого.

Примеры объявлений смешанного содержимого:

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

3.3 Объявления списка атрибутов

Атрибуты используются для ассоциирования пар имя-значение с элементами. Спецификации атрибутов могут появляться только в начальных тэгах и тэгах пустых элементов; поэтому продукции/productions, используемые для их распознавания, появляются в разделе 3.1 Начальные и конечные тэги, тэги пустых элементов. Объявления списков атрибутов могут использоваться:

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

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

Attribute-list Declaration\Объявление Списка Атрибутов

[52]	`AttlistDecl`	::=	`'<!ATTLIST' S Name AttDef* S? '>'`
[53]	`AttDef`	::=	`S Name S AttType S DefaultDecl`

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

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

3.3.1 Типы атрибутов

Есть три разновидности типов атрибутов XML: string/строковой, набор лексемных типов и перечисляемые типы. Тип string может принимать в качестве значения любые символьные строки; лексемные типы имеют различные лексические и семантические ограничения. Ограничения правильности, отмеченные в грамматике, применяются после нормализации значения атрибута, как описано в 3.3 Объявлении Списка Атрибутов.

Attribute Types\Типы Атрибутов

[54]	`AttType`	::=	`StringType \| TokenizedType \| EnumeratedType`
[55]	`StringType`	::=	`'CDATA'`
[56]	`TokenizedType`	::=	`'ID'`	[ОП: ID]
				[ОП: Один ID на Тип Элемента]
				[ОП: Значение по умолчанию ID Атрибута]
			`\| 'IDREF'`	[ОП: IDREF]
			`\| 'IDREFS'`	[ОП: IDREF]
			`\| 'ENTITY'`	[ОП: Имя Экземпляра]
			`\| 'ENTITIES'`	[ОП: Имя Экземпляра]
			`\| 'NMTOKEN'`	[ОП: Лексема Имени]
			`\| 'NMTOKENS'`	[ОП: Лексема Имени]

Ограничение правильности: ID

Значения типа ID обязаны соответствовать продукции Name. Имя обязано не появляться более одного раза в документе XML как значение данного типа; т.е. значения ID обязаны уникально идентифицировать элементы.

Ограничение правильности: Один ID на Тип Элемента

Ни один тип элемента не может иметь более одного ID специфицированного атрибута.

Ограничение правильности: Значение по умолчанию ID Атрибута

ID атрибута обязан иметь объявленное значение по умолчанию - #IMPLIED или #REQUIRED.

Ограничение правильности: IDREF

Значения типа IDREF обязаны соответствовать продукции Name, а значения типа IDREFS обязаны соответствовать Names/Именам; каждое Name обязано соответствовать значению атрибута ID некоторого элемента документа XML; т.е. значения IDREF обязаны соответствовать значению некоторого атрибута ID.

Ограничение правильности: Имя Экземпляра

Значения типа ENTITY обязаны соответствовать продукции Name, значения типа ENTITIES обязаны соответствовать Именам; каждое Name обязано соответствовать имени неразбираемого экземпляра, объявленного в ОТД.

Ограничение правильности: Лексема Имени

Значения типа NMTOKEN обязаны соответствовать продукции Nmtoken; значения типа NMTOKENS обязаны соответствовать Nmtokens.

[Определение: Enumerated attributes/Перечисляемые Атрибуты могут принимать одно значение из списка значений, предоставляемых в объявлении]. Имеется два вида перечисляемых типов:

Enumerated Attribute Types\Типы Перечисляемых Атрибутов

[57]	`EnumeratedType`	::=	`NotationType \| Enumeration`
[58]	`NotationType`	::=	`'NOTATION' S '(' S? Name (S? '\|' S? Name)* S? ')'`	[ОП: Атрибуты Нотации]
				[ОП: Одна Нотация на Тип Элемента]
				[ОП: Нет Нотации в Пустом Элементе]
[59]	`Enumeration`	::=	`'(' S? Nmtoken (S? '\|' S? Nmtoken)* S? ')'`	[ОП: Перечисление]

Атрибут NOTATION идентифицирует нотацию, объявленную в ОТД с ассоциированными системными и/или публичными идентификаторами, используемыми для интерпретации элемента, к которому атрибут присоединён.

Ограничение правильности: Атрибуты Нотации

Значения этого типа обязаны соответствовать одному из имён нотации, включённому в объявление; все имена нотации в объявлении обязаны быть объявлены.

Ограничение правильности: Одна Нотация на Тип Элемента

Ни один тип элемента не может иметь более одного специфицированного атрибута NOTATION.

Ограничение правильности: Нет Нотации в Пустом Элементе

Для обеспечения совместимости, атрибут типа NOTATION обязан не быть объявленным в элементе, объявленном как EMPTY.

Ограничение правильности: Перечисление

Значения этого типа обязаны с одной из лексем Nmtoken в объявлении.

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

3.3.2 Значения по умолчанию для атрибута

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

Attribute Defaults\Значения по Умолчанию

[60]	`DefaultDecl`	::=	`'#REQUIRED' \| '#IMPLIED'`
			`\| (('#FIXED' S)? AttValue)`	[ОП: Требуемый Атрибут]
				[ОП: Законное Значение по Умолчанию Атрибута]
				[ОПС: Нет < в Значениях Атрибута]
				[ОП: Значения по Умолчанию Фиксированного Атрибута]

В объявлении атрибута, #REQUIRED означает, что атрибут всегда обязан быть предоставлен, #IMPLIED - что значение по умолчанию не предоставляется.
[Определение: Если в объявлении не указано ни #REQUIRED, ни #IMPLIED, тогда значение AttValue содержит объявленное значение default; ключевое слово #FIXED устанавливает, что атрибут обязан всегда иметь значение по умолчанию. Если значение по умолчанию объявляется тогда, когда процессор XML вычислил отсутствующий атрибут, поведение будет таким, как если бы атрибут был представлен с объявленным значением по умолчанию.]

Ограничение правильности: Атрибут Required/Необходимый

Если объявлением по умолчанию является ключевое слово #REQUIRED, тогда атрибут обязан быть специфицирован для всех элементов типа из объявления списка атрибутов.

Ограничение правильности: Законное Значение Атрибута по умолчанию

Объявленное значение по умолчанию обязано соответствовать лексическим ограничениям объявляемого типа атрибута.

Ограничение правильности: Значение по умолчанию Фиксированного Атрибута

Если атрибут имеет значение по умолчанию, объявленное при помощи ключевого слова #FIXED, то экземпляры этого атрибута обязаны совпадать со значением по умолчанию.

Примеры объявлений списка атрибутов:

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

3.3.3 Нормализация значения атрибута

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

Все разрывы строки должны быть нормализованы при вводе до #xA, как описано в разделе 2.11 Обработка Конца Строки, чтобы в дальнейшем алгоритм оперировал текстом, нормализованным таким способом.
Начать с нормализованного значения, состоящего из пустой строки.
Для каждого символа, ссылки на объект или мнемоники символа в ненормализованном значении атрибута - с первого до последнего, выполнить следующее:
- Для мнемоники символа - присоединить мнемонику к нормализованному значению.
- Для ссылки на объект - рекурсивно применять шаг 3 данного алгоритма к замещающему тексту объекта.
- Для пробельного символа (#x20, #xD, #xA, #x9) - присоединить символ пробела (#x20) к нормализованному значению.
- Для других символов - присоединить символ к нормализованному значению.

Если тип атрибута - не CDATA, то процессор XML обязан далее обрабатывать нормализованное значение атрибута, отбрасывая ведущие и ведомые пробелы (#x20) и заменяя последовательности пробельных символов (#x20) одиночным символом пробела (#x20).

Обратите внимание, что ненормализованное значение атрибута содержит ссылки-мнемоники на пробельный символ, отличный от #x20, а нормализованное значение содержит ссылку на сам символ (#xD, #xA или #x9). Это контрастирует с тем случаем, когда ненормализованное значение содержит символ пробела (не ссылку), который заменяется на символ пробела (#x20) в нормализованном значении, и также с тем случаем, когда ненормализованное значение содержит ссылку на экземпляр, замещающий текст которого содержит символ пробела; обрабатываемый рекурсивно, символ пробела заменяется в нормализованном значении на пробел (#x20).

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

Далее идут примеры нормализации атрибута.
В данных объявлениях:

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

спецификации атрибутов в левой колонке ниже могут быть нормализованы до символьных последовательностей в средней колонке, если атрибут a объявлен NMTOKENS, и до последовательностей в правой колонке, если a объявлен как CDATA.

Спецификация атрибута a является NMTOKENS a является CDATA

a="xyz"

x y z

#x20 #x20 x y z

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

A #x20 B

#x20 #x20 A #x20 #x20 B #x20 #x20

a="&#xd;&#xd;A&#xa;&#xa;B&#xd;&#xa;"

#xD #xD A #xA #xA B #xD #xA

#xD #xD A #xA #xA B #xD #xD

Заметьте, что последний пример неверен (но правильно сформирован), если a объявлен типом NMTOKENS.

3.4 Разделы условий

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

Conditional Section\Разделы Условий

[61]	`conditionalSect`	::=	`includeSect \| ignoreSect`
[62]	`includeSect`	::=	`'<![' S? 'INCLUDE' S? '[' extSubsetDecl ']]>'`	/ /
				[ОП: Соответствующее Вложение Секции Условий/ЭП]
[63]	`ignoreSect`	::=	`'<![' S? 'IGNORE' S? '[' ignoreSectContents* ']]>'`	/ /
				[ОП: Соответствующее Вложение Секции Условий/ЭП]
[64]	`ignoreSectContents`	::=	`Ignore ('<![' ignoreSectContents ']]>' Ignore)*`
[65]	`Ignore`	::=	`Char* - (Char* ('<![' \| ']]>') Char*)`

Ограничение правильности: Соответствующее вложение Секции Условий/Экземпляров Параметров

Если "<![", "[" или "]]>" секции условий содержится в замещающем тексте для ссылки экземпляра параметра, то все они обязаны содержаться в одном замещающем тексте.

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

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

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

Пример:

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

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

4 Физические структуры

Определение: Документ XML может состоять из одной или более единиц хранения. Они называются экземплярами; они имеют содержимое и все (исключая экземпляр документа и внешний поднабор ОТД) идентифицируются по name\имени экземпляра.] Каждый документ XML имеет один экземпляр, называемый экземпляр документа, который служит в качестве стартовой точки для процессора XML и может содержать весь документ.

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

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

Разбираемые экземпляры вызываются по имени с использованием ссылок экземпляра; неразбираемые экземпляры - по имени, заданному в значении атрибутов ENTITY или ENTITIES.

[Определение: General entities/Общие экземпляры это экземпляры для использования внутри содержимого документа. В этой спецификации ОЭ иногда называются неквалифицированным термином экземпляр, если это не приводит к неоднозначности.]
[Определение: Экземпляры параметров это разбираемые экземпляры для использования внутри ОТД.] Эти два типа экземпляров используют разные формы ссылок и распознаются в различных контекстах. Следовательно, они занимают разные пространства имён; экземпляр параметра и общий экземпляр с одни именем - это два разных экземпляра.

4.1 Ссылки символов и экземпляров

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

Character Reference\Ссылка Символа

[66]	`CharRef`	::=	`'&#' [0-9]+ ';'`
			`\| '&#x' [0-9a-fA-F]+ ';'`	[ОПС: Допустимый Символ]

Ограничение правильной сформированности: Допустимый Символ

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

Если ссылка символа начинается с "&#x", цифры и буквы вплоть до конечного ; дают 16-ричное представление кодовой точки входа символа ISO/IEC 10646. Если она начинается просто с "&#", то цифры вплоть до конечного ; дают 10-ричное представление кодовой точки входа символа.

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

Entity Reference\Ссылки Экземпляра

[67]	`Reference`	::=	`EntityRef \| CharRef`
[68]	`EntityRef`	::=	`'&' Name ';'`	[ОПС: Экземпляр Объявлен]
				[ОП: Экземпляр Объявлен]
				[ОПС: Разбираемый Экземпляр]
				[ОПС: Нет Рекурсии]
[69]	`PEReference`	::=	`'%' Name ';'`	[ОП: Экземпляр Объявлен]
				[ОПС: Нет Рекурсии]
				[ОПС: В ОТД]

Ограничение правильной сформированности: Entity Declared/Экземпляр Объявлен

В документе без ОТД, документе только с одним внутренним поднабором ОТД, не содержащим ссылок экземпляров параметров, или в документе со "standalone='yes'", для ссылки экземпляра, которая не появляется внутри внешнего поднабора или экземпляра параметра, Name, заданное в ссылке экземпляра, обязано совпадать с именем в объявлении экземпляра, который(ое?) не появляется внутри внешнего поднабора или экземпляра параметра, за исключением того, что правильно сформированный документ не должен объявлять следующие экземпляры: amp, lt, gt, apos, quot. Объявление общего экземпляра обязано предшествовать любой ссылке на него, которая появляется в значении по умолчанию в объявлении списка атрибутов.

Учтите, что, если экземпляры объявляются во внешнем поднаборе или во внешних экземплярах параметров, то непроверяющий процессор не обязательно читает и обрабатывает их объявления; для таких документов правилом является то, что экземпляр, который обязан быть объявлен, является правильно сформированным ограничением только тогда, когда standalone='yes'.

Ограничение правильности: Экземпляр Объявлен

В документе с внешним поднабором или внешними экземплярами параметров с "standalone='no'", Name, данное в ссылке экземпляра, обязано совпадать с именем в объявлении экземпляра. Для целей взаимодействия, правильные документы должны объявлять экземпляры amp, lt, gt, apos, quot в форме, специфицированной в разделе 4.6 Предопределённые Экземпляры. Объявление экземпляра параметра обязано предшествовать любой ссылке на него. Точно так же объявление общего экземпляра обязано предшествовать любому объявлению списка атрибутов, содержащему значение по умолчанию с прямой или косвенной ссылкой на этот общий экземпляр.

Ограничение правильной сформированности: Разбираемый Экземпляр

Ссылка экземпляра обязана не содержать имя неразбираемого экземпляра. Неразбираемые экземпляры могут иметь на себя ссылку только в значениях атрибутов, объявленных как тип ENTITY или ENTITIES.

Ограничение правильной сформированности: Нет Рекурсии

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

Ограничение правильной сформированности: в ОТД

Ссылки на экземпляр параметра могут появляться только в ОТД.

Примеры ссылок на символы и экземпляры:

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 Объявления экземпляров

[Определение: Экземпляры объявляются так:]

Entity Declaration\Объявление Экземпляра

[70]	`EntityDecl`	::=	`GEDecl \| PEDecl`
[71]	`GEDecl`	::=	`'<!ENTITY' S Name S EntityDef S? '>'`
[72]	`PEDecl`	::=	`'<!ENTITY' S '%' S Name S PEDef S? '>'`
[73]	`EntityDef`	::=	`EntityValue \| (ExternalID NDataDecl?)`
[74]	`PEDef`	::=	`EntityValue \| ExternalID`

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

4.2.1 Внутренние экземпляры

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

Внутренний экземпляр это разбираемый экземпляр.

Пример объявления внутреннего экземпляра:

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

4.2.2 Внешние экземпляры

[Определение: Если экземпляр не является внутренним, то он является внешним экземпляром, объявляемым так:]

External Entity Declaration\Объявление Внешнего Экземпляра

[75]	`ExternalID`	::=	`'SYSTEM' S SystemLiteral`
			`\| 'PUBLIC' S PubidLiteral S SystemLiteral`
[76]	`NDataDecl`	::=	`S 'NDATA' S Name`	[ОП: Объявленная Нотация]

Если NDataDecl присутствует, то это - общий неразбираемый экземпляр; в противном случае это - разбираемый экземпляр.

Ограничение правильности: Объявленная Нотация

Name обязано совпадать с объявленным именем нотации.

[Определение: SystemLiteral называется системным идентификатором экземпляра. Это ссылка URI (как определено в [IETF RFC 2396], обновлено в [IETF RFC 2732]), которая должна быть разыменована для получения ввода для процессора XML, чтобы построить замещающий текст экземпляра.] Для фрагмента идентификатора (начинающегося символом #) будет считаться ошибкой, если он будет частью системного идентификатора. Если только иное не даётся в информации за пределами данной спецификации (например, специальный тип элемента XML, определённый особым ОТД, или инструкция процесса, определённая особой спецификацией приложения), то относительные URI являются относительными к месту размещения того ресурса, внутри которого появляется объявление экземпляра. URI может, таким образом, быть относительным к экземпляру документа, к экземпляру, содержащему внешний поднабор ОТД, или к какому-либо внешнему экземпляру параметра.

URI-ссылки требуют кодирования и escap'ирования некоторых символов. Недопустимые символы включают все не-ASCII символы, плюс исключённые символы, перечисленные в Разделе 2.4 в [IETF RFC 2396], кроме символов знака номера (#) и знака процента (%) и символов квадратных скобок, вновь разрешённых в [IETF RFC 2732].
Недопустимые символы должна быть escap'ированы так :

Каждый недопустимый символ конвертируется в UTF-8 [IETF RFC 2279] как один или более байт.
Все восьмеричные, соответствующие недопустимому символу, escap'ируются URI escape-механизмом (то есть до %HH, где HH - это 16-ричная нотация байтового значения).
Оригинальный символ замещается результирующей последовательностью символов.

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

Примеры объявлений внешнего экземпляра:

<!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 Разбираемые экземпляры

4.3.1 Объявление текста

Каждый внешний разбираемый экземпляр должен начинаться с объявления текста.

Text Declaration\Объявление Текста

[77] TextDecl ::= '<?xml' VersionInfo? EncodingDecl S? '?>'

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

4.3.2 Правильно сформированные разбираемые экземпляры

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

Well-Formed External Parsed Entity\Правильно Сформированный Внешний Разбираемый Экземпляр

[78] extParsedEnt ::= TextDecl? content

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

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

4.3.3 Кодирование символов в экземплярах

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

Экземпляры, кодированные в UTF-16, обязаны начинаться с Byte Order Mark (Знака Байтового Порядка), описанного в Annex F [ISO/IEC 10646], Annex H [ISO/IEC 10646-2000], раздел 2.4 [Unicode] и раздел 2.7 [Unicode3] (символа ZERO WIDTH NO-BREAK SPACE/ НЕРАЗРЫВНЫЙ ПРОБЕЛ НУЛЕВОЙ ШИРИНЫ, #xFEFF). Это "подпись" кодировки, но не часть разметки или символьных данных документа XML. Процессоры XML обязаны уметь использовать этот символ для различения документов, кодированных в UTF-8 и UTF-16.

Хотя процессор XML должен читать только экземпляры в кодировках UTF-8 и UTF-16, известно, что повсюду используются другие кодировки, и для процессоров XML желательно уметь читать экземпляры, использующие эти (другие) кодировки. При отсутствии внешней информации о кодировке символов (такой как "шапки" MIME), разбираемые экземпляры, хранящиеся в кодировка, отличных от UTF-8 или UTF-16, обязаны начинаться с объявления текста (см. 4.3.1 Объявление Текста), содержащего объявление кодировки:

Encoding Declaration\Объявление Кодировки

[80]	`EncodingDecl`	::=	`S 'encoding' Eq ('"' EncName '"' \| "'" EncName "'" )`
[81]	`EncName`	::=	`[A-Za-z] ([A-Za-z0-9._] \| '-')*`	/ Имя кодировки содержит только символы латиницы /

В экземпляре документа объявление кодировки является частью объявления XML. EncName это название/имя используемой кодировки.

В объявлении кодировки значения "UTF-8", "UTF-16", "ISO-10646-UCS-2" и "ISO-10646-UCS-4" должны использоваться для различных кодировок и трансформаций Unicode / ISO/IEC 10646, значения "ISO-8859-1", "ISO-8859-2", ... "ISO-8859-n" (где n это номер части) должны использоваться для частей ISO 8859, а значения "ISO-2022-JP", "Shift_JIS" и "EUC-JP" должны использоваться для различных форм кодировок JIS X-0208-1997. Рекомендуется, чтобы кодировки символов, зарегистрированные (как charsets\наборы символов) в Internet Assigned Numbers Authority [IANA-CHARSETS], и отличающиеся от уже перечисленных, именовались с использованием их зарегистрированных имён; другие кодировки должны использовать имена, начинающиеся с префикса "x-". Процессоры XML должны подбирать имена кодировок символов нечувствительным к регистру способом и должны интерпретировать зарегистрированные IANA имена как кодировки, зарегистрированные в IANA для этих имён, или рассматривать их как неизвестные (от процессоров, разумеется, не требуется поддерживать все зарегистрированные IANA кодировки).

В отсутствие информации, предоставляемой внешним транспортным протоколом (например, HTTP или MIME), ошибочным для экземпляра, включая объявление кодировки, будет представление перед процессором XML в кодировке, отличной от именованной в объявлении, или использование экземпляром, не начинающимся Byte Order Mark либо объявлением кодировки, отличной от UTF-8. Заметьте, что, поскольку ASCII является поднабором UTF-8, обычные экземпляры ASCII не требуют в обязательном порядке наличия объявления кодировки.

Считается фатальной ошибкой, если TextDecl появится в ином месте, кроме начала внешнего экземпляра.

Считается фатальной ошибкой, если процессор XML обнаруживает экземпляр с кодировкой, которую невозможно обработать. Является фатальной ошибкой, если экземпляр XML определён (в значениях по умолчанию, в объявлении кодировки или высокоуровневым протоколом) в определённой кодировке, но содержит восьмеричные последовательности, которые не являются разрешёнными в данной кодировке. Будет также фатальной ошибкой, если экземпляр XML не содержит объявления кодировки, и его содержимое не является UTF-8 или UTF-16.

Примеры объявлений текста, содержащие объявления кодировки:

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

4.4 Обработка процессором XML экземпляров и ссылок

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

ссылка в содержимом: как ссылка где-либо после начального тэга и перед конечным тэгом элемента; соответствует нетерминальному содержимому.
ссылка в значении атрибута: как ссылка или в значении атрибута в начальном тэге, или как значение по умолчанию в объявлении атрибута; соответствует нетерминальному AttValue.
появляется как значение атрибута: как Name, не ссылка, появляющееся или как значение атрибута, который объявлен как тип ENTITY, или как одна из трёх разделённых пробелами лексем - в значении атрибута, который объявлен как тип ENTITIES.
ссылка в значении экземпляра: как ссылка в литеральном значении экземпляра в объявлении экземпляр параметра или внутреннего экземпляра; соответствует нетерминальному EntityValue.
ссылка в ОТД: как ссылка внутри внешнего или внутреннего поднабора ОТД, но вне EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral или содержимого игнорируемой секции условий (см. 3.4 Секции Условий).

	Тип Экземпляра				Символ
	Параметра	Внутренний Общий	Внешний Разбираемый Общий	Неразбираемый	Символ
ссылка в содержимом	не распознаётся	включён	включается, если проверяется	запрещён	включён
ссылка в значении атрибута	не распознаётся	включён в литерал	запрещён	запрещён	включён
появляется как значение атрибута	не распознаётся	запрещён	запрещён	уведомление	не распознаётся
ссылка в значении экземпляра	включён в литерал	пропущен	пропущен	запрещён	включён
ссылка в ОТД	включён как экземпляр параметра	запрещён	запрещён	запрещён	запрещён

4.4.1 Не распознаётся

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

4.4.2 Включён

[Определение: Экземпляр включён, если его замещающий текст запрашивается и обрабатывается вместо самой ссылки, если она даже и является частью документа в том месте, где ссылка была распознана.] Замещающий текст может содержать и символьные данные, и (за исключением экземпляров параметров) разметку, которая должна распознаваться обычным способом. (Строка "AT&T;" расширяется до "AT&T;" и оставшийся амперсанд не распознаётся как ограничитель ссылки экземпляра.) Ссылка на символ включается, если символ обрабатывается вместо самой ссылки.

4.4.3 Включается, если проверяется

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

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

4.4.4 Запрещён

Следующее запрещено и вызывает фатальные ошибки:

появление ссылки на неразбираемый экземпляр;
появление символьной ссылки общего экземпляра в ОТД, за исключением EntityValue или AttValue;
ссылка на внешний экземпляр в значении атрибута.

4.4.5 Включён в литерал

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

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

а это - нет:

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

4.4.6 Уведомление

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

4.4.7 Пропущен

Если ссылка на общий экземпляр появляется в EntityValue в объявлении экземпляра, то он пропускается и остаётся как есть.

4.4.8 Включён как экземпляр параметра

Точно так же, как и в случае с внешними разбираемыми экземплярами, экземпляры параметров должны быть лишь включены, если проверяются. Если ссылка экземпляра параметра распознаётся в ОТД и включается, то его (экземпляра) замещающий текст расширяется путём присоединения одного ведущего и одного ведомого пробела (#x20); целью является - ограничить для замещающего текста экземпляра параметра возможность содержать интегральное число грамматических лексем в ОТД. Это поведение не применяется к ссылкам экземпляра параметра в значениях экземпляра; это описано в 4.4.5 Включён в литерал.

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 Предопределённые экземпляры

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

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

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

4.7 Объявления нотации

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

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

Notation Declarations\Объявления Нотации

[82]	`NotationDecl`	::=	`'<!NOTATION' S Name S (ExternalID \| PublicID) S? '>'`	[ОП: Уникальное Имя Нотации]
[83]	`PublicID`	::=	`'PUBLIC' S PubidLiteral`

Ограничение правильности: Уникальное Имя Нотации

Только одно объявление нотации может объявить данное Имя/Name.

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

4.8 Экземпляр документа

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

5 Соответствие

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

Соответствующие процессоры XML делятся на два класса: проверяющие и непроверяющие.

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

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

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

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

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

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

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

6 Нотация

Формальная грамматика XML даётся в данной спецификации с использованием нотации Extended Backus-Naur Form (EBNF). Каждое правило грамматики определяет один символ в такой форме:

symbol ::= expression

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

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

#xN: где N это 16-ричное целое, выражение соответствует символу из ISO/IEC 10646, каноническое значение кода которого (UCS-4), если интерпретировать его как беззнаковое двоичное число, имеет указанное значение. Количество ведущих нулей в форме #xN не имеет значения; количество ведущих нулей в соответствующем значении кода управляется используемой кодировкой символов и не имеет значения в XML.
[a-zA-Z], [#xN-#xN]: соответствует Char со значением в обозначенном диапазоне(ах) (включительно).
[abc], [#xN#xN#xN]: соответствует Char со значением из перечисленных символов. Перечисления и диапазоны могут быть объединены внутри одного набора скобок.
[^a-z], [^#xN-#xN]: соответствует Char со значением вне указанного диапазона.
[^abc], [^#xN#xN#xN]: соответствует Char со значением не из указанных символов. Перечисления и диапазоны запрещённых значений могут быть объединены внутри одного набора скобок.
"string": соответствует литерной строке, соответствующей той, которая дана внутри двойных кавычек.
'string': соответствует литерной строке, соответствующей той, которая дана внутри одинарных кавычек.

Эти символы могут комбинироваться для составления более сложных блоков, как показано ниже, где A и B обозначают простые выражения:

(expression/выражение): expression рассматривается как модуль и может комбинироваться так, как описано в этом списке.
A?: соответствует A или ничему; необязательное A (по выбору).
A B: соответствует A с последующим B. Этот оператор имеет более высокий приоритет, чем выбор; таким образом, A B | C D идентично (A B) | (C D).
A | B: соответствует A или B, но не обоим вместе.
A - B: соответствует любой строке, которая соответствует A, но не соответствует B.
A+: соответствует одному или более вхождению A. Конкатенация имеет более высокий приоритет, чем выбор; таким образом, A+ | B+ идентично (A+) | (B+).
A*: соответствует 0 или более вхождений A. Конкатенация имеет более высокий приоритет, чем выбор; таким образом A* | B* идентично (A*) | (B*).

Другие нотации, используемые в продукциях:

/* ... */: комментарий.
[ wfc: ... ]: well-formedness constraint- ограничение правильной сформированности; идентифицирует по имени ограничение правильно сформированных документов, ассоциированных с продукцией.
[ vc: ... ]: validity constraint - ограничение правильности; идентифицирует по имени ограничение правильных (верных) документов, ассоциированных с продукцией.

A Ссылки

A.1 Нормативные Ссылки

IANA-CHARSETS: (Internet Assigned Numbers Authority) Official Names for Character Sets, ed. Keld Simonsen et al. См. ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
IETF RFC 1766: IETF (Internet Engineering Task Force). RFC 1766: Tags for the Identification of Languages, ed. H. Alvestrand. 1995. См. http://www.ietf.org/rfc/rfc1766.txt.)
ISO/IEC 10646: ISO (International Organization for Standardization). ISO/IEC 10646-1993 (E). Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 1993 (плюс исправления с AM 1 по AM 7).
ISO/IEC 10646-2000: ISO (International Organization for Standardization). ISO/IEC 10646-1:2000. Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [Geneva]: International Organization for Standardization, 2000.
Unicode: The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.
Unicode3: The Unicode Consortium. The Unicode Standard, Version 3.0. Reading, Mass.: Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5.

A.2 Прочие Ссылки

Aho/Ullman: Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986, rpt. corr. 1988.
Berners-Lee et al.: Berners-Lee, T., R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics. 1997. (Работа не закончена; смотри обновления к RFC1738.)
Brüggemann-Klein: Brüggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Faculty of Mathematics at the University of Freiburg, 1993.
(См. ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)
Brüggemann-Klein and Wood: Brüggemann-Klein, Anne, and Derick Wood. Deterministic Regular Languages. Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991. Extended abstract in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag, Berlin 1992. Lecture Notes in Computer Science 577. Полная версия озаглавлена One-Unambiguous Regular Languages in Information and Computation 140 (2): 229-253, февраль 1998.
Clark: James Clark. Comparison of SGML and XML. См. http://www.w3.org/TR/NOTE-sgml-xml-971215.
IANA-LANGCODES: (Internet Assigned Numbers Authority) Registry of Language Tags, ed. Keld Simonsen et al. (См. http://www.isi.edu/in-notes/iana/assignments/languages/.)
IETF RFC2141: IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ed. R. Moats. 1997.
(См. http://www.ietf.org/rfc/rfc2141.txt.)
IETF RFC 2279: IETF (Internet Engineering Task Force). RFC 2279: UTF-8, a transformation format of ISO 10646, ed. F. Yergeau, 1998. (См. http://www.ietf.org/rfc/rfc2279.txt.)
IETF RFC 2376: IETF (Internet Engineering Task Force). RFC 2376: XML Media Types. ed. E. Whitehead, M. Murata. 1998. (См. http://www.ietf.org/rfc/rfc2376.txt.)
IETF RFC 2396: IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 1998.
(См. http://www.ietf.org/rfc/rfc2396.txt.)
IETF RFC 2732: IETF (Internet Engineering Task Force). RFC 2732: Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. 1999. (См. http://www.ietf.org/rfc/rfc2732.txt.)
IETF RFC 2781: IETF (Internet Engineering Task Force). RFC 2781: UTF-16, an encoding of ISO 10646, ed. P. Hoffman, F. Yergeau. 2000. (См. http://www.ietf.org/rfc/rfc2781.txt.)
ISO 639: (International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: International Organization for Standardization, 1988.
ISO 3166: (International Organization for Standardization). ISO 3166-1:1997 (E). Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes [Geneva]: International Organization for Standardization, 1997.
ISO 8879: ISO (International Organization for Standardization). ISO 8879:1986(E). Information processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML). First edition -- 1986-10-15. [Geneva]: International Organization for Standardization, 1986.
ISO/IEC 10744: ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology -- Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: International Organization for Standardization, 1992. Extended Facilities Annexe. [Geneva]: International Organization for Standardization, 1996.
WEBSGML: ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology -- Document Description and Processing Languages. [Geneva]: International Organization for Standardization, 1998. (См. http://www.sgmlsource.com/8879rev/n0029.htm.)
XML Names: Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999.
(См. http://www.w3.org/TR/REC-xml-names/.)

B Классы символов

Следуя характеристикам, определённым в стандарте Unicode, символы классифицируются как базовые символы (помимо прочих, они содержат алфавитные символы латинского шрифта), идеографические символы и комбинированные символы (помимо прочих, этот класс содержит большинство диакритических). Цифры и расширители также выделены.

Characters\Символы

[84]	`Letter`	::=	`BaseChar \| Ideographic`
[85]	`BaseChar`	::=	[#x0041-#x005A] \| [#x0061-#x007A] \| [#x00C0-#x00D6] \| [#x00D8-#x00F6] \| [#x00F8-#x00FF] \| [#x0100-#x0131] \| [#x0134-#x013E] \| [#x0141-#x0148] \| [#x014A-#x017E] \| [#x0180-#x01C3] \| [#x01CD-#x01F0] \| [#x01F4-#x01F5] \| [#x01FA-#x0217] \| [#x0250-#x02A8] \| [#x02BB-#x02C1] \| #x0386 \| [#x0388-#x038A] \| #x038C \| [#x038E-#x03A1] \| [#x03A3-#x03CE] \| [#x03D0-#x03D6] \| #x03DA \| #x03DC \| #x03DE \| #x03E0 \| [#x03E2-#x03F3] \| [#x0401-#x040C] \| [#x040E-#x044F] \| [#x0451-#x045C] \| [#x045E-#x0481] \| [#x0490-#x04C4] \| [#x04C7-#x04C8] \| [#x04CB-#x04CC] \| [#x04D0-#x04EB] \| [#x04EE-#x04F5] \| [#x04F8-#x04F9] \| [#x0531-#x0556] \| #x0559 \| [#x0561-#x0586] \| [#x05D0-#x05EA] \| [#x05F0-#x05F2] \| [#x0621-#x063A] \| [#x0641-#x064A] \| [#x0671-#x06B7] \| [#x06BA-#x06BE] \| [#x06C0-#x06CE] \| [#x06D0-#x06D3] \| #x06D5 \| [#x06E5-#x06E6] \| [#x0905-#x0939] \| #x093D \| [#x0958-#x0961] \| [#x0985-#x098C] \| [#x098F-#x0990] \| [#x0993-#x09A8] \| [#x09AA-#x09B0] \| #x09B2 \| [#x09B6-#x09B9] \| [#x09DC-#x09DD] \| [#x09DF-#x09E1] \| [#x09F0-#x09F1] \| [#x0A05-#x0A0A] \| [#x0A0F-#x0A10] \| [#x0A13-#x0A28] \| [#x0A2A-#x0A30] \| [#x0A32-#x0A33] \| [#x0A35-#x0A36] \| [#x0A38-#x0A39] \| [#x0A59-#x0A5C] \| #x0A5E \| [#x0A72-#x0A74] \| [#x0A85-#x0A8B] \| #x0A8D \| [#x0A8F-#x0A91] \| [#x0A93-#x0AA8] \| [#x0AAA-#x0AB0] \| [#x0AB2-#x0AB3] \| [#x0AB5-#x0AB9] \| #x0ABD \| #x0AE0 \| [#x0B05-#x0B0C] \| [#x0B0F-#x0B10] \| [#x0B13-#x0B28] \| [#x0B2A-#x0B30] \| [#x0B32-#x0B33] \| [#x0B36-#x0B39] \| #x0B3D \| [#x0B5C-#x0B5D] \| [#x0B5F-#x0B61] \| [#x0B85-#x0B8A] \| [#x0B8E-#x0B90] \| [#x0B92-#x0B95] \| [#x0B99-#x0B9A] \| #x0B9C \| [#x0B9E-#x0B9F] \| [#x0BA3-#x0BA4] \| [#x0BA8-#x0BAA] \| [#x0BAE-#x0BB5] \| [#x0BB7-#x0BB9] \| [#x0C05-#x0C0C] \| [#x0C0E-#x0C10] \| [#x0C12-#x0C28] \| [#x0C2A-#x0C33] \| [#x0C35-#x0C39] \| [#x0C60-#x0C61] \| [#x0C85-#x0C8C] \| [#x0C8E-#x0C90] \| [#x0C92-#x0CA8] \| [#x0CAA-#x0CB3] \| [#x0CB5-#x0CB9] \| #x0CDE \| [#x0CE0-#x0CE1] \| [#x0D05-#x0D0C] \| [#x0D0E-#x0D10] \| [#x0D12-#x0D28] \| [#x0D2A-#x0D39] \| [#x0D60-#x0D61] \| [#x0E01-#x0E2E] \| #x0E30 \| [#x0E32-#x0E33] \| [#x0E40-#x0E45] \| [#x0E81-#x0E82] \| #x0E84 \| [#x0E87-#x0E88] \| #x0E8A \| #x0E8D \| [#x0E94-#x0E97] \| [#x0E99-#x0E9F] \| [#x0EA1-#x0EA3] \| #x0EA5 \| #x0EA7 \| [#x0EAA-#x0EAB] \| [#x0EAD-#x0EAE] \| #x0EB0 \| [#x0EB2-#x0EB3] \| #x0EBD \| [#x0EC0-#x0EC4] \| [#x0F40-#x0F47] \| [#x0F49-#x0F69] \| [#x10A0-#x10C5] \| [#x10D0-#x10F6] \| #x1100 \| [#x1102-#x1103] \| [#x1105-#x1107] \| #x1109 \| [#x110B-#x110C] \| [#x110E-#x1112] \| #x113C \| #x113E \| #x1140 \| #x114C \| #x114E \| #x1150 \| [#x1154-#x1155] \| #x1159 \| [#x115F-#x1161] \| #x1163 \| #x1165 \| #x1167 \| #x1169 \| [#x116D-#x116E] \| [#x1172-#x1173] \| #x1175 \| #x119E \| #x11A8 \| #x11AB \| [#x11AE-#x11AF] \| [#x11B7-#x11B8] \| #x11BA \| [#x11BC-#x11C2] \| #x11EB \| #x11F0 \| #x11F9 \| [#x1E00-#x1E9B] \| [#x1EA0-#x1EF9] \| [#x1F00-#x1F15] \| [#x1F18-#x1F1D] \| [#x1F20-#x1F45] \| [#x1F48-#x1F4D] \| [#x1F50-#x1F57] \| #x1F59 \| #x1F5B \| #x1F5D \| [#x1F5F-#x1F7D] \| [#x1F80-#x1FB4] \| [#x1FB6-#x1FBC] \| #x1FBE \| [#x1FC2-#x1FC4] \| [#x1FC6-#x1FCC] \| [#x1FD0-#x1FD3] \| [#x1FD6-#x1FDB] \| [#x1FE0-#x1FEC] \| [#x1FF2-#x1FF4] \| [#x1FF6-#x1FFC] \| #x2126 \| [#x212A-#x212B] \| #x212E \| [#x2180-#x2182] \| [#x3041-#x3094] \| [#x30A1-#x30FA] \| [#x3105-#x312C] \| [#xAC00-#xD7A3]
[86]	`Ideographic`	::=	`[#x4E00-#x9FA5] \| #x3007 \| [#x3021-#x3029]`
[87]	`CombiningChar`	::=	[#x0300-#x0345] \| [#x0360-#x0361] \| [#x0483-#x0486] \| [#x0591-#x05A1] \| [#x05A3-#x05B9] \| [#x05BB-#x05BD] \| #x05BF \| [#x05C1-#x05C2] \| #x05C4 \| [#x064B-#x0652] \| #x0670 \| [#x06D6-#x06DC] \| [#x06DD-#x06DF] \| [#x06E0-#x06E4] \| [#x06E7-#x06E8] \| [#x06EA-#x06ED] \| [#x0901-#x0903] \| #x093C \| [#x093E-#x094C] \| #x094D \| [#x0951-#x0954] \| [#x0962-#x0963] \| [#x0981-#x0983] \| #x09BC \| #x09BE \| #x09BF \| [#x09C0-#x09C4] \| [#x09C7-#x09C8] \| [#x09CB-#x09CD] \| #x09D7 \| [#x09E2-#x09E3] \| #x0A02 \| #x0A3C \| #x0A3E \| #x0A3F \| [#x0A40-#x0A42] \| [#x0A47-#x0A48] \| [#x0A4B-#x0A4D] \| [#x0A70-#x0A71] \| [#x0A81-#x0A83] \| #x0ABC \| [#x0ABE-#x0AC5] \| [#x0AC7-#x0AC9] \| [#x0ACB-#x0ACD] \| [#x0B01-#x0B03] \| #x0B3C \| [#x0B3E-#x0B43] \| [#x0B47-#x0B48] \| [#x0B4B-#x0B4D] \| [#x0B56-#x0B57] \| [#x0B82-#x0B83] \| [#x0BBE-#x0BC2] \| [#x0BC6-#x0BC8] \| [#x0BCA-#x0BCD] \| #x0BD7 \| [#x0C01-#x0C03] \| [#x0C3E-#x0C44] \| [#x0C46-#x0C48] \| [#x0C4A-#x0C4D] \| [#x0C55-#x0C56] \| [#x0C82-#x0C83] \| [#x0CBE-#x0CC4] \| [#x0CC6-#x0CC8] \| [#x0CCA-#x0CCD] \| [#x0CD5-#x0CD6] \| [#x0D02-#x0D03] \| [#x0D3E-#x0D43] \| [#x0D46-#x0D48] \| [#x0D4A-#x0D4D] \| #x0D57 \| #x0E31 \| [#x0E34-#x0E3A] \| [#x0E47-#x0E4E] \| #x0EB1 \| [#x0EB4-#x0EB9] \| [#x0EBB-#x0EBC] \| [#x0EC8-#x0ECD] \| [#x0F18-#x0F19] \| #x0F35 \| #x0F37 \| #x0F39 \| #x0F3E \| #x0F3F \| [#x0F71-#x0F84] \| [#x0F86-#x0F8B] \| [#x0F90-#x0F95] \| #x0F97 \| [#x0F99-#x0FAD] \| [#x0FB1-#x0FB7] \| #x0FB9 \| [#x20D0-#x20DC] \| #x20E1 \| [#x302A-#x302F] \| #x3099 \| #x309A
[88]	`Digit`	::=	`[#x0030-#x0039] \| [#x0660-#x0669] \| [#x06F0-#x06F9] \| [#x0966-#x096F] \| [#x09E6-#x09EF] \| [#x0A66-#x0A6F] \| [#x0AE6-#x0AEF] \| [#x0B66-#x0B6F] \| [#x0BE7-#x0BEF] \| [#x0C66-#x0C6F] \| [#x0CE6-#x0CEF] \| [#x0D66-#x0D6F] \| [#x0E50-#x0E59] \| [#x0ED0-#x0ED9] \| [#x0F20-#x0F29]`
[89]	`Extender`	::=	`#x00B7 \| #x02D0 \| #x02D1 \| #x0387 \| #x0640 \| #x0E46 \| #x0EC6 \| #x3005 \| [#x3031-#x3035] \| [#x309D-#x309E] \| [#x30FC-#x30FE]`

Классы символов, определённые здесь, могут происходить из базы символов Unicode 2.0 следующим образом:

Начальные символы имени обязаны быть одной из следующих категорий: Ll, Lu, Lo, Lt, Nl.
Другие символы имени (кроме начальных символов имени) обязаны быть одной из следующих категорий: Mc, Me, Mn, Lm или Nd.
Символы в области совместимости (т.е. с кодом символа больше, чем #xF900, и меньше, чем #xFFFE) в именах XML не допускаются.
Символы, имеющие декомпозицию шрифта или совместимости (т.е. те, которые имеют "compatibility formatting tag/форматирующий тэг совместимости" в поле 5 базы данных-- обозначенные в поле 5 начальной "<") не допускаются.
Следующие символы считаются начальными символами имени, но не символами имени, поскольку файл свойств классифицирует их как алфавитные: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.
Символы #x20DD-#x20E0 исключены (в соответствии с Unicode 2.0, раздел 5.14).
Символ #x00B7 классифицирован как расширитель, поскольку список свойств идентифицирует его именно так.
Символ #x0387 добавлен как символ имени, поскольку #x00B7 является его каноническим эквивалентом.
Символы ':' и '_' разрешены в качестве начальных символов имени.
Символы '-' и '.' разрешены в качестве символов имени.

C XML и SGML (ненормативное)

XML создан как поднабор SGML, поэтому каждый документ XML должен быть документом, соответствующим SGML. Детальное сравнение дополнительных ограничений, которые XML помещает в документ, и ограничений SGML см. в [Clark].

D Развёртывание ссылок на символы и экземпляры (ненормативное)

Это приложение содержит примеры, иллюстрирующие последовательность распознавания и развёртывания ссылок на символы и экземпляры, как специфицировано в разделе 4.4 Обработка процессором XML Экземпляров и Ссылок.

Если ОТД содержит объявление

<!ENTITY example "<p>Амперсанд (&#38;#38;) может быть escape'ирован
численно (&#38;#38;#38;) или общей мнемоникой (&amp;amp;).</p>" >

то процессор XML будет распознавать мнемоники при разборе объявления экземпляра и разрешать их перед тем, как сохранить следующую строку как значение экземпляра "example":

<p>Амперсанд (&#38;) может быть escape'ирован
численно (&#38;#38;) или общей мнемоникой (&amp;amp;).</p>

Ссылка на "&example;" в документе вызовет повторный разбор текста, во время которого стартовый и конечный тэги элемента p будут распознаны, и эти три ссылки будут распознаны и развёрнуты, давая в результате элемент p со следующим содержимым (все данные, никаких разграничителей и разметки):

Амперсанд (&) может быть escape'ирован
численно (&#38;) или общей мнемоникой (&amp;).

Более сложный пример иллюстрирует правила и эффект от их применения. Здесь номера строк даны лишь для ориентировки:

1 <?xml version='1.0'?>
2 <!DOCTYPE test [
3 <!ELEMENT test (#PCDATA) >
4 <!ENTITY % xx '&#37;zz;'>
5 <!ENTITY % zz '&#60;!ENTITY tricky "error-prone" >' >
6 %xx;
7 ]>
8 <test>This sample shows a &tricky; method.</test>

Здесь происходит следующее:

в строке 4 ссылка на символ 37 развёртывается сразу, а экземпляр параметра - "xx" - сохраняется в таблице символов со значением "%zz;". Поскольку замещающий текст повторно не сканируется, ссылка на экземпляр параметра "zz" не распознаётся. (И будет ошибкой, если распознаётся, поскольку "zz" ещё не объявлена.)
в строке 5 ссылка на символ "<" развёртывается сразу, а экземпляр параметра - "zz" - сохраняется замещающим текстом "<!ENTITY tricky "error-prone" >", что является правильно сформированным объявлением экземпляра.
в строке 6 ссылка на "xx" распознаётся, и замещающий текст "xx" (именованного как "%zz;") разбирается. Ссылка на "zz" распознаётся в свою очередь, и замещающий текст ("<!ENTITY tricky "error-prone" >") разбирается. Общий экземпляр "tricky" теперь объявлен с замещающим текстом "error-prone".
в строке 8 ссылка на общий экземпляр "tricky" распознаётся и развёртывается, поэтому полное содержимое элемента test является самоописывающей (и неграмматической) строкой This sample shows a error-prone method.

E Детерминистические модели содержимого (ненормативное)

Как отмечено в 3.2.1 Содержимом Элемента, необходимо, чтобы модели содержимого в объявлении типа элемента были детерминистическими. Это требование введено для совместимости с SGML (которое называет детерминистические модели содержимого "недвусмысленными"); создание процессоров XML с использованием систем SGML может отмечать недетерминистические модели содержимого как ошибочные.

Например, модель содержимого ((b, c) | (b, d)) - недетерминистическая, потому что, при данном b, процессор XML не может знать, которое b в модели соответствует, без того чтобы не просмотреть всё сначала и выяснить, какой элемент идёт после b. В данном случае, две ссылки на b могут быть сжаты до одиночной, делая модель такой: (b, (c | d)). Начальное b теперь точно соответствует одному имени в модели содержимого. Процессору не нужно возвращаться к началу, что посмотреть, а что идёт затем; c или d могут быть приняты.

Более формально: автоматизация окончательного состояния может быть сконструирована из модели содержимого с использование стандартных алгоритмов, например, алгоритм 3.5 в разделе 3.9 в Aho, Sethi и Ullman [Aho/Ullman]. Во многих таких алгоритмах, добавочный набор конструируется для каждой позиции в регулярном выражении (т.е. для каждого узла-листа в дереве синтаксиса регулярного выражения); если какая-либо позиция имеет добавочный набор, в котором более чем одна добавочная позиция помечена тем же самым именем типа элемента, то модель содержимого ошибочна, и о неё может быть выведено сообщение как об ошибочной.

Существуют алгоритмы, которые позволяют автоматически редуцировать многие, но не все, недетерминистические модели содержимого до эквивалентных детерминистических моделей; см. Brüggemann-Klein 1991 [Brüggemann-Klein].

F Автоопределение кодировок символов (ненормативное)

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

F.1 Определение без внешней информации о кодировке

Поскольку не каждый экземпляр XML, сопровождаемый внешней информацией о кодировке и не в кодировке UTF-8 или UTF-16, обязан начинаться объявлением кодировки XML, когда первые символы должны быть '<?xml', и каждый соответствующий процессор может определить, после двух или четырёх 8-ричных на входе, который из следующих вариантов применить.
При чтении этого списка, может помочь знание того, что в UCS-4 '<' это "#x0000003C" и '?' это "#x0000003F" и что Byte Order Mark/Знак Порядка Байтов требуемый потоками данных UTF-16, это "#xFEFF". Нотация ## используется для обозначения любого байтового значения, за исключением того, что два последовательных ## не могут быть оба 00.

С Byte Order Mark:

`00 00 FE FF`	UCS-4, big-endian machine (1234 order)
`FF FE 00 00`	UCS-4, little-endian machine (4321 order)
`00 00 FF FE`	UCS-4, неиспользуемый 8-ричный порядок (2143)
`FE FF 00 00`	UCS-4, неиспользуемый 8-ричный порядок (3412)
`FE FF ## ##`	UTF-16, big-endian
`FF FE ## ##`	UTF-16, little-endian
`EF BB BF`	UTF-8

Без Byte Order Mark:

`00 00 00 3C`	UCS-4 или другая кодировка с 32-битрым модулем кода и символы ASCII, кодированные значения ASCII, в, соответственно, big-endian (1234), little-endian (4321) и двух неиспользуемых порядках байтов (2143 и 3412). Объявление кодировки обязано быть прочитано для того, чтобы определить, какая из UCS-4 или других поддерживаемых 32-битных кодировок применяется.
`3C 00 00 00`
`00 00 3C 00`
`00 3C 00 00`
`00 3C 00 3F`	UTF-16BE, или big-endian ISO-10646-UCS-2, или другая кодировка с 16-битным модулем кода в порядке big-endian и символы ASCII, кодированные как значения ASCII (объявление кодировки обязано быть прочитано, чтобы определить, которая ...)
`3C 00 3F 00`	UTF-16LE, или little-endian ISO-10646-UCS-2, или другая кодировка с 16-битным модулем кода в порядке little-endian и символы ASCII, кодированные как значения ASCII (объявление кодировки обязано быть прочитано, чтобы определить, которая ...)
`3C 3F 78 6D`	UTF-8, ISO 646, ASCII, некоторая часть ISO 8859, Shift-JIS, EUC или какой-либо другой 7-битной, 8-битной или смешанной ширины кодировка, которая гарантирует, что символы ASCII имеют свои нормальные позиции, ширину и значения; объявление действующей кодировки обязано быть прочитано для того, чтобы определить, какая из них применена, но, поскольку все эти кодировки используют одни и те же битовые последовательности для соответствующих символов ASCII, объявление кодировки само может быть надёжно прочитано
`4C 6F A7 94`	EBCDIC (в некотором смысле; полное объявление кодировки обязано быть прочитано, чтобы сказать, какая кодовая страница используется)
Other\Другая	UTF-8 без объявления кодировки, иначе лэйбл с потока данных будет снят (испытывая недостаток наличия необходимого объявления кодировки), поток данных повреждён, фрагментарен или заключён в упаковку какого-либо вида

Примечание:

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

Этот уровень автоопределения достаточен для того, чтобы читать объявления кодировки XML и разбирать идентификатор кодировки символов, который пока ещё необходим для различения отдельных членов каждого семейства кодировок (например, для вызова UTF-8 из 8859 и частей 8859 одной из другой, или для различения используемой специфической кодовой страницы EBCDIC, и т.д.).

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

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

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

F.2 Приоритеты при наличии внешней информации о кодировке

Второй возможный вариант - это когда экземпляр XML сопровождается информацией о кодировке, как в некоторых файловых системах и некоторых сетевых протоколах. Если доступны несколько источников информации, их относительные приоритеты и предпочтительные методы разрешения конфликтов должны быть специфицированы как часть высокоуровневого протокола, используемого для вывода XML. Более конкретно смотрите, пожалуйста, [IETF RFC 2376] (или её последователей), которая определяет text/xml и application/xml MIME-типы и даёт определённые советы по использованию.
В целях взаимодействия, однако, рекомендуется следовать данному правилу:

Если экземпляр XML находится в файле, то Byte-Order Mark и объявление кодировки используются (если имеются) для определения кодировки символов.

G W3C XML Working Group (ненормативное)

Эта спецификация была подготовлена к публикации и одобрена W3C XML Working Group (WG)/Рабочей Группой. Одобрение WG данной спецификации не обязательно означает, что все члены WG голосовали за её одобрение.

Действующие и бывшие члены XML WG:

Jon Bosak, Sun (Председатель)
James Clark (Техническое Руководство)
Tim Bray, Textuality and Netscape (Соредактор XML)
Jean Paoli, Microsoft (Соредактор XML)
C. M. Sperberg-McQueen, U. of Ill. (Соредактор XML)
Dan Connolly, W3C (Координатор W3C)
Paula Angerstein, Texcel
Steve DeRose, INSO
Dave Hollander, HP
Eliot Kimber, ISOGEN
Eve Maler, ArborText
Tom Magliery, NCSA
Murray Maloney, SoftQuad, Grif SA, Muzmo and Veo Systems
MURATA Makoto (FAMILY Given), Fuji Xerox Information Systems
Joel Nava, Adobe
Conleth O'Connell, Vignette
Peter Sharpe, SoftQuad
John Tigue, DataChannel

H W3C XML Core Group (ненормативное)

Вторая редакция данной спецификации была подготовлена W3C XML Core Working Group (WG). Членами WG, на время публикации данной редакции, были:

Paula Angerstein, Vignette
Daniel Austin, Ask Jeeves
Tim Boland
Allen Brown, Microsoft
Dan Connolly, W3C (Staff Contact)
John Cowan, Reuters Limited
John Evdemon, XMLSolutions Corporation
Paul Grosso, Arbortext (Сопредседатель)
Arnaud Le Hors, IBM (Сопредседатель)
Eve Maler, Sun Microsystems (Редактор Второго Издания)
Jonathan Marsh, Microsoft
MURATA Makoto (FAMILY Given), IBM
Mark Needleman, Data Research Associates
David Orchard, Jamcracker
Lew Shannon, NCR
Richard Tobin, University of Edinburgh
Daniel Veillard, W3C
Dan Vint, Lexica
Norman Walsh, Sun Microsystems
François Yergeau, Alis Technologies (Редактор Списка Опечаток)
Kongyi Zhou, Oracle

I Примечания о вариантах (ненормативное)

Второе Издание было кодировано в XMLspec DTD (для которого имеется соответствующая документация). Версии HTML были сделаны с использованием комбинации таблиц стилей XSLT xmlspec.xsl, diffspec.xsl и REC-xml-2e.xsl. PDF-версия была создана с возможностью html2ps и distiller-программ.

РќРµСЃСѓС‰РµСЃС‚РІСѓСЋС‰Р°СЏ СЃС‚СЂР°РЅРёС†Р°

Расширяемый Язык Разметки (XML) 1.0 (Второе Издание)

Рекомендации W3C от 6 октября 2000 г.

Резюме

Статус данного документа

Содержание

Приложения

1 Введение

1.1 Происхождение и цели создания

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

2 Документы

2.1 Правильно сформированные документы XML

Document\Документ

2.2 Символы

Character Range\Диапазон символов

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

White Space\Пробел

Names and Tokens\Имена и Лексемы

Literals\Литеры

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

Character Data\Символьные Данные

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

Comments/Комментарии

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

Processing Instructions\Инструкции Процесса

2.7 Разделы CDATA

CDATA Sections/Разделы CDATA

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

Prolog\Пролог

Document Type Definition\Определение Типа Документа

External Subset\Внешний Поднабор

2.9 Отдельное объявление документа

Standalone Document Declaration\Отдельное Объявление Документа

2.10 Обработка пробелов

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

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

3 Логические структуры

Element\Элемент

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

Start-tag\Начальный тэг

End-tag\Конечный Тэг

Content of Elements\Содержимое Элемента

Tags for Empty Elements\Тэги пустых Элементов

3.2 Объявления типа элемента

Element Type Declaration\Объявление Типа Элемента

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

Element-content Models\Модели Содержимого Элемента

3.2.2 Смешанное содержимое

Mixed-content Declaration\Объявление Смешанного Содержимого

3.3 Объявления списка атрибутов

Attribute-list Declaration\Объявление Списка Атрибутов

3.3.1 Типы атрибутов

Attribute Types\Типы Атрибутов

Enumerated Attribute Types\Типы Перечисляемых Атрибутов

3.3.2 Значения по умолчанию для атрибута

Attribute Defaults\Значения по Умолчанию

3.3.3 Нормализация значения атрибута

3.4 Разделы условий

Conditional Section\Разделы Условий

4 Физические структуры

4.1 Ссылки символов и экземпляров

Character Reference\Ссылка Символа

Entity Reference\Ссылки Экземпляра

4.2 Объявления экземпляров

Entity Declaration\Объявление Экземпляра

4.2.1 Внутренние экземпляры

4.2.2 Внешние экземпляры

External Entity Declaration\Объявление Внешнего Экземпляра

4.3 Разбираемые экземпляры

4.3.1 Объявление текста

Text Declaration\Объявление Текста

4.3.2 Правильно сформированные разбираемые экземпляры

Well-Formed External Parsed Entity\Правильно Сформированный Внешний Разбираемый Экземпляр

4.3.3 Кодирование символов в экземплярах

Encoding Declaration\Объявление Кодировки

4.4 Обработка процессором XML экземпляров и ссылок

4.4.1 Не распознаётся

4.4.2 Включён

4.4.3 Включается, если проверяется

4.4.4 Запрещён

Расширяемый Язык Разметки (XML) 1.0
(Второе Издание)