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

IANA-CHARSETS (Internet Assigned Numbers Authority) Официальные названия для наборов символов, редактор Keld Simonsen и другие. См. . IETF RFC 1766 IETF (Internet Engineering Task Force). RFC 1766: Тэги для идентификации языков, редактор H. Alvestrand. 1995. (см. .) 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. Стандарт Unicode, версия 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996. Unicode3 The Unicode Consortium. Стандарт Unicode, версия 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, откорректированный репринт 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. (см. .) 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, February 1998. Clark James Clark. Сравнение SGML и XML. См. . IANA-LANGCODES (Internet Assigned Numbers Authority) Registry of Language Tags, редактор Keld Simonsen и другие (см. .) IETF RFC2141 IETF (Internet Engineering Task Force). RFC 2141: Синтаксис URN, редактор R. Moats. 1997. (см. .) IETF RFC 2279 IETF (Internet Engineering Task Force). RFC 2279: UTF-8, a transformation format of ISO 10646, редактор F. Yergeau, 1998. (см. .) IETF RFC 2376 IETF (Internet Engineering Task Force). RFC 2376: XML Media Types. редакция 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. (см. .) 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. (см. .) IETF RFC 2781 IETF (Internet Engineering Task Force). RFC 2781: UTF-16, an encoding of ISO 10646, редакция 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). Первая редакция -- 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. (см. .) XML Names Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (см. .)

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

Приводимые далее определения были представлены в стандарте Unicode. Все символы делятся на базовые символы (BaseChar, наряду с прочим сюда включены буквы латинского алфавита), идеографические символы (Ideographic), комбинированные символы (CombiningChar, в последнюю группу попадает также большинство диакритических символов). Выделяются также цифры (Digit) и расширения (Extender).

C XML и SGML (Пояснения к спецификации)

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

D Обработка ссылок на сущность и символ (Пояснения к спецификации)

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

Если DTD содержит декларацию

<!ENTITY example "An ampersand (&#38;) may be escaped numerically (&#38;#38;) or with a general entity (&amp;)." >

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

