Партнёры:

Хостинг:

[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Web мастеру, CGI, Perl, PHP, Apache" (Архив | Для печати)

REC-xml-19980210

Extensible Markup Language (XML, Открытый язык разметки) 1.0

Рекомендация W3C 10 февраля 1998 г.

Настоящая версия:

http://www.w3.org/TR/1998/REC-xml-19980210

http://www.w3.org/TR/1998/REC-xml-19980210.xml

http://www.w3.org/TR/1998/REC-xml-19980210.html

http://www.w3.org/TR/1998/REC-xml-19980210.pdf

http://www.w3.org/TR/1998/REC-xml-19980210.ps

Последняя версия:

http://www.w3.org/TR/REC-xml

Предыдущая версия:

http://www.w3.org/TR/PR-xml-971208

Редакторы:

Тим Брэй (Textuality и Netscape) <tbray@textuality.com>

Джин Паоли (Microsoft) <jeanpa@microsoft.com>

С. М. Шперберг-МакКуин (Университет штата Иллинойс в Чикаго) <cmsmcq@uic.edu>

Введение

Открытый язык разметки (Extensible Markup Language, XML) представляет собой подмножество SGML и полностью описывается в настоящем документе. Предназначением его является обеспечить обслуживание, получение и обработку общего языка SGML в Web так же, как сейчас это происходит с языком HTML. Язык XML разработан для упрощения реализации и взаимодействия между SGML и HTML.

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

Данный документ просматривался членами W3C и другими заинтересованными сторонами, и одобрен Директором в качестве Рекомендации W3C. Это постоянный документ; он может использоваться в качестве справочника или приводиться в других документах в качестве нормативного. Распространением настоящей рекомендации W3C старается привлечь внимание к спецификации и расширить сферу ее применения. Это расширит функциональность и возможность взаимодействия в Web.

В настоящем документе определяется синтаксис, созданный путем выделения подмножества из существующего и широко используемого международного стандарта обработки текстов (Standard Generalized Markup Language, ISO 8879:1986(E) исправленный и дополненный) для использования в World Wide Web. Этот документ является результатом деятельности W3C в области XML, более подробную информацию о которой можно получить по адресу http://www.w3.org/XML. Список текущих рекомендаций W3C и прочих технических документов можно найти по адресу http://www.w3.org/TR.

В настоящей спецификации используется термин URI, определяемый в документе [Berners-Lee et al.], над которым ведется работа и который, как ожидается, обновит [IETF RFC1738] и [IETF RFC1808].

Список обнаруженных в данной спецификации ошибок можно найти по адресу http://www.w3.org/XML/xml-19980210-errata.

Об обнаруженных в этом документе ошибках сообщайте по адресу xml-editor@w3.org.

Extensible Markup Language (XML, Открытый язык разметки) 1.0

Содержание

Приложения

1. Введение

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

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

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

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

Язык XML разработан Рабочей группой XML (ранее называвшейся SGML Editorial Review Board), образованной при содействии World Wide Web Consortium (W3C) в 1996 г. Председателем ее был Джон Босак из компании Sun Microsystems, и группа активно участвовала в работе группы XML Special Interest Group (ранее называвшейся Рабочей группой SGML), также организованной W3C. Список членов рабочей группы XML приведен в приложении. В W3C эту рабочую группу представлял Дэн Коннолли.

Цели разработки документов на языке XML следующие:

1. Язык XML должен без проблем использоваться в Интернет.
2. Язык XML должен поддерживать широкий спектр приложений.
3. Язык XML должен быть совместим с SGML.
4. Программы для обработки документов XML должны быть просты в написании.
5. Число необязательных возможностей в XML должно быть минимальным, в идеале оно должно равняться нулю.
6. Документы XML должны быть удобочитаемы и ясны.
7. Дизайн XML должен создаваться быстро.
8. Дизайн XML должен быть строгим и лаконичным.
9. Документы XML должно быть просто создавать.
10. Лаконичность в разметке XML имеет минимальное значение.

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

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

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

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

можно/может

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

должен/необходимо

Соответствующие спецификации документы и процессоры XML обязаны демонстрировать описанное поведение; в противном случае они некорректны.

ошибка

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

неустранимая ошибка

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

на выбор пользователя

Конформное программное обеспечение может или должно (в зависимости от модального глагола в предложении) демонстрировать описанное поведение; в таком случае оно должно предоставлять пользователям средства включения или отключения описанного поведения.

ограничение допустимости

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

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

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

совпадение

(Строк или имен:) Две сравниваемых строки или два сравниваемых имени должны быть идентичны. Символы с несколькими возможными представлениями в наборе ISO/IEC 10646 (например, одни и те же символы с диакритическими знаками и без них) совпадают, только если они одинаково представляются в обеих строках. По выбору пользователя процессоры могут нормализовать такие символы к какой-либо канонической форме. Смена регистра не выполняется. (Строк и правил в грамматике:) Строка совпадает с грамматической продукцией, если она принадлежит языку, генерируемому этой продукцией. (Содержимого и моделей одержимого:) Элемент совпадает со своим объявлением, если он является конформным, как описано в ограничении "Допустимый элемент".

для совместимости

Свойство XML, включенное исключительно для гарантии совместимости XML с SGML.

для поддержки возможности взаимодействия сетей

Необязательная рекомендация, включенная для повышения вероятности того, что документы XML могут обрабатываться существующими процессорами SGML, предшествующими Дополнениям WebSGML к стандарту ISO 8879.

2. Документы

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

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

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

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

1. Взятый как единое целое, он совпадает с продукцией, помеченной document.
2. Он соответствует всем ограничениям формальной правильности, определенным в настоящей спецификации.
3. Каждая из анализируемых сущностей, на которые в документе даются прямые или косвенные ссылки, правильно построена.

Совпадение с продукцией document подразумевает, что:

1. Он содержит один или несколько элементов.
2. Есть только один элемент, называемый корнем, или элементом документа, никакая часть которого не отображается в содержимом никакого другого элемента. Для всех остальных элементов, если начальный тег является содержимым другого элемента, конечный тег находится в содержимом того же элемента. Проще говоря, элементы, имеющие начальные и конечные теги, корректно вложены друг в друга.

Вследствие этого, для каждого элемента C в документе, не являющегося корневым, имеется один элемент P такой, что C находится в содержимом P, но не в содержимом любого другого элемента, находящегося в содержимом элемента P. Элемент P в этом случае называется родителем элемента C, а элемент C - дочерним элементом элемента P.

2.2 Символы

Анализируемая сущность содержит текст, последовательность символов, которая может представлять разметку или символьные данные. Символ в соответствии со стандартом ISO/IEC 10646 [ISO/IEC 10646] является неделимой единицей текста. Допустимыми являются символы табуляции, возврата каретки, перевода строки и допустимые графические символы Unicode и ISO/IEC 10646. Использование "символов совместимости", описанных в разделе 6.8 спецификации [Unicode], не рекомендуется.

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

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

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

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

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

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

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

Nmtoken (метка имени) представляет собой любую комбинацию символов имени.

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

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

Текст представляет собой смесь символьных данных и разметки. Разметка бывает в форме начальных тегов, конечных тегов, тегов пустых элементов, ссылок на сущности, ссылок на символы, комментариев, разделителей разделов CDATA, объявлений типа документа и инструкций по обработке.

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

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

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

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

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

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

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

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

Инструкции по обработке (processing instructions, PI) для приложений могут включаться в документы.

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

2.7 Разделы CDATA

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

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

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

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

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

и точно таким же является документ:

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

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

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

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

Объявление разметки представляет собой объявление типа элемента, объявление списка атрибутов, объявление сущности или объявление нотации. Эти объявления полностью или частично могут содержаться в сущностях параметров, как описано в ограничениях формальной правильности и допустимости ниже. Более полную информацию можно найти в разделе "4. Физические структуры".

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

Ограничение допустимости: Корневой тип элемента
Имя в объявлении типа документа должно соответствовать типу корневого элемента.

Ограничение допустимости: Корректное объявление/Вложение сущности параметров
Заменяющий текст сущности параметра должен быть корректно вложен в объявления разметки. То есть, если любой первый или последний символ объявления разметки (markupdecl вышк) содержится в заменяющем тексте ссылки на сущность параметров, они оба должны содержаться в одном и том же заменяющем тексте.

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

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

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

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

Системный идентификатор "hello.dtd" определяет URI DTD документа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Langcode может быть:

• двухбуквенным кодом языка в соответствии с [ISO 639], "Codes for the representation of names of languages" (Коды для представления названий языков)
• идентификатором языка, зарегистрированным в Internet Assigned Numbers Authority [IANA]; они начинаются с префикса "i-" (or "I-")
• идентификатором языка, назначаемым пользователем или согласованным несколькими сторонами для личного использования; они должны начинаться с префикса "x-" или "X-", что гарантирует отсутствие конфликтов с зарегистрированными или стандартизованными в IANA именами

Количество сегментов Subcode не ограничено; если имеется первый сегмент, и Subcode состоит из двух букв, то это должен быть код страны в соответствии с [ISO 3166], "Codes for the representation of names of countries" (Коды для представления названий стран). Если первый подкод состоит из более чем двух букв, это должен быть подкод языка, зарегистрированный в IANA, если только Langcode не начинается с префикса "x-" или "X-".

Обычно код языка дается в нижнем регистре, а код страны (если таковой имеется) - в верхнем. Обратите внимание, что эти значения, в отличие от другим имен в документах XML, не учитывают регистр.

Например:

Считается, что значение xml:lang применяется ко всем атрибутам и содержимому элемента, для которого оно указано, если только оно не переопределяется другим экземпляром xml:lang другого элемента в этом содержимом.

Простое объявление xml:lang может иметь следующий вид:

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

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

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

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

Ограничение формальной правильности: Соответствие типа элемента
Name в конечном теге элемента должно соответствовать типу элемента в начальном теге.

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

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

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

Начало каждого непустого элемента XML отмечается начальным тегом.

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

Ограничение формальной правильности: Уникальная спецификация атрибута
Имя атрибута в одном начальном теге или теге пустого элемента может присутствовать только один раз.

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

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

Ограничение формальной правильности: Запрещены символы < в значениях атрибутов
Заменяющий текст любой сущности, на которую в значении атрибута имеется прямая или косвенная ссылка (кроме "<"), не должны содержать символа <.

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

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

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

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

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

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

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

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

Элементная структура документа XML может для проверки достоверности ограничиваться с помощью объявлений типов элементов и списков атрибутов. Объявление типа элемента ограничивает содержимое элемента.

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

Объявление типа элемента имеет следующий вид:

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

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

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

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

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

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

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

Ограничение допустимости: Корректное вложение групп/сущностей параметров
Заменяющий текст сущности параметров должен быть корректно вложен в обозначаемые скобками группы. То есть если в конструкции choice, seq или Mixed в заменяющем тексте сущности параметра содержится открывающая или закрывающая скобка, обе скобки должны находиться в одном и том же заменяющем тексте. Для совместимости, если ссылка на сущность параметров располагается в конструкции choice, seq или Mixed, ее заменяющий текст не должен быть пустым, и ни первый, ни последний непустой символ заменяющего текста не должен быть соединителем (| или ,).

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

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

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

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

Ограничение допустимости: Отсутствие дублирующихся типов
одно и то же имя не должно встречаться в одном объявлении со смешанным содержимым более одного раза.

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

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

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

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

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

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

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

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

Атрибуты XML бывают трех типов: строка, набор снабженных метками типов и нумерованный тип. Строка может принимать в качестве значения любую литеральную строку; снабженные метками типы могут иметь переменные лексические и семантические ограничения:

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

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

Ограничение допустимости: Значение по умолчанию атрибута ID
Атрибут ID должен объявляться со значение по умолчанию #IMPLIED или #REQUIRED.

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

Ограничение допустимости: Имя сущности
Значения типа ENTITY должны соответствовать продукции Name, значения типа ENTITIES - Names; каждое Name должно соответствовать имени неанализируемой сущности, объявленной в DTD.

Ограничение допустимости: Метка имени
Значения типа NMTOKEN должны соответствовать продукции Nmtoken; значения типа NMTOKENS - Nmtokens.

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

Атрибут NOTATION идентифицирует нотацию, объявленную в DTD, с которой связаны системные и/или общие идентификаторы, используемую при интерпретации элемента, к которому прикрепляется атрибут.

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

Ограничение допустимости: Перечисление
Значения этого типа должны соответствовать одной из меток Nmtoken в объявлении.

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4 Условные разделы

Условные разделы являются частями внешнего подмножества объявления типа документа, включенные в логическую структуру DTD (или исключенные из нее) на базе ключевого слова, управляющего им.

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

Если ключевое слово условного раздела - INCLUDE, содержимое условного раздела является частью DTD. Если ключевое слово условного раздела - IGNORE, содержимое условного раздела не является логически частью DTD. Обратите внимание, что для надежности разбора содержимое даже игнорируемых условных разделов должно прочитываться для выявления вложенных условных разделов и гарантии того, конец самого последнего (игнорируемого) условного раздела обнаружено корректно. Если условный раздел с ключевым словом INCLUDE располагается в условном разделе большего объем с ключевым словом IGNORE, игнорируются как внешний, так и внутренний разделы.

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

Пример:

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

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

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

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

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

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

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

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

Ограничение формальной правильности: Допустимый символ
Символы, на которые осуществляется ссылка, должны соответствовать продукции для Char.

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

Ограничение формальной правильности: Сущность объявлена
В документе без DTD, документе только с внутренним подмножеством DTD, не содержащим ссылок на сущности параметров, или документе с объявлением "standalone='yes'" Name, данное в ссылке на сущность, должно соответствовать имени в объявлении сущности, за исключением правильно построенных документов, в которых следующие сущности объявляться не должны: CODE>amp, lt, gt, apos, quot. Объявление сущности параметра должно предшествовать всем ссылкам на него. Аналогично объявление общей сущности должно предшествовать всем ссылкам на него, расположенным в значении по умолчанию в объявлении списка атрибутов. Обратите внимание, что, если сущности объявлены во внешнем подмножестве или во внешних сущностях параметров, процессор без проверки правлиьности не обязан читать и обрабатывать их объявления; для таких документов правило обязательного объявления сущности является ограничением формальной правильности, только если standalone='yes'.

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

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

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

Ограничение формальной правильности: В DTD
Ссылки на сущности параметров могут располагаться только в DTD.

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

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

4.2 Объявления сущностей

Сущности объявляются следующим образом:

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

4.2.1 Внутренние сущности

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

Внутренняя сущность является анализируемой.

Пример объявления внутренней сущности:

4.2.2 Внешние сущности

Если сущность не является внутренней, она является внешней и объявляется следующим образом:

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

Ограничение допустимости: Нотация объявлена
Name должно соответствовать объявленному имени нотации.

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

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

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

Примеры объявлений внешних сущностей:

4.3 Анализируемые сущности

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

Внешние анализируемые сущности могут начинаться с объявления текста.

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

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

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

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

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

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

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

Сущности, закодированные в UTF-16, должны начинаться с Byte Order Mark (метке порядка байтов), описанной в стандарте ISO/IEC 10646 Annex E и Unicode Appendix B (символ ZERO WIDTH NO-BREAK SPACE (неразрывный пробел нулевой ширины), #xFEFF). Он представляет собой сигнатуру кодировки и не является частью разметки или символьных данных документа XML. Процессоры XML должны использовать этот символ для определения разницы между документами, закодированными с использованием UTF-8 и UTF-16.

Хотя процессор XML обязан читать только сущности в кодировках UTF-8 и UTF-16, в мире используются и другие кодировки, и будет полезно, если процессоры XML смогут читать сущности, в которых они используются. Анализируемые сущности, хранящиеся в кодировках, отличных от UTF-8 или UTF-16, должны начинаться с объявления текста, содержащего объявление кодировки:

В сущности документа объявление кодировки является частью объявления 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-9" должны использоваться для частей набора ISO 8859, а значения "ISO-2022-JP", "Shift_JIS" и "EUC-JP" - для различных закодированных видов JIS X-0208-1997. Процессоры XML могут распознавать другие кодировки; рекомендуется, чтобы в ссылках на кодировки символов, зарегистрированные (как наборы символов) в Internet Assigned Numbers Authority [IANA] и отличные от перечисленных выше, использовались зарегистрированные названия. Обратите внимание, что зарегистрированные названия не учитывают регистр, поэтому процессоры, которые распознают их, не должны учитывать для них регистр.

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

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

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

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

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

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

в качестве ссылки в любом месте после начального тега до конечного тега элемента; соответствует нетерминалу content.

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

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

Находится в значении атрибута

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

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

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

Ссылка в DTD

в качестве ссылки во внутреннем или внешнем подмножествах DTD, но за пределами EntityValue или AttValue.

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

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

4.4.2 Включается

Сущность включается, если ее заменяющий текст считывается и обрабатывается вместо самой ссылки, как если бы он был частью документа в месте, в котором расположена распознаваемая ссылка. Заменяющий текст может содержать символьные данные и (только не для сущностей параметров) разметку, которые должны распознаваться стандартным образом, за исключением того, что заменяющий текст сущностей, используемый для кодирования разделителей (сущности amp, lt, gt, apos, quot) всегда обрабатывается как данные. (Строка "AT&T;" разворачивается в "AT&T;", и оставшийся амперсанд не распознается в качестве разделителя ссылки на сущность.) Ссылка на символ включается, если указанный символ обрабатывается вместо самой ссылки.

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

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

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

4.4.4 Запрещен

Запрещены и представляют собой неустранимые ошибки:

• наличие ссылки на неанализируемую сущность.
• наличие любого символа или ссылки на общий в DTD, за исключением того, когда они располагаются в EntityValue или AttValue.
• ссылка на внешнюю сущность в значении атрибута.

4.4.5 Включается в литерал

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

а этот пример неправилен:

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

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

4.4.7 Обходится

Если ссылка на общую сущность находится в EntityValue в объявлении сущности, она обходится и остается как есть.

4.4.8 Включается как сущность параметров

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

4.5 Построение заменяющего текста внутренних сущностей

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

Литеральное значение сущности, как оно дано во внутреннем объявлении сущности (EntityValue), может содержать ссылки на символы, сущности параметров и общие сущности. Такие ссылки должны содержаться полностью в литеральном значении сущности. Фактический заменяющий текст в литеральном значении сущности, включенный, как описано выше, должен содержать заменяющий текст всех сущностей параметров, на которые имеются ссылки, а вместо всех ссылок на символы должен содержать собственно символы; однако ссылки на общие сущности должны оставаться в оригинальном виде, без декодирования. Например, даны следующие объявления:

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

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

Эти простые правила могут достаточно сложно взаимодействовать; более подробное обсуждение сложного примера находится в разделе "Г. Декодирование ссылок на сущности и символы".

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

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

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

Обратите внимание, что символы < и & в объявлениях "lt" и "amp" закодированы дважды для соответствия требованию правильного построения замены сущности.

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

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

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

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

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

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

5. Конформность

5.1 Процессоры с проверкой корректности и без нее

Конформные процессоры XML подразделяются на два класса: с проверкой корректности и без нее.

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

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

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

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

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

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

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

6. Нотация

Формальная грамматика XML дается в настоящей спецификации с помощью простой нотации Extended Backus-Naur Form (EBNF - расширенной формы Бакуса-Наура). Каждое правило грамматики определяет один символ в форме

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

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

#xN

где N - шестнадцатеричное целое число, выражение соответствует символу набора ISO/IEC 10646, каноническое (UCS-4) кодовое значение которого, в случае интерпретации в виде беззнакового двоичного числа, имеет указанное значение. Число начальных пробелов в форме #xN не имеет значения; число начальных пробелов в соответствующем кодовом значении определяется используемой кодировкой символов и не имеет значения для XML.

[a-zA-Z], [#xN-#xN]

соответствует любому символу со значением в указанном диапазоне (включительно).

[^a-z], [^#xN-#xN]

соответствует любому символу со значением вне указанного диапазона.

[^abc], [^#xN#xN#xN]

соответствует любому символу со значением, не входящим в число указанных символов.

"строка"

соответствует литеральной строке, соответствующей строке, данной в двойных кавычках.

'строка'

соответствует литеральной строке, соответствующей строке, данной в одинарных кавычках.

(выражение)

выражение обрабатывается как единица и может объединяться, как описано в данном списке.

A?

соответствует A или ничему; необязательное A.

A B

соответствует A, за которым следует B.

A | B

соответствует A или B, но не обоим вместе.

A - B

соответствует любой строке, соответствующей A, но не соответствующей B.

A+

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

A*

соответствует любому числу экземпляров A.

/* ... */

комментарий.

[ wfc: ... ]

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

[ vc: ... ]

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

Приложения

А. Ссылки

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

IANA

(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, ред. H. Alvestrand. 1995.

ISO 639

(International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: Международная организация по стандартизации, 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]: Международная организация по стандартизации, 1997.

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]: Международная организация по стандартизации, 1993 (а также дополнения AM 1 - AM 7).

Unicode

The Unicode Consortium. The Unicode Standard, Version 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.

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. Regular Expressions into Finite Automata. Extended abstract in I. Simon, Hrsg., LATIN 1992, S. 97-98. Springer-Verlag, Berlin 1992. Полная версия в Theoretical Computer Science 120: 197-213, 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, октябрь 1991.

Clark

James Clark. Comparison of SGML and XML. См. http://www.w3.org/TR/NOTE-sgml-xml-971215.

IETF RFC1738

IETF (Internet Engineering Task Force). RFC 1738: Uniform Resource Locators (URL), ред. T. Berners-Lee, L. Masinter, M. McCahill. 1994.

IETF RFC1808

IETF (Internet Engineering Task Force). RFC 1808: Relative Uniform Resource Locators, ред. R. Fielding. 1995.

IETF RFC2141

IETF (Internet Engineering Task Force). RFC 2141: URN Syntax, ред. R. Moats. 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]: Международная организация по стандартизации, 1986.

ISO/IEC 10744

ISO (International Organization for Standardization). ISO/IEC 10744-1992 (E). Information technology -- Hypermedia/Time-based Structuring Language (HyTime). [Geneva]: Международная организация по стандартизации, 1992. Extended Facilities Annexe. [Geneva]: Международная организация по стандартизации, 1996.

Б. Классы символов

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

Определенные здесь классы символов выводятся из базы данных символов Unicode следующим образом:

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

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

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

Г. Декодирование ссылок на сущности и символы (ненормативное)

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

Если в DTD имеется объявление

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

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

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

Результат будет следующим:

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

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

Для совместимости необходимо, чтобы модели содержимого в объявлениях типов элементов были детерминистическими.

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

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

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

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

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

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

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

• 00 00 00 3C: UCS-4, тупоконечная машина (порядок 1234)
• 3C 00 00 00: UCS-4, остроконечная машина (порядок 4321)
• 00 00 3C 00: UCS-4, необычный порядок октетов (2143)
• 00 3C 00 00: UCS-4, необычный порядок октетов (3412)
• FE FF: UTF-16, тупоконечный
• FF FE: UTF-16, остроконечный
• 00 3C 00 3F: UTF-16, тупоконечный, без метки порядка байтов (и поэтому, строго говоря, ошибочный)
• 3C 00 3F 00: UTF-16, остроконечный, без метки порядка байтов (и поэтому, строго говоря, ошибочный)
• 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 без объявления кодировки, в противном случае поток данных поврежден, неполон или заключен в некоторую оболочку

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

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

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

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

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

• Если сущность XML находится в файле, для определения кодировки символов используются PI метки порядка байтов и объявления кодировки. Все другие эвристики и источники информации предназначены исключительно для устранения ошибок.
• Если сущность XML доставляется с использованием типа MIME text/xml, метод кодирования символов определяет параметр charset типа MIME; все другие эвристики и источники информации предназначены исключительно для устранения ошибок.
• Если сущность XML доставляется с использованием типа MIME application/xml, для определения кодировки символов используются PI метки порядка байтов и объявления кодировки (если они имеются). Все другие эвристики и источники информации предназначены исключительно для устранения ошибок.

Ж. Рабочая группа W3C по XML (ненормативное)

Настоящая спецификация подготовлена и утверждена для публикации рабочей группой W3C по XML. Утверждение настоящей спецификации рабочей группой не обязательно подразумевает, что все члены рабочей группы проголосовали за ее утверждение. На настоящий момент и в прошлом членами рабочей группы по XML были:

Copyright  ©  1998 W3C (MIT, INRIA, Keio ), С сохранением всех прав. Применяются правила W3C, связанные с ответственностью, торговыми марками, использованием документов и лицензированием программного обеспечения.