An ampersand (&) may be escaped numerically (&#38;) or with a general entity (&amp;).

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

An ampersand (&) may be escaped numerically (&) or with a general entity (&).

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

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

В результате получается следующий сценарий:

в строке 4 ссылка на символ с кодом 37 обрабатывается сразу, и сущность параметра "xx" помещается в таблицу символов со значением "%zz;". И поскольку текст замены повторно не просматривается, ссылка на сущность параметра "zz" обнаружена не будет. (Если же это здесь произойдет, то будет зафиксирована ошибка, поскольку сущность "zz" еще не была декларирована.)

Если DTD содержит декларацию

<!ENTITY example "An ampersand (&#38;) may be escaped numerically (&#38;#38;) or with a general entity (&amp;)." >

An ampersand (&) may be escaped numerically (&#38;) or with a general entity (&amp;).

An ampersand (&) may be escaped numerically (&) or with a general entity (&).

В результате получается следующий сценарий:

в строке 6 обнаруживается ссылка на сущность "xx" и, соответственно, производится разбор текста замены для этой сущности (а именно, "%zz;"). При этом обнаруживается ссылка на сущность "zz" и тоже анализируется ее текст замены ("<!ENTITY tricky "error-prone" >"). В результате получаем декларацию общей сущности "tricky" с текстом замены "error-prone".

в строке 8, обнаруживается и обрабатывается ссылка на общую сущность "tricky". В итоге получаем полное содержимое элемента test в виде самодостаточной (и не связанной с какой-либо грамматикой) строки This sample shows a error-prone method.

в строке 5 ссылка на символ "<" обрабатывается сразу, и сущность параметра "zz" обзаводится текстом замены "<!ENTITY tricky "error-prone" >", являющимся корректной декларацией сущности.

в строке 6 обнаруживается ссылка на сущность "xx" и, соответственно, производится разбор текста замены для этой сущности (а именно, "%zz;"). При этом обнаруживается ссылка на сущность "zz" и тоже анализируется ее текст замены ("<!ENTITY tricky "error-prone" >"). В результате получаем декларацию общей сущности "tricky" с текстом замены "error-prone".

в строке 8, обнаруживается и обрабатывается ссылка на общую сущность "tricky". В итоге получаем полное содержимое элемента test в виде самодостаточной (и не связанной с какой-либо грамматикой) строки This sample shows a error-prone method.

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

[82]	NotationDecl	::=	'<!NOTATION' ( \| ) ? '>'
[83]	PublicID	::=	'PUBLIC'

Ограничение действительности: Уникальность имени нотации

Любое может быть использовано только в одной декларации.

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

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

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

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

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

формирования для атрибутов.

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

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

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

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

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

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

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

Декларация кодировки

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

В декларация кодировки является частью . здесь - название используемой кодировки.

Значения "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. Желательно, чтобы обращение к остальным кодировкам символов, зарегистрированным (как наборы символов) в Internet Assigned Numbers Authority , осуществлялось через официальное название. Для названий остальных кодировок должны использоваться префиксы "x-". XML процессоры должны игнорировать верхний и нижний регистр в названии кодировки. Процессор должен либо интерпретировать зарегистрированное в IANA название как указание на использование зарегистрированной под этом именем кодировки, либо считать кодировку неизвестной (разумеется, один процессор не обязуется поддерживать все кодировки, которые были зарегистрированы в IANA).

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

Если обнаружена не в начале внешней сущности, фиксируется фатальная ошибка.

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

Примеры деклараций текста, содержащих декларацию кодировки:

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

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

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

[32]

SDDecl

::=

'standalone' (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"'))

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

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

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

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

Декларация одиночного документа должна иметь значение "no", если какие-либо внешние декларации разметки включают декларацию для:

атрибутов со значением , если элементы, к которым эти атрибуты относятся, были представлены в документе без уточнения значений для указанных атрибутов,

сущностей (кроме amp, lt, gt, apos и quot), если в документе встретились на эти сущности,

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

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

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

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

[32]

SDDecl

::=

'standalone' (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"'))

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

сущностей (кроме amp, lt, gt, apos и quot), если в документе встретились на эти сущности,

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

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

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

Декларация смешанного контента

[51]	Mixed	::=	'(' ? '#PCDATA' (? '\|' ? )* ? ')*'
			\| '(' ? '#PCDATA' ? ')'

где параметр определяет тип элементов, которые могут быть использованы в роли непосредственных потомков. Ключевое слово #PCDATA исторически унаследовано от термина "parsed character data".

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

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

Примеры деклараций смешанного контента:

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

[52]	AttlistDecl	::=	'<!ATTLIST' * ? '>'
[53]	AttDef	::=

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

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

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

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

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

Декларация текста

Каждая внешняя разобранная сущность должна начинаться с декларации текста.

[77]

TextDecl

::=

'<?xml' ? ? '?>'

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

Каждая внешняя разобранная сущность должна начинаться с декларации текста.

[77]

TextDecl

::=

'<?xml' ? ? '?>'

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

[28]	doctypedecl	::=	'<!DOCTYPE' ( )? ? ('[' ( \| )* ']' ?)? '>'

				/* */
[28a]	DeclSep	::=	\|
				/* */
[29]	markupdecl	::=	\| \| \| \| \|

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

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

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

Ограничение действительности: тип корневого элемента

Параметр в декларации типа документа должен соответствовать типу .

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

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

Ограничение корректности: Сущности параметров во внутреннем наборе

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

Ограничение корректности: Внешний набор

Внешний набор, если таковой имеется, должен соответствовать сценарию для .

Ограничение корректности: Сущность параметра между декларациями

Текст замены для ссылки на сущность параметра в должен соответствовать сценарию .

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

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

[45]	elementdecl	::=	'<!ELEMENT' ? '>'
[46]	contentspec	::=	'EMPTY' \| 'ANY' \| \|

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

Ограничение действительности: Уникальность декларации типа элемента

Ни один тип элемента не может быть декларирован более одного раза.

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

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

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

[75]	ExternalID	::=	'SYSTEM'
			\| 'PUBLIC'
[76]	NDataDecl	::=	'NDATA'

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

Ограничение действительности: Декларированная нотация

должно соответствовать декларированному имени .

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

Ссылки URI требуют кодирования и маскирования (escaping) определенных символов. Среди запрещенных символов числятся все не-ASCII символы, а также исключенные символы, перечисленные в главе 2.4 документа . Исключение составляют символы решетки (#) и процента (%), а также символы квадратных скобок, разрешенные документом . Запрещенные символы необходимо маскировать следующим образом:

Каждый из запрещенных символов преобразуется в один или два байта в кодировке UTF-8 .

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

Исходный символ замещается полученной последовательностью символов.

[Определение: Помимо системного, внешний идентификатор может включать также и публичный идентификатор.] 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 >

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

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

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

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

[2]

Char

::=

#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

/* любой символ Unicode, исключая суррогатные блоки, FFFE и FFFF. */

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

Документ

[1]

document

::=

element Misc*

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

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

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

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

Документы

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

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

E Детерминистические модели содержания (Пояснения к спецификации)

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

К примеру, модель содержимого ((b, c) | (b, d)) является недетерминистической, поскольку, получив исходный b, XML процессор не может знать, какому b в исходной модели он соответствует, не проследив далее по строке, какой элемент следует за указанным b. В данном случае обе ссылки на b можно свести в одну общую ссылку, преобразовав рассматриваемую модель в (b, (c | d)). Теперь исходный элемент b соответствует ровно одному имени в модели содержания, и процессору нет нужды заглядывать вперед чтобы увидеть, что за ним следует. Это может быть и c, и d.

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

Существуют алгоритмы, которые способны многие (хотя и не все) недетерминистические модели содержания автоматически привести к эквивалентным детерминистическым моделям (см. Brüggemann-Klein 1991 ).

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

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

с Byte Order Mark:

00 00 FE FF	UCS-4, big-endian машина (1234 порядок)
FF FE 00 00	UCS-4, little-endian машина (4321 порядок)
00 00 FF FE	UCS-4, необычный порядок октетов (2143)
FE FF 00 00	UCS-4, необычный порядок октетов (3412)
FE FF ## ##	UTF-16, big-endian
FF FE ## ##	UTF-16, little-endian
EF BB BF	UTF-8

без Byte Order Mark:

0000 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 (С некоторыми особенностями. Чтобы выяснить, которая из кодовых страниц была задействована, необходимо прочесть полную декларацию кодировки.)
остальное	UTF-8 без декларации кодировки, или неверный заголовок потока данных (отсутствие необходимой декларации кодировки), искажение, фрагментарность или результат обработки каким-либо архиватором

с Byte Order Mark:

00 00 FE FF	UCS-4, big-endian машина (1234 порядок)
FF FE 00 00	UCS-4, little-endian машина (4321 порядок)
00 00 FF FE	UCS-4, необычный порядок октетов (2143)
FE FF 00 00	UCS-4, необычный порядок октетов (3412)
FE FF ## ##	UTF-16, big-endian
FF FE ## ##	UTF-16, little-endian
EF BB BF	UTF-8

без Byte Order Mark:

0000 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 (С некоторыми особенностями. Чтобы выяснить, которая из кодовых страниц была задействована, необходимо прочесть полную декларацию кодировки.)
остальное	UTF-8 без декларации кодировки, или неверный заголовок потока данных (отсутствие необходимой декларации кодировки), искажение, фрагментарность или результат обработки каким-либо архиватором

<

Примечание:

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

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

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

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

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

Примечание:

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

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

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

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

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

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

Вторая из возможных ситуаций возникает когда XML сущность сопровождает информация о кодировке, извлекаемая из некоторых файловых систем и сетевых протоколов. Если имеется несколько источников информации, то их относительный приоритет и предпочтительный способ разрешения конфликтов должны определяться протоколом более высокого уровня, используемым для передачи XML документов. В частности, можно обратиться к и наследующим его документам, определяющим типы MIME text/xml и application/xml, а также содержащим полезное руководство. Однако в целях совместимости желательно руководствоваться следующим правилом:

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

F Автоматическое определение кодировки символов (Пояснения к спецификации)

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

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

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

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

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

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

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

Расширяемый язык разметки

Данная спецификация была подготовлена и принята к публикации рабочей группой W3C XML (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

I Рабочие заметки (Пояснения к спецификации)

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

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

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

Замечание:

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

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

Например:

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

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

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

xml:lang NMTOKEN #IMPLIED

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

J Словарь (Пояснения к спецификации)

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

character data - символьные данные

conditional section - условная секция

constraint - ограничение, правило, условие

entity - сущность

enumerated type - перечислимый тип

escape character - маскирование символа

literal data, literals - строковые данные, литералы

non-terminal symbol - неграничный символ

name character - символ имени

nonterminal content - незавершенное содержание

non-validating processor - непроверяющий процессор

numeric character reference - числовая ссылка на символ

parsed entities - разобранные сущности

production - сценарий (грамматики)

standalone document - одиночный документ

storage unit - единица размещения

subset - набор (внутренний, внешний) в DTD

token - лексема

tokenized type - символьный тип

valid document - действительный документ

validating XML processor - проверяющий XML процессор

well-formed - корректный

white space - пробельный символ

Если у вас возникли какое-либо замечания, мы будем рады их получить по адресу .

Элемент

[39]	element	::=
			\|

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

Ограничение корректности: Соответствие типов элементов

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

Ограничение действительности: Действительность элемента

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

Декларация соответствует EMPTY, а элемент не имеет .

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

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

Декларация соответствует ANY, и был декларирован тип всех .

Кодирование символов в сущностях

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

Сущности с кодировкой UTF-16 должны начинаться с Byte Order Mark, описанного в Приложении F документа , Приложении H документа , главе 2.4 документа и главе 2.7 документа (символ ZERO WIDTH NO-BREAK SPACE, #xFEFF). Причем это сигнатура кодировки, а не фрагмент разметки или символьных данных XML документа. XML процессоры должны уметь с помощью этого символа различать документы в кодировках UTF-8 и UTF-16.

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

в любом месте документа при

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

[15]

Comment

::=

''

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

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

[15]

Comment

::=

''

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

Конечный тэг

[42]

ETag

::=

'</' ? '>'

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

</termdef>

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

Корректная внешняя разобранная сущность

[78]

extParsedEnt

::=

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

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

Корректные разобранные сущности

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

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

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

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

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

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

Литералы

[9]	EntityValue	::=	'"' ([^%&"] \| \| )* '"'
			\| "'" ([^%&'] \| \| )* "'"
[10]	AttValue	::=	'"' ([^<&"] \| )* '"'
			\| "'" ([^<&'] \| )* "'"
[11]	SystemLiteral	::=	('"' [^"]* '"') \| ("'" [^']* "'")
[12]	PubidLiteral	::=	'"' * '"' \| "'" ( - "'")* "'"
[13]	PubidChar	::=	#x20 \| #xD \| #xA \| [a-zA-Z0-9] \| [-'()+,./:=?;!*#@$_%]

Замечание:

Хотя сценарий и позволяет определить сущность, состоящую из одного единственного простого символа < в строке данных (имеется ввиду <!ENTITY mylt "<">), настоятельно рекомендуется избегать подобной практики, поскольку любая ссылка на указанную сущность приведет к появлению ошибки корректности.

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

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

Модели содержимого элемента

[47]	children	::=	( \| ) ('?' \| '*' \| '+')?
[48]	cp	::=	( \| \| ) ('?' \| '*' \| '+')?
[49]	choice	::=	'(' ? ( ? '\|' ? )+ ? ')'	/* */
				/* */

[50]	seq	::=	'(' ? ( ? ',' ? )* ? ')'	/* */

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

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

Ограничение действительности: Правильная вложенность Group/PE

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

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

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

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

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

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

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

[40]	STag	::=	'<' ( )* ? '>'
[41]	Attribute	::=

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

Ограничение корректности: Уникальность спецификации атрибута

В границах одного начального тэга (или тэга пустого элемента) одно и то же имя атрибута не может появляться более одного раза.

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

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

Ограничение корректности: Отсутствие ссылок на внешние сущности

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

Ограничение корректности: Отсутствие символов < в значениях атрибута

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

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

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

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

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

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

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

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

Начинается с нормализованного значения, состоящего из пустой строки.

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

Для ссылки на символ к нормализованное значение поместить символ, на который делалась ссылка.

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

В случае пробельного символа (#x20, #xD, #xA, #x9) в нормализованное значение помещать символ пробела (#x20).

Остальные символы просто помещать в нормализованное значение.

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

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

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

Далее следуют примеры нормализации атрибутов. Даны следующие декларации:

<!ENTITY d ""> <!ENTITY a "
"> <!ENTITY da "
">

Атрибут, указанный в левой колонке следующей таблицы, в ходе нормализации будет преобразован в последовательность символов, представленную в средней колонке, если атрибут 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 имеет тип NMTOKENS.

a= " A B "
#xD #xD A #xA #xA B #xD #xA	#xD #xD A #xA #xA B #xD #xD