Электронная библиотека
Программисту веб-дизайнеру
Другие материалы
Расширяемый язык разметки XML 1.0, вторая редакция
Рекомендации W3C от 6 октября 2000 года
XML™ 1.0:
The Extensible Markup Language
(Расширяемый Язык Разметки)
Расширяемый язык разметки XML 1.0, вторая редакция
Рекомендации W3C от 6 октября 2000 года
Внимание !
Эта версия:
Самая последняя версия:
Предыдущая версия:
http://www.w3.org/tr/2000/WD-xml-2e-20000814
Copyright © 2000 W3C (MIT, INRIA, Keio), Все Права
Зарезервированы.
W3C соблюдает все обязательства,
права на торговые
марки,
использование
документов и лицензирование
программного обеспечения.
Расширяемый язык разметки (The Extensible Markup Language, XML) - подмножество SGML, целиком описанное в представленном документе. Язык должен дать возможность передавать, получать и обрабатывать в Web общие документы SGML так же, как сейчас это можно делать с документами HTML. Язык XML спроектирован так, чтобы упростить реализацию и обеспечить взаимодействие SGML и HTML.
Данный документ был рассмотрен членами W3C, другими заинтересованными сторонами и был утвержден Директором в качестве рекомендации от W3C. Документ является окончательным и его можно использовать как материал для ссылки или цитировать в других документах в качестве стандарта. Участие W3C в разработке этой спецификации заключается в привлечении к ней внимания и содействии ее широкому распространению. Принятие стандарта способствует наращиванию функциональных возможностей и повышению уровня взаимодействия в Сети.
В данном документе формулируется синтаксис, пригодный для использования в World Wide Web и построенный как подмножество уже имеющегося и широко используемого международного стандарта обработки текстов (Standard Generalized Markup Language, SGML, ISO 8879:1986(E) улучшенного и исправленного). Данный документ является результатом работ по проекту W3C XML Activity, детальное описание которого можно найти по адресу http://www.w3.org/XML/. Нормативную силу имеет только английская версия спецификации, однако по адресу http://www.w3.org/XML/#trans можно найти перевод этого документа на другие языки. На странице http://www.w3.org/tr/ можно найти перечень текущих рекомендаций W3C и других технических документов.
Вторая редакция не является новой версией языка XML (первая была опубликована 10 февраля 1998 года). Она всего лишь учитывает изменения, продиктованные удобством читателей и выявленными ошибками (которые можно увидеть по адресу http://www.w3.org/XML/xml-19980210-errata). Перечень ошибок, обнаруженных во второй версии спецификации, можно увидеть по адресу http://www.w3.org/XML/xml-V10-2e-errata.
Об ошибках, обнаруженных в данном документе, просьба сообщать по адресу xml-editor@w3.org; Доступен архив переписки.
Замечание:
Со времени публикации первой редакции C. M. Sperberg-McQueen поменял место работы. Теперь он работает в World Wide Web Consortium и с ним можно связаться по адресу cmsmcq@w3.org.
1 Введение
1.1 Возникновение языка XML и его задачи
1.2 Терминология
2 Документы
2.1 Корректные XML документы
2.2 Символы
2.3 Общие синтаксические конструкции
2.4 Символьные данные и разметка
2.5 Комментарии
2.6 Инструкции обработки
2.7 Секции CDATA
2.8 Пролог и декларация типа документа
2.9 Декларация одиночного документа
2.10 Обработка пробельных символов
2.11 Обработка концов строк
2.12 Идентификация языка
3 Логические структуры
3.1 Начальные тэги, конечные тэги и тэги пустых элементов
3.2 Декларации типа элемента
3.2.1 Содержимое элемента
3.2.2 Смешанный контент
3.3 Декларации списков атрибутов
3.3.1 Типы атрибутов
3.3.2 Значения атрибутов по умолчанию
3.3.3 Нормализация значения атрибута
3.4 Условные секции
4 Физические структуры
4.1 Ссылки на символ и сущность
4.2 Декларации сущности
4.2.1 Внутренние сущности
4.2.2 Внешние сущности
4.3 Разобранные сущности
4.3.1 Декларация текста
4.3.2 Корректные разобранные сущности
4.3.3 Кодирование символов в сущностях
4.4 Обработка XML процессором сущностей и ссылок
4.4.1 Не распознается
4.4.2 Включается
4.4.3 Включается при проверке
4.4.4 Запрещен
4.4.5 Включается как строка
4.4.6 Уведомление
4.4.7 Пропускается
4.4.8 Включается как сущность параметра
4.5 Построение текста замены для внутренней сущности
4.6 Предопределенные сущности
4.7 Декларирование нотаций
4.8 Сущность документа
5 Соответствие
5.1 Проверяющие и непроверяющие процессоры
5.2 Использование XML процессоров
6 Нотация
Приложения
A Ссылки
A.1 Нормативные ссылки
A.2 Остальные ссылки
B Классы символов
C XML и SGML (Пояснения к спецификации)
D Обработка ссылок на сущность и символ (Пояснения к спецификации)
E Детерминистические модели содержания (Пояснения к спецификации)
F Автоматическое определение кодировки символов (Пояснения к спецификации)
F.1 Определение без внешней информации о кодировке
F.2 Приоритеты при наличии внешней информации о кодировке
G Рабочая группа W3C XML (Пояснения к спецификации)
H Основная группа W3C XML (Пояснения к спецификации)
I Рабочие заметки (Пояснения к спецификации)
J Словарь (Пояснения к спецификации)
Расширяемый язык разметки (Extensible Markup Language, аббревиатура - XML) описывает класс объектов XML document, а также частично описывает работу компьютерных программ, обрабатывающих объекты с данными, реализующими этот класс. XML - это прикладной уровень или усеченная форма SGML, Стандартного Обобщенного языка разметки [ISO 8879]. По своему построению, XML документ является полноценным SGML документом.
XML документы состоят из единиц размещения, называемых сущностями, которые содержат разобранные или неразобранные данные. Разобранные данные состоят из набора символов, часть которых образуют символьные данные, часть - разметку. Разметка образует описание схемы размещения и логической структуры документа. Язык XML дает механизм создания ограничений для указанной схемы размещения и логической структуры.
[Определение: Для чтения XML документа, доступа к его содержимому и структуре используется программный модуль, называемый XML процессором.] [Определение: Предполагается, что XML процессор выполняет свою работу по заданию другого модуля, называемого приложением.] Данная спецификация формулирует требования к работе XML процессора, указывая как именно он должен читать данные XML и какую информацию в результате он должен предоставить приложению.
1.1 Возникновение языка XML и его задачи
Язык XML был разработан группой XML Working Group (первоначально называемой SGML Editorial Review Board), сформированной в 1996 году под патронажем World Wide Web Consortium (W3C). Председательствует в группе Jon Bosak из Sun Microsystems, принимающий также активное участие в работе группы XML Special Interest Group (ранее известной как SGML Working Group), которая тоже была сформирована W3C. Список членов XML Working Group представлен в Приложении. Связь группы с W3C обеспечивает Dan Connolly.
При разработке языка XML ставились следующие задачи:
Данная спецификация в сочетании с остальными связанными с нею стандартами (Unicode и ISO/IEC 10646 для символов, Internet RFC 1766 для тэгов идентификации языка, ISO 639 для кодов с названием языка и ISO 3166 для кодов с названием страны) дает всю необходимую информацию для понимания языка XML (версия 1.0) и создания компьютерных программ для его обработки.
Данная версия спецификации XML может распространяться свободно при условии, что весь текст и замечания правового характера остаются нетронутыми.
Терминология, используемая для описания XML документов, также дается в данной спецификации. При построении определений и описании функций XML процессора используются термины из следующего перечня:
может (may)
[Определение: Документы и XML процессоры, отвечающие этому условию, могут, но не обязаны действовать именно так, как было описано.]
должен (must)
[Определение: Документы и XML процессоры обязаны действовать именно так, как было описано. В противном случае имеет место ошибка.]
ошибка (error)
[Определение: Отступление от правил данной спецификации, результат не определен. Программное обеспечение, отвечающее требованиям спецификации, может обнаруживать такую ошибку, сообщать о ней и обрабатывать ее.]
фатальная ошибка (fatal error)
[Определение: Ошибка, которую XML процессор, отвечающий требованиям спецификации, должен зафиксировать и сообщить об этом приложению. После обнаружения фатальной ошибки процессор может продолжить обработку данных с тем, чтобы найти остальные ошибки и, возможно, сообщить о них приложению. Помогая обрабатывать ошибки, процессор может предоставить приложению доступ к необработанным материалам исходного документа (символьным данным и разметке). После обнаружения фатальной ошибки процессор должен приостановить нормальную обработку данных (то есть, он должен прекратить передачу приложению символьных данных и сведений о логической структуре документа обычным образом).]
по выбору пользователя (at user option)
[Определение: Программное обеспечение, отвечающее требованиям спецификации, может или должно (в зависимости от степени долженствования в предложении) поступать так, как было указано в спецификации. Если это сделано, пользователю должна быть предоставлена возможность разрешать или запрещать описанные действия.]
ограничение действительности (validity constraint, VC)
[Определение: Правило, относящееся ко всем действительным XML документам. Нарушение ограничения корректности классифицируется как ошибка, о которой (по выбору пользователя) должны сообщать проверяющие XML процессоры.]
ограничение корректности (well-formedness constraint, WFC)
[Определение: Правило, относящееся ко всем корректным XML документам. Нарушение ограничения корректности классифицируется как фатальная ошибка.]
соответствие (match)
[Определение: (Для строк или имен:) Две сравниваемые строки или имени должны быть идентичны. Символы с несколькими возможными представлениями в ISO/IEC 10646 (например, символы, имеющие обе формы представления precomposed и base+diacritic) считаются совпадающими только тогда, когда в обеих строках они имеют одну и ту же форму представления. Преобразование регистра не производится. (Для строк и правил грамматики:) Строка отвечает сценарию грамматики если она принадлежит языку, генерируемому по этому сценарию. (Для содержимого и моделей содержимого:) Элемент соответствует своей декларации если он отвечает положениям, описанным в соответствующем ограничении [VC: Действительный элемент].]
для совместимости (for compatibility)
[Определение: Выделяет фразу, описывающую функцию языка XML, которая была включена в спецификацию исключительно для того, чтобы убедиться в том, что XML сохраняет совместимость с языком SGML.]
для взаимодействия (for interoperability)
[Определение: Выделяет фразу, описывающую необязательную рекомендацию, которая была включена в спецификацию для увеличения возможности обработки XML документов с помощью уже установленных SGML процессоров, указанных в Приложении WebSGML Adaptations к ISO 8879.]
[Определение: Объект данных становится XML документом если, в соответствии с определениями обсуждаемой спецификации, он является корректным. Корректный XML документ также может стать действительным, если отвечает некоторым дополнительным ограничениям.]
Каждый XML имеет логическую и физическую структуру. Физически документ состоит из элементов, называемых сущностями. Любая сущность может ссылаться на другие сущности, обеспечивая их включение в данный документ. Документ начинается с "корня" или сущности документа. С логической точки зрения, документ строится из деклараций, элементов, комментариев, ссылок на символ и инструкций обработки. Все они размечаются в документе явным образом. Логические и физические структуры должны иметь корректную вложенность, как было описано в главе 4.3.2 Корректные разобранные сущности.
[Определение: Текстовый объект становится корректным (well-formed) XML документом, если:]
Документ
[1]
document
::=
prolog element Misc*
Соответствие сценарию document подразумевает следующее:
[Определение: Из вышесказанного следует что в документе для любого некорневого элемента C имеется другой элемент P из этого же документа, такой что C находится в содержимом P, но при этом не попадает в содержимое какого-либо третьего элемента, также находящегося в содержимом элемента P. В таком случае об элементе P говорят как о родителе элемента C, а элемент C называют непосредственным потомком элемента P.]
[Определение: Разобранная сущность (parsed entity) содержит текст - последовательности символов, образующие разметку и символьные данные.] [Определение: символ - это элементарная единица текста, описанная в ISO/IEC 10646 [ISO/IEC 10646] (см. также [ISO/IEC 10646-2000]). Допустимы символы табуляции, возврата каретки, конца строки, а также разрешенные символы из наборов Unicode и ISO/IEC 10646. Последние версии указанных стандартов, актуальные на момент подготовки данного документа, перечислены в Приложении A.1 Нормативные ссылки. Перечисленные стандарты могут быть дополнены новыми символами в ходе обновления или при написании для них новых редакций. Соответственно, XML процессоры должны принимать любой символ из диапазона, указанного для Char. Использовать "символы совместимости", описанные в главе 6.8 из [Unicode] (см. также D21 в главе 3.6 из [Unicode3]), нежелательно.]
Диапазон символов
[2]
Char
::=
#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
[#x10000-#x10FFFF]
/* любой символ Unicode, исключая суррогатные блоки, FFFE и FFFF. */
Механизм шифрования символьных кодов использует битовые шаблоны, которые могут меняться от сущности к сущности. Все XML процессоры должны иметь возможность работать с кодировками UTF-8 и UTF-16 из набора 10646. Механизм для указания используемой кодировки и подключения новых кодировок обсуждается позднее в главе 4.3.3 Кодирование символов в сущностях.
2.3 Общие синтаксические конструкции
В данной главе определяются некоторые символы, широко используемые в грамматике XML.
S (пробельный символ, white space) состоит из одного или нескольких символов пробела (#x20), возврата каретки, конца строки или табулятора.
Пробельный символ
[3]
S
::=
(#x20 | #x9 | #xD | #xA)+
Для удобства символы делятся на буквы, цифры и остальные символы. Буквы состоят из алфавитных, слоговых и идеографических символов. Полное определение конкретных символов из каждого класса дается в Приложении B Классы символов.
[Определение: Имя (name) - это лексема (token), начинающаяся с буквы, либо одного из нескольких символов пунктуации, за которыми следуют буквы, цифры, дефисы, символы подчеркивания, двоеточия или точки (все они называются name character - символами имени).] Имена, начинающиеся с комбинации "xml" или какой-либо из строк, соответствующих шаблону (('X'|'x') ('M'|'m') ('L'|'l')), зарезервированы под стандартизацию в этой спецификации и ее последующих версиях.
Замечание:
Интерпретация имен, содержащих символ двоеточия, задается в документе Namespaces in XML Recommendation [XML Names]. Поэтому авторам не следует использовать символ двоеточия в именах XML, если это не связано с обращением к пространству имен. Вместе с тем, сами XML процессоры должны воспринимать двоеточие в имени как обычный символ.
Nmtoken (лексема имени) - это произвольное сочетание символов имени.
Имена и лексемы
[4]
NameChar
::=
Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
[5]
Name
::=
(Letter | '_' | ':') (NameChar)*
[7]
Nmtoken
::=
(NameChar)+
[8]
Nmtokens
::=
Nmtoken (S Nmtoken)*
Строковые данные (literal data) - это любая заключенная в кавычки строка, внутри которой нет кавычек, которые можно было бы принять за разделители этой строки. Строковые данные, или литералы (literals), применяются для указания содержимого внутренних сущностей (EntityValue), значений атрибутов (AttValue) и внешних идентификаторов (SystemLiteral). Заметим, что идентификатор SystemLiteral может быть обработан без проверки разметки.
Литералы
[9]
EntityValue
::=
'"' ([^%&"] | PEReference | Reference)* '"'
| "'" ([^%&'] | PEReference | Reference)* "'"
[10]
AttValue
::=
'"' ([^<&"] | Reference)* '"'
| "'" ([^<&'] | Reference)* "'"
[11]
SystemLiteral
::=
('"' [^"]* '"') | ("'" [^']* "'")
[12]
PubidLiteral
::=
'"' PubidChar* '"' | "'" (PubidChar - "'")* "'"
[13]
PubidChar
::=
#x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]
Замечание:
Хотя сценарий EntityValue и позволяет определить сущность, состоящую из одного единственного простого символа < в строке данных (имеется ввиду <!ENTITY mylt "<">), настоятельно рекомендуется избегать подобной практики, поскольку любая ссылка на указанную сущность приведет к появлению ошибки корректности.
2.4 Символьные данные и разметка
Текст документа образуется сочетанием символьных данных и разметки. [Определение: Разметка принимает форму начальных тэгов, конечных тэгов, тэгов пустых элементов, ссылок на сущности, ссылок на символы, комментариев, разделителей секций CDATA, объявлений типов документов, инструкций обработки, деклараций XML, деклараций текста и любых пробельных символов, которые располагаются на верхнем уровне сущности документа (то есть, вне элемента document и за пределами иных элементов разметки).]
[Определение: Текст, который не относится к разметке, формирует символьные данные документа (character data).]
Символ амперсанта (&) и левая угловая скобка (<) могут появиться в своем обычном текстовом виде только в том случае, если используются в качестве ограничителя разметки, либо находятся в пределах комментария, инструкции обработки или секции CDATA. Если же эти символы потребовались в документе где-либо еще, их следует маскировать, воспользовавшись для этого либо соответствующей числовой ссылкой на символ (numeric character reference), либо строками "&" и "<" соответственно. Правая угловая скобка (>) может быть представлена в виде строки ">". Кроме того, если правая угловая скобка в содержимом элемента попадает в комбинацию символов "]]>", которая не соответствует окончанию секции CDATA, то, в целях совместимости, эту скобку необходимо заменить ссылкой на символ либо комбинацией ">".
Символьные данные в содержимом элемента - это любая строка символов, которая не содержит начальных ограничителей какой-либо разметки. Символьные данные в секции CDATA - это любая строка символов, которая не содержит закрывающего ограничителя секции CDATA (комбинации символов "]]>").
Если в значение атрибута необходимо поместить символ одинарной или двойной кавычки, то апостроф или символ одинарной кавычки (') следует представить комбинацией "'", а символ двойной кавычки (") - как """.
Символьные данные
[14]
CharData
::=
[^<&]* - ([^<&]* ']]>' [^<&]*)
[
Определение:
Комментарий может размещаться в любом месте документа при условии, что он не попадает в границы какого-либо элемента разметки. Комментаций может также появляться в тех местах декларации типа документа, где это разрешено грамматикой. Комментарии не относятся к символьным данным документа, однако XML процессоры могут (но не обязаны) передавать приложению текст полученных комментариев. Для сохранения совместимости, в комментарии не следует пользоваться комбинацей символов "--" (двойной дефис).] Ссылка на сущность параметра в комментариях не распознается.
Комментарии
[15]
Comment
::=
'<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'
Пример комментария:
<!-- declarations for <head> & <body> -->
Заметим, что, согласно требованиям обсуждаемой грамматики, комментарий не может завершаться комбинацией символов --->. Поэтому следующий пример корректным уже не будет.
<!-- B+, B, or B--->
[Определение: Инструкции обработки (processing instruction, PI) позволяют размещать в документе инструкции для приложений.]
Инструкции обработки
[16]
PI
::=
'<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'
[17]
PITarget
::=
Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
Хотя PI не относятся к символьным данным документа, они точно так же должны быть переданы приложению. Инструкция PI начинается с указания адреса (PITarget), используемого для идентификации приложения, которому предназначается эта инструкция. Адреса с названиями "XML", "xml" и аналогичными зарезервированы для стандартизации в текущей и последующих версиях спецификации. Для формального декларирования адресата инструкции PI может использоваться механизм нотаций XML. Ссылки на сущность параметра в инструкциях обработки не распознаются.
[Определение:
Секция CDATA может находиться повсюду, где могут размещаться символьные данные. Использование секции CDATA позволяет избежать обработки блока текста, содержащего символы, которые в других случаях распознавались бы как разметка. Секция CDATA начинается со строки "<![CDATA[" и заканчивается строкой "]]>":]
Секции CDATA
[18]
CDSect
::=
CDStart CData CDEnd
[20]
CData
::=
(Char* - (Char* ']]>' Char*))
В секции CDATA распознается только один элемент разметки - строка CDEnd. Поэтому все символы левой угловой скобки и амперсанта могут предстать здесь в своем обычном текстовом виде. Эти символы не нужно (да и невозможно) маскировать с помощью комбинаций "<" и "&". Секции CDATA не могут быть вложенными.
Пример секции CDATA, в которой строки "<greeting>" и "</greeting>" будут распознаваться не как разметка, а как обычные символьные данные:
<![CDATA[<greeting>Hello, world!</greeting>]]>
2.8 Пролог и декларация типа документа
[Определение: Документ XML должен начинаться с декларации XML, указывающей версию используемого языка XML.] Например, в следующем примере представлен полноценный XML документ, корректный, но недействительный:
<?xml version="1.0"?> <greeting>Hello, world!</greeting>
таким образом, имеем:
<greeting>Hello, world!</greeting>
Для обозначения совместимости с данной версией спецификации, необходимо указывать номер версии "1.0". Если в документе используется значение "1.0", но он не отвечает требованиям данной версии спецификации, это будет ошибкой. Выбор номера для тех версий спецификации XML, которые последуют за "1.0", остается за рабочей группой по XML, однако это не подразумевает что она обязуется разработать новые версии языка XML или придерживаться какой-либо конкретной схемы при их нумерации, если таковые будут созданы. Поскольку появление новых версий не исключается, то принятие упомянутой схемы нумерации позволило бы реализовать автоматическое распознавание версии, которое должно стать необходимым. Если получен документ с меткой о версии, которую процессор не в состоянии поддерживать, последний может сигнализировать об ошибке.
Задачей разметки XML документа должно быть описание схемы его размещения и логической структуры, а также связывание пар атрибут-значение с их логической структурой. XML предоставляет механизм для определения логических ограничений для логической структуры и формирования предопределенных единиц размещения - декларацию типа документа. [Определение: XML документ является действительным, если с ним связана декларация типа документа и если этот документ отвечает представленным в ней ограничениям.]
Декларация типа должна располагаться в документе до первого элемента.
Пролог
[22]
prolog
::=
XMLDecl? Misc* (doctypedecl Misc*)?
[23]
XMLDecl
::=
'<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'
[24]
VersionInfo
::=
S 'version' Eq ("'" VersionNum "'" | '"' VersionNum '"')/* */
[26]
VersionNum
::=
([a-zA-Z0-9_.:] | '-')+
[27]
Misc
::=
Comment | PI | S
[Определение: В языке XML декларация типа документа либо сама содержит, либо ссылается на декларации разметки, которые определяют грамматику некого класса документов. Такую грамматику называют декларацией типа документа, или Dtd (document type definition). Декларация типа документа может ссылаться на внешний набор, который также содержит декларацию разметки (специальный тип - внешняя сущность), может содержать свой внутренний набор деклараций разметки, а может сочетать оба варианта. Dtd документа формируется из обоих этих наборов, обрабатываемых совместно.]
[Определение: Декларация разметки - это декларация типа документа, декларация списка атрибутов, декларация сущности или декларация нотации.] Перечисленные декларации могут целиком, либо частично располагаться в сущности параметра в соответствии с приводимыми далее ограничениями корректности и действительности. Дальнейшие подробности см. в главе 4 Физические структуры.
Декларация типа документа
[28]
doctypedecl
::=
'<!DOCTYPE' S Name (S ExternalID)? S? ('[' (markupdecl | DeclSep)* ']' S?)? '>'
[VC: Тип корневого элемента]
/* */
[28a]
DeclSep
::=
PEReference | S
[WFC: Сущность параметра между декларациями]
/* */
[29]
markupdecl
::=
elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI | Comment
[VC: Правильная декларация/вложенность сущности параметра]
[WFC: Сущности параметров во внутреннем наборе]
Отметим, что можно создать корректный документ, который включал бы doctypedecl, не ссылающийся на внешний набор деклараций и не содержащий своего внутреннего набора.
Декларации разметки могут полностью или частично состоять из текста замены для сущностей параметров. Сценарии, приводимые далее в спецификации для конкретных неграничных элементов (elementdecl, AttlistDecl и так далее), описывают декларации уже после подстановки всех сущностей параметров.
Ссылка на сущность параметра распознается в любом месте Dtd (внутреннем и внешнем наборах, внешних сущностях параметров) за исключением текстовых данных, инструкций обработки, комментариев и содержимого игнорируемых условных секций (см. главу 3.4 Условные секции). Распознается она также и в тексте значения сущности. Использование сущностей параметров во внутреннем наборе деклараций подчиняется следующим ограничениям:
Ограничение действительности: тип корневого элемента
Параметр Name в декларации типа документа должен соответствовать типу корневого элемента.
Ограничение действительности: Правильная декларация/вложенность сущности параметра
Текст замены для сущности параметра должен быть правильным образом вложен в декларации разметки. Иначе говоря, если первый или последний символ декларации разметки (см. выше markupdecl) находится в тексте замены для ссылки на сущность параметра, то в этом тексте должен находиться и второй из указанных символов.
Ограничение корректности: Сущности параметров во внутреннем наборе
Во внутреннем наборе Dtd ссылка на сущность параметра может появляться только в тех местах, где могут расположиться декларации разметки, но не в самой декларации разметки. (Это не относится к ссылкам во внешних сущностях параметров или во внешнем наборе.)
Ограничение корректности: Внешний набор
Внешний набор, если таковой имеется, должен соответствовать сценарию для extSubset.
Ограничение корректности: Сущность параметра между декларациями
Текст замены для ссылки на сущность параметра в DeclSep должен соответствовать сценарию extSubsetDecl.
Вслед за внутренним набором, внешний набор и любые внешние сущности параметров, на которые делается ссылка в DeclSep, должны состоять из полных наборов деклараций разметки для типов, которые разрешены неграничным символом markupdecl, в сочетании с пробельными символами и ссылками на сущности параметров. При этом отдельные фрагменты содержимого внешнего набора или сущностей внешних параметров при определенных условиях могут игнорироваться в случае построения условных секций. Во внутреннем наборе использовать такие секции не разрешается.
Внешний набор
[30]
extSubset
::=
TextDecl?
extSubsetDecl
[31]
extSubsetDecl
::=
( markupdecl | conditionalSect | DeclSep)*
/* */
Внешний набор и внешние сущности параметров отличаются от внутреннего набора также и тем, что для них ссылка на сущность параметра может появляться не только в интервалах между декларациями разметки, но и в границах самих этих деклараций.
Пример XML документа с декларацией типа документа:
<?xml version="1.0"?> <!DOCTYPE greeting SYSTEM "hello.dtd"> <greeting>Hello, world!</greeting>
Системный идентификатор "hello.dtd" указывает адрес Dtd этого документа (ссылку URI).
Декларации также могут быть представлены локально, как это делается в следующем примере:
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE greeting [ <!ELEMENT greeting (#PCDATA)> ]> <greeting>Hello, world!</greeting>
Если используются и внешний, и внутренний наборы деклараций, то внутренний набор рассматривается прежде внешнего. Как следствие этого, декларации сущностей и списка атрибутов во внутреннем наборе имеют приоритет над аналогичными декларациями во внешнем наборе.
2.9 Декларация одиночного документа
Декларации разметки, которые XML процессор передает приложению, могут оказывать влияние на содержимое документа. Примером могут служить атрибуты по умолчанию и декларации сущностей. Декларация одиночного документа, которая может быть представлена в составе XML декларации, указывает, могут ли возникать декларации в сущностях параметров, а также декларации, внешние по отношению к сущности документа. [Определение: Внешняя декларация разметки определяется как декларация разметки, встретившаяся во внешнем наборе или в сущности параметра (внешней или внутренней, последний вариант был включен в спецификацию только потому, что непроверяющие процессоры читать их не обязаны).]
Декларация одиночного документа
[32]
SDDecl
::=
S 'standalone' Eq (("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"'))
[VC: Декларация одиночного документа]
Значение "yes" в декларации одиночного документа говорит об отсутствии внешних деклараций разметки, которые оказывали бы влияние на информацию, которую XML процессор передает приложению. Значение "no" указывает на то, что такие внешние декларации разметки имеются, либо могут быть появиться. Заметим, что декларация одиночного документа всего лишь свидетельствует о присутствии внешних деклараций. Наличие же в документе ссылок на внешние сущности, если последние уже были декларированы в самом документе, статуса одиночного документа не отменяет.
Если внешние декларации разметки отсутствуют, то декларация одиночного документа теряет смысл. Если присутствуют внешние декларации разметки, но отсутствует декларация одиночного документа, подразумевается что она имеет значение "no".
Любой XML документ, для которого было указано standalone="no", может быть алгоритмическим путем приведен к одиночному документу, что может потребоваться для некоторых приложений, получающих данные по сети.
Ограничение действительности: Декларация одиночного документа
Декларация одиночного документа должна иметь значение "no", если какие-либо внешние декларации разметки включают декларацию для:
amp, lt, gt, apos и quot), если в документе встретились ссылки на эти сущности,
Пример декларации XML с декларированием одиночного документа:
<?xml version="1.0" standalone='yes'?>
2.10 Обработка пробельных символов
В ходе редактирования XML документов часто бывает удобно воспользоваться "пробельными символами" (white space - пробелы, табуляторы и пустые строки) для выделения разметки для лучшей читаемости. Такие пробельные символы обычно не должны попадать в ту версию документа, которая передается в приложение. С другой стороны, часто встречаются "значимые" пробельные символы, которые должны быть оставлены в передаваемом документе, например если это стихи или исходный код программы.
XML процессор должен всегда передавать приложению все символы документа, не относящиеся к разметке. Проверяющий XML процессор дополнительно должен проинформировать приложение о том, какие из этих символов соответствуют пробельным символам в содержимом элемента.
К элементу может быть приставлен специальный атрибут, называемый xml:space, для того чтобы показать, что пробельные символы в этом элементе должны быть сохранены. Если этот атрибут используется в действительных документах, то, как и любой другой, он должен быть декларирован. Будучи декларирован, он должен быть представлен как перечислимый тип, значениями которого являются одно или оба значения "default" и "preserve". Например:
<!ATTLIST poem xml:space (default|preserve) 'preserve'> <!-- --> <!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>
Значение атрибута "default" говорит о том, что для данного элемента используется режим обработки пробельных символов, применяемый в приложениях по умолчанию. Значение "preserve" говорит о том, что приложения должны сохранить все пробельные символы. Декларированное таким образом правило относится ко всем элементам, находящимся среди содержимого того элемента, которому был назначен данный атрибут (при условии что это правило не было затем переопределено другим экземпляром атрибута xml:space).
Считается что корневой элемент любого документа не имеет указаний о том, каким образом приложение будет обрабатывать пробелы, если для этого атрибута не было дано соответствующего значения и этот атрибут не был представлен среди значений по умолчанию.
Часто разобранные сущности XML, помещенные в компьютерные файлы, для удобства редактирования представляются в виде набора строк. В качестве разделителя для таких строк обычно используется некая комбинация символов возврата каретки (#xD) и конца строки (#xA).
Чтобы облегчить работу приложений, текст, который им передает XML процессор, должен быть таким, как если бы этот процессор при выводе перед обработкой нормализовал все концы строк во внешних разобранных сущностях (а также сущности самого документа). Осуществляться это должно путем замены последовательности из двух символов #xD #xA (а также одиночного #xD, за которым не следует #xA) одним символом #xA.
В ходе обработки документа часто бывает полезным идентифицировать, на каком из естественных или формальных языков он был записан. Для идентификации языка, который использовался при записи содержимого и значений атрибутов любого элемента, в документе может быть указан специальный атрибут с названием xml:lang. Если этот атрибут используется в действительном документе, то, как и любой другой, он должен быть декларирован. Значением этого атрибута являются идентификаторы языков, определенные в документе [IETF RFC 1766] (Тэги для идентификации языков) или наследующих его стандартах IETF.
Замечание:
В [IETF RFC 1766] указанные тэги строятся из двухсимвольного кода языка, заданного в [ISO 639], двухсимвольного кода страны, определенного в [ISO 3166] или же языкового идентификатора, зарегистрированного в Internet Assigned Numbers Authority [IANA-LANGCODES]. Предполагается, что для идентификации языков, которые в настоящий момент не упомянуты в спецификации [ISO 639], стандарты, наследующие [IETF RFC 1766], будут дополнены трехсимвольными кодами.
(Сценарии грамматики с 33 по 38 изъяты из спецификации.)
Например:
<p xml:lang="en">The quick brown fox jumps over the lazy dog.</p> <p xml:lang="en-GB">What colour is it?</p> <p xml:lang="en-US">What color is it?</p> <sp who="Faust" desc='leise' xml:lang="de"> <l>Habe nun, ach! Philosophie,</l> <l>Juristerei, und Medizin</l> <l>und leider auch Theologie</l> <l>durchaus studiert mit heiЯem Bemьh'n.</l> </sp>
Предполагается, что информация, представленная в xml:lang, относится ко всем атрибутам и всему содержимому элемента, где этот атрибут был указан (при условии, что в содержимом этого элемента она не была затем переопределена новым экземпляром атрибута xml:lang в другом элементе).
Простая декларация атрибута xml:lang может иметь вид
xml:lang NMTOKEN #IMPLIED
Если это необходимо, для этого атрибута могут быть представлены значения по умолчанию. В сборнике французской поэзии (poem) для английских студентов, содержащем глоссарий (gloss) и пометки на английском языке (note), атрибут xml:lang может быть декларирован следующим образом:
<!ATTLIST poem xml:lang NMTOKEN 'fr'> <!ATTLIST gloss xml:lang NMTOKEN 'en'> <!ATTLIST note xml:lang NMTOKEN 'en'>
[Определение: Каждый XML документ содержит один или несколько элементов, границы каждого из которых обозначены либо парой начальный тэг - конечный тэг, либо (если это пустой элемент) тэгом пустого элемента. Каждый элемент имеет определенный тип, который идентифицируется по имени и иногда называется "общим идентификатором" этого элемента (generic identifier - GI), а также может иметь набор спецификаций к атрибутам.] Каждая спецификация атрибута содержит его имя и значение.
Элемент
[39]
element
::=
EmptyElemTag
| STag content ETag
[WFC: Соответствие типов элементов]
[VC: Действительность элемента]
Данная спецификация не ограничивает семантику, порядок использования (за исключением синтаксиса), выбор имен для атрибутов и типов элементов. Ограничение заключается в том, что имена, чье начало соответствует шаблону (('X'|'x')('M'|'m')('L'|'l')), зарезервированы для стандартизации в текущей и последующих версиях данной спецификации.
Ограничение корректности: Соответствие типов элементов
Параметр Name в конечном тэге элемента должен соответствовать типу элемента в начальном тэге.
Ограничение действительности: Действительность элемента
Элемент считается действительным, если имеется декларация, соответствующая elementdecl, в которой параметр Name соответствует типу элемента, а также выполняется одно из следующих условий:
3.1 Начальные тэги, конечные тэги и тэги пустых элементов
[Определение: Начало любого непустого XML элемента помечается начальным тэгом.]
Начальный тэг
[40]
STag
::=
'<' Name (S Attribute)* S? '>'
[WFC: Уникальность спецификации атрибута]
[41]
Attribute
::=
Name Eq AttValue
[VC: Тип значения атрибута]
[WFC: Отсутствие ссылок на внешние сущности]
[WFC: Отсутствие символов < в значениях атрибута]
Параметр Name в начальном и конечном тэгах определяет тип элемента. [Определение: Пара Name - AttValue называется спецификацией атрибута для данного элемента], [Определение: Параметр Name в каждой такой паре называется именем атрибута], а [Определение: содержимое поля AttValue - текст в одинарных (') или двойных (") кавычках - называется значением атрибута.] Заметим, что очередность появления спецификаций атрибутов в начальном тэге или тэге пустого элемента значения не имеет.
Ограничение корректности: Уникальность спецификации атрибута
В границах одного начального тэга (или тэга пустого элемента) одно и то же имя атрибута не может появляться более одного раза.
Ограничение действительности: Тип значения атрибута
Атрибут должен быть декларирован, его значение должно иметь тот тип, который был декларирован для него. (Описание типов атрибутов см. в главе 3.3 Декларации списков атрибутов.)
Ограничение корректности: Отсутствие ссылок на внешние сущности
Значение атрибута не может иметь содержать прямых или косвенных ссылок на внешние сущности.
Ограничение корректности: Отсутствие символов < в значениях атрибута
Символ < не может содержаться в тексте замены для сущностей, на которые в значении атрибута прямо или косвенно дается ссылка.
Пример начального тэга:
<termdef id="dt-dog" term="dog">
[Определение: Любой элемент, чье начало отмечено начальным тэгом, должен завершиться конечным тэгом, имя которого повторяет тип элемента, указанный в начальном тэге:]
Конечный тэг
[42]
ETag
::=
'</' Name S? '>'
Пример конечного тэга:
</termdef>
[Определение: Текст, заключенный между начальным и конечным тэгами, называется содержимым элемента:]
Содержимое элементов
[43]
content
::=
CharData? ((element | Reference | CDSect | PI | Comment) CharData?)*
/* */
[Определение: Элемент без содержимого называется пустым элементом.] Пустой элемент может быть представлен либо в виде начального тэга, за которым сразу же следует конечный тэг, либо как тэг пустого элемента. [Определение: Тэг пустого элемента имеет специальный формат:]
Тэги пустых элементов
[44]
EmptyElemTag
::=
'<' Name (S Attribute)* S? '/>'
[WFC: Уникальность спецификации атрибута]
Тэг пустого элемента может быть использован для любого элемента, не имеющего содержимого, независимо от того, был ли последний декларирован с ключевым словом EMPTY. В целях совместимости, тэг пустого элемента должен использоваться для элементов, которые были декларированы как EMPTY, и только для них.
Примеры пустых элементов:
<IMG align="left" src="http://www.w3.org/Icons/WWW/w3c_home" /> <br></br> <br/>
Для достижения действительности, на структуру элементов в XML документе могут быть наложены ограничения в виде деклараций типов используемых элементов и списков атрибутов. Декларирование типа элемента накладывает ограничение на его содержание.
Декларация типа элемента часто конкретизирует тип его непосредственных потомков. По выбору пользователя, XML процессор может генерировать предупреждение если в декларации был упомянут тип элемента, для которого не было предоставлено соответствующей декларации, однако ошибочной эта ситуация не считается.
[Определение: Декларация типа элемента имеет вид:]
Декларация типа элемента
[45]
elementdecl
::=
'<!ELEMENT' S Name S contentspec S? '>'
[VC: Уникальность декларации типа элемента]
[46]
contentspec
::=
'EMPTY' | 'ANY' | Mixed | children
где параметр Name определяет декларируемый тип элемента.
Ограничение действительности: Уникальность декларации типа элемента
Ни один тип элемента не может быть декларирован более одного раза.
Примеры деклараций типа элемента:
<!ELEMENT br EMPTY> <!ELEMENT p (#PCDATA|emph)* > <!ELEMENT %name.para; %content.para; > <!ELEMENT container ANY>
[Определение: Тип элемента определяет содержимое элемента, если элементы указанного типа обязаны не иметь символьных данных, а только непосредственные элементы-потомки, которые могут отделяться друг от друга пробельными символами (символами, соответствующими неграничному S).] [Определение: В этом случае накладываемое на элемент ограничение содержит модель содержимого - простую грамматику, управляющую допустимыми типами непосредственных элементов-потомков и порядком, в котором им разрешено появляться.] Указанная грамматика строится из фрагментов содержания (cp), которые содержат название, списки выбора и последовательные списки фрагментов содержания:
Модели содержимого элемента
[47]
children
::=
(choice | seq) ('?' | '*' | '+')?
[48]
cp
::=
(Name | choice | seq) ('?' | '*' | '+')?
[49]
choice
::=
'(' S? cp ( S? '|' S? cp )+ S? ')'
/* */
>
/* */
[VC: Правильная вложенность Group/PE]
[50]
seq
::=
'(' S? cp ( S? ',' S? cp )* S? ')'
/* */
[VC: Правильная вложенность Group/PE]
где каждая запись Name - это тип элемента, который может выступить в роли непосредственного потомка. Любой фрагмент содержимого в списке выбора может быть помещен в содержимое элемента в то место, где согласно грамматике располагался соответствующий список выбора. Все фрагменты содержимого в последовательном списке должны быть вставлены в содержимое элемента и именно в том прядке, как они были представлены в исходном списке. Необязательный символ, следующий за именем (или списком), указывает, должен ли данный элемент (или фрагменты из данного списка) быть повторен один или более раз (+), нуль или более раз (*), либо нуль или один раз (?). Отсутствие такого оператора означает, что данный элемент (или фрагмент) должен появиться ровно один раз. Представленный синтаксис и его значение те же самые, что используются в сценариях самой спецификации.
Содержимое элемента соответствует модели содержания тогда и только тогда, когда можно проследить способ его получения из этой модели в соответствии с операторами последовательности, выбора и повторения, а также такой, что каждый элемент в содержании соответствует типу элемента в модели содержания. Если какой-либо элемент в документе может быть сопоставлен нескольким типам элементов в модели содержания, то для сохранения совместимости процессор должен фиксировать ошибку. За дополнительной информацией обращайтесь к Приложению E Детерминистические модели содержания.
Ограничение действительности: Правильная вложенность Group/PE
Текст замены для сущности параметра должен иметь правильно вложенные группы скобок. Иными словами, если в конструкциях choice, seq или Mixed открывающая или закрывающая скобка была включена в текст замены для сущности параметра, то в этот текст должна попадать и вторая парная скобка.
Если в конструкциях choice, seq или Mixed обнаружена ссылка на сущность параметра, то, для совместимости, ее текст замены должен содержать хотя бы один символ, отличный от пробела. И ни первый, ни последний символ в тексте замены, отличный от пробела, не должен быть соединителем (| или ,).
Примеры моделей содержимого элемента:
<!ELEMENT spec (front, body, back?)> <!ELEMENT div1 (head, (p | list | note)*, div2*)> <!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*>
[Определение: Какой-либо тип элемента имеет смешанный контент, если элементы этого типа могут содержать символьные данные, возможно чередуемые с элементами-потомками.] В таком случае ограничения модели могут касаться лишь типа непосредственных элементов-потомков, но не порядка их следования и количества экземпляров:
Декларация смешанного контента
[51]
Mixed
::=
'(' S? '#PCDATA' (S? '|' S? Name)* S? ')*'
| '(' S? '#PCDATA' S? ')'
[VC: Правильная вложенность Group/PE]
[VC: Отсутствие дублирования типов]
где параметр Name определяет тип элементов, которые могут быть использованы в роли непосредственных потомков. Ключевое слово #PCDATA исторически унаследовано от термина "parsed character data".
Ограничение действительности: Отсутствие дублирования типов
Одно и то же имя не может быть представлено в декларации смешанного контента более одного раза.
Примеры деклараций смешанного контента:
<!ELEMENT p (#PCDATA|a|ul|b|i|em)*> <!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* > <!ELEMENT b (#PCDATA)>
3.3 Декларации списка атрибутов
Атрибут используется для того, чтобы связать с элементом пару имя-значение. Спецификация атрибута может быт дана только в начальном тэге, либо тэге пустого элемента. Таким образом, сценарии ее обработки следует искать в главе 3.1 Начальные тэги, конечные тэги и тэги пустых элементов. Декларация списка атрибутов может быть использована для:
[Определение: для каждого атрибута, относящегося к элементам определенного типа, в соответствующей декларации списка атрибутов определяются имя, тип данных и, возможно, значение по умолчанию:]
Декларация списка атрибутов
[52]
AttlistDecl
::=
'<!ATTLIST' S Name AttDef* S? '>'
[53]
AttDef
::=
S Name S AttType S DefaultDecl
В поле Name в правиле AttlistDecl указывается тип элемента. По выбору пользователя, XML процессор может генерировать предупреждение, если атрибуты, декларированные для такого типа элементов, сами декларированы не были, однако ошибкой такая ситуация не считается. Параметр Name в правиле AttDef соответствует имени описываемого атрибута.
Если для какого-либо из типов элементов было дано несколько деклараций AttlistDecl, то содержимое всех их суммируется. Если для некого типа элементов было дано несколько деклараций одного и того же атрибута, то использоваться должна только первая декларация, а все последующие будут игнорироваться. Для сохранения совместимости, авторы Dtd могут придерживаться правила давать для любого типа элементов не более одной декларации списка атрибутов, не более одной декларации для каждого имени атрибута, представленного в декларации списка атрибутов и, по крайней мере, одну декларацию атрибута в каждой из деклараций списка атрибутов. В целях совместимости, XML процессор по выбору пользователя может генерировать предупреждение, если для какого-либо типа элементов было представлено более одной декларации списка атрибутов, или для какого-либо атрибута было представлено более одной декларации, однако описанные ситуации ошибочными не являются.
Все типы XML атрибутов делятся на три класса: строковый тип, набор символьных (tokenized) типов и перечислимые (enumerated) типы. Строковый тип может иметь в качестве значения одну строку. Символьные типы содержат различные лексические и семантические ограничения. Ограничения действительности, обсуждаемые в данной грамматике, начинают действовать после того, как значение атрибута было нормализовано в соответствии с описанием в главе 3.3 Декларации списков атрибутов.
Типы атрибутов
[54]
AttType
::=
StringType | TokenizedType | EnumeratedType
[56]
TokenizedType
::=
'ID'
[VC: ID]
[VC: Один ID для каждого типа элементов]
[VC: Значение по умолчанию для атрибута ID]
| 'IDREF'
[VC: IDREF]
| 'IDREFS'
[VC: IDREF]
| 'ENTITY'
[VC: Имя сущности]
| 'ENTITIES'
[VC: Имя сущности]
| 'NMTOKEN'
[VC: Лексема имени]
| 'NMTOKENS'
[VC: Лексема имени]
Ограничение действительности: 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.
[Определение: Перечислимый атрибут может выбирать одно значение из перечня, предоставленного в декларации]. Существует два вида перечислимых типов:
Типы перечислимых атрибутов
[57]
EnumeratedType
::=
NotationType | Enumeration
[58]
NotationType
::=
'NOTATION' S '(' S? Name (S? '|' S? Name)* S? ')'
[VC: Атрибуты нотации]
[VC: Одна нотация для каждого типа элемента]
[VC: Отсутствие нотаций для пустого элемента]
[59]
Enumeration
::=
'(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')'
[VC: Перечисление]
Атрибут NOTATION идентифицирует нотацию, которая была декларирована в Dtd вместе с ассоциированными с нею системными и/или общими (public) идентификаторами, и которую следует использовать для интерпретации элемента, в котором был указан данный атрибут.
Ограничение действительности: Атрибуты нотации
Значения указанного типа должны соответствовать одному из представленных в декларации названий нотации. Все названия нотаций в декларации в свою очередь также должны быть декларированы.
Ограничение действительности: Одна нотация для каждого типа элемента
Для типа элемента не может указываться более одного атрибута NOTATION.
Ограничение действительности: Отсутствие нотаций для пустого элемента
Для сохранения совместимости, для элемента, объявленного как EMPTY, атрибут типа NOTATION декларироваться не должен.
Ограничение действительности: Перечисление
Значения этого типа должны соответствовать одной из лексем Nmtoken, указанных в декларации.
Чтобы обеспечить взаимодействие, один и тот же Nmtoken должен появляться среди перечислимых типов атрибутов, относящихся к одному типу элементов, не более одного раза.
3.3.2 Значения атрибутов по умолчанию
Декларация атрибута предоставляет сведения о том, обязательно ли присутствие в элементе данного атрибута и, если нет, то как XML процессор должен реагировать на отсутствие в документе декларированного атрибута.
Значение атрибута по умолчанию
[60]
DefaultDecl
::=
'#REQUIRED' | '#IMPLIED'
| (('#FIXED' S)? AttValue)
[VC: Обязательный атрибут]
[VC: Допустимость значения по умолчанию для атрибута]
r />
[WFC: Отсутствие символов < в значениях атрибута]
[VC: Фиксированное значение атрибута по умолчанию]
Запись #REQUIRED в декларации атрибута означает, что этот атрибут должен присутствовать в элементе всегда, #IMPLIED означает, что значения по умолчанию для атрибута не предоставляется. [Определение: Если в декларации нет ни #REQUIRED, ни #IMPLIED, то значение AttValue содержит значение, декларированное по умолчанию. Ключевое слово #FIXED устанавливает, что данный атрибут обязан всегда иметь значение по умолчанию. Если было декларировано значение по умолчанию, то когда XML процессор не обнаруживает этого атрибута, он должен поступать так, словно атрибут присутствует и имеет значение, декларированное по умолчанию.]
Ограничение действительности: Обязательный атрибут
Если для атрибута декларировано по умолчанию ключевое слово #REQUIRED, то в декларации списка атрибутов этот атрибут должен быть указан во всех элементах указанного типа.
Ограничение действительности: Допустимость значения по умолчанию для атрибута
Декларированное значение по умолчанию должно отвечать всем лексическим ограничениям для декларируемого типа атрибута.
Ограничение действительности: Фиксированное значение атрибута по умолчанию
Если атрибут по умолчанию имеет значение, декларированное с ключевым словом #FIXED, то все экземпляры данного атрибута должны соответствовать этому значению по умолчанию.
Примеры деклараций списка атрибутов:
<!ATTLIST termdef id ID #REQUIRED name CDATA #IMPLIED> <!ATTLIST list type (bullets|ordered|glossary) "ordered"> <!ATTLIST form method CDATA #FIXED "POST">
3.3.3 Нормализация значения атрибута
Перед передачей значения атрибута приложению или проверкой его корректности XML процессор должен выполнить нормализацию полученного значения атрибута по описанному далее алгоритму либо как-нибудь иначе, например передав это значение отдельному приложению, реализующему указанный алгоритм.
Если тип атрибута - не 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= "

A

B
"
#xD #xD A #xA #xA B #xD #xA
#xD #xD A #xA #xA B #xD #xD
Заметим, что последний пример недействителен (хотя и корректен), если объявлено, что a имеет тип NMTOKENS.
[Определение: Условная секция является фрагментом внешнего набора для декларации типа документа, которая включается или исключается из логической структуры Dtd в зависимости от значения управляющего ею ключевого слова.]
Условная секция
[61]
conditionalSect
::=
includeSect | ignoreSect
[62]
includeSect
::=
'<![' S? 'INCLUDE' S? '[' extSubsetDecl ']]>'
/* */
[VC: Правильная вложенность условной секции/PE]
[63]
ignoreSect
::=
'<![' S? 'IGNORE' S? '[' ignoreSectContents* ']]>'
/* */
[VC: Правильная вложенность условной секции/PE]
[64]
ignoreSectContents
::=
Ignore ('<![' ignoreSectContents ']]>' Ignore)*
[65]
Ignore
::=
Char* - (Char* ('<![' | ']]>') Char*)
Ограничение действительности: Правильная вложенность условной секции/PE
Если какая-либо из конструкций условной секции ("<![", "[" или "]]>") находится в тексте замены для ссылки на сущность параметра, то в этом тексте должны находиться и все остальные конструкции.
Подобно внутреннему и внешнему наборам Dtd, условная секция тоже может содержать одну или несколько полных деклараций, комментариев, инструкций обработки или же вложенных условных секций, перемежаемых пробельным символом.
Если ключевым словом условной секции является INCLUDE, то содержимое этой секции становится частью Dtd. Если же ключевым словом условной секции является IGNORE, то содержимое секции логической частью Dtd не становится. Если условная секция с ключевым словом INCLUDE была представлена в составе более крупной условной секции с ключевым словом IGNORE, то игнорируются обе внутренняя и внешняя секции. Содержимое игнорируемой условной секции обрабатывается путем изъятия всех символов, стоящих после скобки "[", следующей за ключевым словом, и до того как будет найден конец условной секции (исключение составляет условная секция, начинающияся с "<![" и заканчивающаяся "]]>"). При этом ссылки на сущности параметров не распознаются.
Если ключевое слово условной секции является ссылкой на сущность параметра, то данную сущность параметра необходимо заменить его содержимым до того, как процессор будет решать, включать или игнорировать данную условную секцию.
Например:
<!ENTITY % draft 'INCLUDE' > <!ENTITY % final 'IGNORE' > <![%draft;[ <!ELEMENT book (comments*, title, body, supplements?)> ]]> <![%final;[ <!ELEMENT book (title, body, supplements?)> ]]>
[Определение: XML документ может состоять из одной или нескольких единиц размещения, называемых сущностями. Все сущности имеют содержание (исключение составляют сущность документа и внешний набор Dtd) и идентифицируются по имени.] Каждый XML документ имеет ровно одну сущность, называемую сущностью документа, которая служит стартовой точкой для XML процессора и может содержать документ целиком.
Сущности могут быть разобранными либо неразобранными. [Определение: Содержимое разобранной сущности (parsed entity) называется ее текстом замены. Этот текст рассматривается как составная часть документа.]
[Определение: Неразобранная сущность (unparsed entity) - это ресурс, содержимым которого может быть текст, либо что-нибудь другое. Даже если это текст, это не обязательно должно быть XML. С каждой неразобранной сущностью связана нотация, идентифицируемая по имени. Помимо того, что XML процессор должен предоставить приложению идентификаторы сущности и ее нотацию, спецификация XML не предъявляет никаких требований к содержимому неразобранной сущности.]
Разобранные сущности вызываются по имени посредством ссылки на сущность, а неразобранные сущности - по имени, указанному в значении атрибута ENTITY или ENTITIES.
[Определение: Общая сущность (general entity) - это сущность для использования в содержимом документа. В рамках данной спецификации общие сущности часто обозначаются неформальным термином сущность (entity), если это не приводит к двусмысленности.] [Определение: Сущность параметра - это разобранная сущность для использования в Dtd.] Существует два типа сущностей, использующих различный формат ссылки и распознаваемых в различном контексте. Более того, эти типы занимают разные пространства имен. Сущность параметра и общая сущность с тем же самым именем в действительности являются различными сущностями.
4.1 Ссылки на символ и сущность
[Определение: Ссылка на символ относится к определенному символу из набора ISO/IEC 10646, например, к такому символу, который невозможно получить непосредственно с имеющихся устройств ввода.]
Ссылка на символ
[66]
CharRef
::=
'&#' [0-9]+ ';'
| '&#x' [0-9a-fA-F]+ ';'
[WFC: Допустимый символ]
Ограничение корректности: Допустимый символ
Символ, на который дается ссылка, должен отвечать сценарию Char.
Если ссылка на символ начинается с комбинации "&#x", то все последующие цифры и буквы вплоть до завершающего символа ; образуют шестнадцатеричное представление для кода этого символа, указанного в ISO/IEC 10646. Если же ссылка начинается с комбинации "&#", то все последующие цифры вплоть до завершающего ; образуют десятичное представление кода символа.
[Определение: Ссылка на сущность обращается к содержимому именованной сущности.]
[Определение: Ссылка на разобранные общие сущности использует в качестве ограничителей амперсант (&) и символ точки с запятой (;).]
[Определение: Ссылка на сущность параметра используют в качестве ограничителей символы процента (%) и точки с запятой (;).]
Ссылка на сущность
[67]
Reference
::=
EntityRef | CharRef
[68]
EntityRef
::=
'&' Name ';'
[WFC: Декларированная сущность]
[VC: Декларированная сущность]
[69]
PEReference
::=
'%' Name ';'
[VC: Декларированная сущность]
Ограничение корректности: Декларированная сущность
Для документа без какого-либо Dtd, для документа, имеющего лишь внутренний набор Dtd, который не содержит ссылок на сущность параметра, а также для документа с декларацией "standalone='yes'": для каждого Name в ссылке на сущность, которая не попадает ни во внешний набор, ни в сущность параметра, должен иметься соответствующий Name в одной из деклараций сущности, которые также не располагаются ни во внешнем наборе, ни в сущности параметра. Исключение составляют корректные (well-formed) документы, для которых нет нужды декларировать сущности amp, lt, gt, apos и quot. Декларация общей сущности должна предшествовать всем ссылкам на нее, которые могут иметься в декларации списка атрибутов в составе значения по умолчанию.
Заметим, что если сущность была декларирована во внешнем наборе или во внешней сущности параметра, то непроверяющий процессор не обязан читать и обрабатывать ее декларацию. Для подобных документов требование декларировать сущности становится условием корректности только если было указано standalone='yes'.
Ограничение действительности: Декларированная сущность
В документе с внешним набором или внешними сущностями параметра, который имеет декларацию "standalone='no'", лексема Name в ссылке на сущность должна соответствовать Name в одной из деклараций сущности. Чтобы обеспечить взаимодействие, действительные документы должны декларировать сущности amp, lt, gt, apos, quot в том формате, который описан в главе 4.6 Предопределенные сущности. Декларация сущности параметра должна предшествовать любым ссылкам на нее. Точно так же декларация общей сущности должна предшествовать любым декларациям списка атрибута, содержащим значение по умолчанию с прямой либо косвенной ссылкой на эту общую сущность.
Ограничение корректности: Разобранная сущность
Ссылка на сущность не должна содержать имени неразобранной сущности. Ссылаться на неразобранные сущности можно только в тех значениях атрибута, которые были декларированы как имеющие тип ENTITY или ENTITIES.
Ограничение корректности: Отсутствие рекурсии
Разобранная сущность не должна иметь рекурсивной ссылки саму на себя, прямой либо косвенной.
Ограничение корректности: В Dtd
Ссылка на сущность параметра может присутствовать только в Dtd.
Примеры ссылок на символ и сущность:
Type <key>less-than</key> (<) to save options. This document was prepared on &docdate; and is classified &security-level;.
Пример ссылки на сущность параметра:
<!-- declare the parameter entity "ISOLat2"... --> <!ENTITY % ISOLat2 SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" > <!-- ... now reference it. --> %ISOLat2;
[Определение: Сущности декларируются следующим образом:]
Декларация сущности
[70]
EntityDecl
::=
GEDecl | PEDecl
[71]
GEDecl
::=
'<!ENTITY' S Name S EntityDef S? '>'
[72]
PEDecl
::=
'<!ENTITY' S '%' S Name S PEDef S? '>'
[73]
EntityDef
::=
EntityValue | (ExternalID NDataDecl?)
[74]
PEDef
::=
EntityValue | ExternalID
Name используется для идентификации сущности в соответствующей ссылке на сущность, а также идентифицирует неразобранную сущность в значении атрибута ENTITY или ENTITIES. Если одна и та же сущность была декларирована несколько раз, то используется лишь первая из найденых деклараций. По выбору пользователя, XML процессор может генерировать предупреждение в случае, если имеет место многократное декларирование сущностей.
[Определение: Если сущность декларирована как EntityValue, то она называется внутренней сущностью. Для этой сущности отсутствует размещаемый отдельно физический объект, а нее содержание определяется в декларации.] Заметим, что в строковом значении сущности для создания приемлемого текста замены может потребоваться некоторая обработка ссылок на сущность и символ: см. главу 4.5 Построение текста замены для внутренней сущности.
Внутренняя сущность является разобранной сущностью.
Пример декларации внутренней сущности:
<!ENTITY Pub-Status "This is a pre-release of the specification.">
[Определение: Если сущность не является внутренней, это внешняя сущность, декларируемая следующим образом:]
Декларация внешней сущности
[75]
ExternalID
::=
'SYSTEM' S SystemLiteral
| 'PUBLIC' S PubidLiteral S SystemLiteral
[76]
NDataDecl
::=
S 'NDATA' S Name
[VC: Декларированная нотация]
Если в декларации присутствует NDataDecl, то это общая неразобранная сущность. В противном случае, сущность является разобранной.
Ограничение действительности: Декларированная нотация
Name должно соответствовать декларированному имени нотации.
[Определение: Литерал SystemLiteral называется системным идентификатором сущности. Он представляет собой ссылку URI (чье определение было дано в [IETF RFC 2396], а затем дополнено в [IETF RFC 2732]), которую необходимо разобрать, чтобы получить данные на вход XML процессора и сформировать текст замены для указанной сущности.] Если идентификатор фрагмента (начинающийся с символа #) окажется в составе системного идентификатора, фиксируется ошибка. Для обработки относительных адресов URI в качестве базового берется адрес того источника, в котором была обнаружена декларация данной сущности, если обратное не было указано в ином источнике информации помимо данной спецификация (например, когда специальный тип XML элемента был определен в отдельном Dtd или инструкция обработки определена спецификацией конкретного приложения). Таким образом, URI может вычисляться относительно сущности документа, относительно сущности, содержащей внешний набор Dtd, или какой-либо другой внешней сущности параметра.
Ссылки URI требуют кодирования и маскирования (escaping) определенных символов. Среди запрещенных символов числятся все не-ASCII символы, а также исключенные символы, перечисленные в главе 2.4 документа [IETF RFC 2396]. Исключение составляют символы решетки (#) и процента (%), а также символы квадратных скобок, разрешенные документом [IETF RFC 2732]. Запрещенные символы необходимо маскировать следующим образом:
%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.png" NDATA gif >
Каждая внешняя разобранная сущность должна начинаться с декларации текста.
Декларация текста
[77]
TextDecl
::=
'<?xml' VersionInfo? EncodingDecl S? '?>'
Декларация текста должна быть предоставлена строкой, а не ссылкой на разобранную сущность. Декларация текста не может находиться где-либо еще, кроме как в начале внешней разобранной сущности. Декларация текста во внешней разобранной сущности не является частью текста замены последней.
4.3.2 Корректные разобранные сущности
Сущность документа является корректной, если она соответствует сценарию document. Внешняя общая разобранная сущность является корректной, если она соответствует сценарию extParsedEnt. Все внешние сущности параметров являются корректными по определению.
Корректная внешняя разобранная сущность
[78]
extParsedEnt
::=
TextDecl? content
Внутренняя общая разобранная сущность является корректной если ее текст замены соответствует сценарию content. Все внутренние сущности параметров являются корректными по определению.
Следствием корректности сущностей является правильная вложенность логических и физических структур в XML документе: начальный тэг и конечный тэг, тэг пустого элемента, элемент, комментарий, инструкция обработки, ссылка на символ, а также ссылка на сущность не могут начинаться в одной сущности и заканчиваться в другой.
4.3.3 Кодирование символов в сущностях
Каждая из внешних разобранных сущностей в XML документе для своих символов может использовать собственную кодировку. Все XML процессоры должны уметь читать сущности в кодировках UTF-8 и UTF-16. В данной спецификации термины "UTF-8" и "UTF-16" не имеют отношения к кодировкам символов с какими-либо иными названиями, даже если эти кодировки и названия очень похожи на UTF-8 или UTF-16.
Сущности с кодировкой UTF-16 должны начинаться с Byte Order Mark, описанного в Приложении F документа [ISO/IEC 10646], Приложении H документа [ISO/IEC 10646-2000], главе 2.4 документа [Unicode] и главе 2.7 документа [Unicode3] (символ ZERO WIDTH NO-BREAK SPACE, #xFEFF). Причем это сигнатура кодировки, а не фрагмент разметки или символьных данных XML документа. XML процессоры должны уметь с помощью этого символа различать документы в кодировках UTF-8 и UTF-16.
Хотя от XML процессор обязуется читать сущности в кодировках UTF-8 и UTF-16, в мире существует и иные кодировки. Поэтому XML процессору потребуется читать сущности и в других кодировках. В отсутствие внешней информации о кодировке символа (например, в MIME заголовке), разобранные сущности, представленные в иной кодировке, нежели UTF-8 и UTF-16, должны начинаться с декларации текста (см. главу 4.3.1 Декларация текста), содержащей декларацию кодировки:
Декларация кодировки
[80]
EncodingDecl
::=
S 'encoding' Eq ('"' EncName '"' | "'" EncName "'" )
[81]
EncName
::=
[A-Za-z] ([A-Za-z0-9._] | '-')*
/* Названия кодировок содержат только латинские символы */
В сущности document декларация кодировки является частью декларации XML. EncName здесь - название используемой кодировки.
Значения "UTF-8", "UTF-16", "ISO-10646-UCS-2" и "ISO-10646-UCS-4" в декларации кодировки должны относиться к различным кодировкам и трансформациям из набора Unicode / ISO/IEC 10646, значения "ISO-8859-1", "ISO-8859-2", ... "ISO-8859-n" (где n - номер раздела) - к соответствующим разделам кодировки ISO 8859, а значения "ISO-2022-JP", "Shift_JIS" и "EUC-JP" - к различным кодированным формам набора JIS X-0208-1997. Желательно, чтобы обращение к остальным кодировкам символов, зарегистрированным (как наборы символов) в Internet Assigned Numbers Authority [IANA-CHARSETS], осуществлялось через официальное название. Для названий остальных кодировок должны использоваться префиксы "x-". XML процессоры должны игнорировать верхний и нижний регистр в названии кодировки. Процессор должен либо интерпретировать зарегистрированное в IANA название как указание на использование зарегистрированной под этом именем кодировки, либо считать кодировку неизвестной (разумеется, один процессор не обязуется поддерживать все кодировки, которые были зарегистрированы в IANA).
Если сущность, содержащая декларацию кодировки, предоставлена XML процессору в иной кодировке, чем было заявлено в этой декларации, или сущность, которая не начинается ни с Byte Order Mark, ни с декларации кодировки, была представлена в иной кодировке, нежели UTF-8, а внешний транспортный протокол (например, HTTP или MIME) не предоставил требуемой информации, будет зафиксирована ошибка. Заметим, что поскольку ASCII - является подмножеством UTF-8, то ASCII сущности обычно не нуждаются в декларации кодировки.
Если TextDecl обнаружена не в начале внешней сущности, фиксируется фатальная ошибка.
Если XML процессор сталкивается с сущностью, чью кодировку он не может обработать, фиксируется фатальная ошибка. Фатальная ошибка фиксируется также если было указано (значением по умолчанию, декларацией кодировки или протоколом верхнего уровня), что XML сущность использует определенную кодировку, но в то же время содержит последовательности октетов, которые для этой кодировки недопустимы. Ну и наконец, фатальная ошибка фиксируется, если XML сущность не имеет декларации кодировки, а ее содержимое не относится ни к UTF-8, ни к UTF-16.
Примеры деклараций текста, содержащих декларацию кодировки:
<?xml encoding='UTF-8'?> <?xml encoding='EUC-JP'?>
4.4 Обработка XML процессором сущностей и ссылок
В представленной далее таблице собраны сведения о контексте, в котором могут появиться ссылки на символы, ссылки на сущность, а также вызовы неразобранных сущностей, и какая в каждом случае потребуется реакция от XML процессора. Записи в левой колонке описывают распознаваемый контекст:
Ссылка в содержимом
Ссылка в любом месте элемента в интервале между начальным и конечным тэгами. Соответствует незавершенному (nonterminal) контенту.
Ссылка в значении атрибута
Ссылка либо в значении атрибута начального тэга, либо в значении по умолчанию из декларации атрибута. Соответствует незавершенному AttValue.
Значение атрибута
Это не ссылка, а лексема типа Name. Выступает либо как значение атрибута, декларированного с типом ENTITY, либо как одна из лексем, перечисленных через пробел в значении атрибута, декларированного с типом ENTITIES.
Ссылка в значении сущности
Ссылка из параметра или строкового значения внутренней сущности, находящихся в декларации сущности. Соответствует незавершенной EntityValue.
Ссылка в Dtd
Ссылка во внутреннем или внешнем наборе Dtd, не попавшая в конструкции EntityValue, AttValue, PI, Comment, SystemLiteral, PubidLiteral, а также содержимое игнорируемой условной секции (см. главу 3.4 Условные секции).
Тип сущности
Символ
Параметр
Внутренняя общая
Внешняя разобранная общая
Неразобранная
Ссылка в содержимом
Не распознается
Включается
Включается при проверке
Запрещен
Включается
Ссылка в значении атрибута
Не распознается
Включен в строку
Запрещен
Запрещен
Включается
Значение атрибута
Не распознается
Запрещен
Запрещен
Уведомление
Не распознается
Ссылка в значении сущности
Включается как строка
Пропускается
Пропускается
Запрещен
Включается
Ссылка в Dtd
Включается как сущность параметра
Запрещен
Запрещен
Запрещен
Запрещен
За пределами Dtd символ % теряет специальное значение, поэтому в Dtd могут появляться ссылки на сущность параметра, которые в содержимом элемента не распознаются как разметка. Аналогично, названия неразобранных сущностей распознается только в значении соответствующим образом декларированного атрибута.
[Определение: Сущность называется включенной, если вместо первоначальной ссылки был взят соответствующий текст замены и затем обработан так, словно это был фрагмент документа, находящийся в том месте, где располагалась исходная ссылка.] Текст замены может включать и символьные данные, и (за исключением сущностей параметров) разметку, которые должны распознаваться обычным образом. (Например, строка "AT&T;" преобразуется в "AT&T;", а оставшийся в ней амперсант рассматривается не как ограничитель ссылки на сущность.) Ссылка на символ считается включенной, если вместо этой ссылки обрабатывается указываемый ею символ.
Если XML процессор обнаруживает ссылку на разобранную сущность, то для проверки действительности документа, он должен осуществить подстановку соответствующего текста замены. Если же сущность является внешней, и процессор не предпринимает попыток проверить XML документ, то он хотя и может, но уже не обязан включать в документ текст замены для этой сущности. Если непроверяющий процессор не выполнял подстановки текста замены, он должен информировать приложение о том, что данную сущность он обнаружил, но не прочел.
Представленное положение исходит из того, что автоматическая подстановка, предоставляемая механизмом обработки сущностей SGML и XML, первоначально предназначалась для поддержки модульности при авторизации и не должен был использоваться другими приложениями, например для просмотра данного документа. Например, программа просмотра, встречаясь со ссылкой на внешнюю разобранную сущность, может использовать визуальную индикацию имеющейся ссылки, а саму сущность выводить на экран только по требованию пользователя.
Следующие ситуации относятся к разряду запрещенных и соответствуют фатальной ошибке:
ссылка на внешнюю сущность в значении атрибута.
Если в значении атрибута обнаружена ссылка на сущность, или в строчном значении сущности обнаружена ссылка на сущность параметра, то вместо этой ссылки обрабатывается ее текст замены, словно это был фрагмент документа, находившийся в том месте, где была обнаружена исходная ссылка. Исключение составляют символы одинарной или двойной кавычки, которые в тексте замены всегда воспринимаются как обычный символ данных, а не как завершение соответствующей строки. Например, следующий пример является корректным:
<!-- --> <!ENTITY % YN '"Yes"' > <!ENTITY WhatHeSaid "He said %YN;" >
а этот - нет:
<!ENTITY EndAttr "27'" > <element attribute='a-&EndAttr;>
Если название неразобранной сущности было представлено в качестве лексемы в значении атрибута с декларированным типом ENTITY или ENTITIES, то проверяющий процессор должен передать приложению сведения о системных и публичных (если таковые имеются) идентификаторах данной сущности и связанной с нею нотации.
Если в декларации сущности в поле EntityValue обнаружена ссылка на общую сущность, она пропускается и оставляется без изменений.
4.4.8 Включается как сущность параметра
Поскольку это внешняя разобранная сущность, то потребность в подстановке сущности параметра должна появляться только при проверке. Если в Dtd обнаружена ссылка на сущность параметра и выполняется подстановка ее текста замены, то к последнему в начале и конце должно быть приставлено по одному символу пробела (#x20). Этим гарантируется, что текст замены для сущностей параметров будет содержать полный набор грамматических лексем Dtd. Описанное положение не относится к ссылкам на сущность параметра в значении сущности - ситуации, описанной в главе 4.4.5 Включается как строка.
4.5 Построение текста замены для внутренней сущности
Обсуждая процедуру обработки внутренних сущностей, полезно различать два вида значений сущности. [Определение: Строковое значение сущности - это строка в кавычках, которая реально присутствует в декларации сущности и соответствует незавершенному EntityValue.] [Определение: Текст замены - это содержимое сущности после подстановки всех ссылок на символ и сущность параметра.]
Строковое значение сущности, данное в декларации внутренней сущности (EntityValue), может содержать ссылки на символ, на сущность параметра и на общую сущность. Такие ссылки должны целиком содержаться в строковом значении сущности. Реально подставляемый текст замены должен содержать текст замены для всех сущностей параметров и все символы, на которые делалась ссылка, причем в тех местах строкового значения сущности, где эти ссылки находились. Вместе с тем, ссылки на общие сущности должны оставаться без изменений. Например, даны следующие декларации:
<!ENTITY % pub "Éditions Gallimard" > <!ENTITY rights "All rights reserved" > <!ENTITY book "La Peste: Albert Camus, © 1947 %pub;. &rights;" >
тогда текст замены для сущности "book":
La Peste: Albert Camus, © 1947 Éditions Gallimard. &rights;
Ссылка на общую сущность "&rights;" должна расшифроваться только тогда, когда ссылка "&book;" попадает в содержимое документа или значение атрибута.
Эти простые правила могут иметь сложные взаимоотношения. Детальное обсуждение сложного примера этого см. в Приложении D Обработка ссылок на сущность и символ.
[Определение: Ссылки на сущность и символ могут быть использованы для маскирования левой угловой скобки, амперсанта и других ограничителей. Для этой цели сформирован целый набор общих сущностей (amp, lt, gt, apos, quot). Также может использоваться числовая ссылка на символ, которая должна обрабатываться как символьные данные и заменяться соответствующим символом сразу по обнаружении. Таким образом, числовые ссылки "<" и "&" могут быть использованы для маскирования символов < и &, встречающихся среди символьных данных.]
Независимо от того, были ли указанные сущности декларированы, они должны распознаваться всеми XML процессорами. Чтобы обеспечить взаимодействие, действительные XML документы перед использованием должны декларировать эти сущности, как и любые другие. Если сущности lt или amp были декларированы, то они должны быть объявлены как внутренняя сущность, чей текст замены - это ссылка на соответствующий маскируемый символ (знак меньше или амперсант). Для этих сущностей необходимо двойное маскирование, чтобы ссылка на них давала корректный результат. Если декларируются сущности gt, apos или quot, то они должны быть представлены как внутренняя сущность, текст замены которой - это одиночный маскируемый символ (либо ссылка на этот символ, двойное маскирование здесь хотя и допустимо, но необязательно). Например:
<!ENTITY lt "&#60;"> <!ENTITY gt ">"> <!ENTITY amp "&#38;"> <!ENTITY apos "'"> <!ENTITY quot """>
[Определение: Нотация идентифицирует по имени формат неразобранных сущностей, формат элементов, обеспечивающих атрибут нотации, или же приложение, которому адресуется инструкция обработки.]
[Определение: Декларация нотации дает этой нотации название, используемое при декларировании сущности, списка атрибутов или в спецификациях атрибутов, а также внешний идентификатор этой нотации, который может позволить XML процессору или его клиентскому приложению найти вспомогательную программу, способную обработать данные, представленные в этой нотации.]
Декларации нотации
[82]
NotationDecl
::=
'<!NOTATION' S Name S (ExternalID | PublicID) S? '>'
[VC: Уникальность имени нотации]
[83]
PublicID
::=
'PUBLIC' S PubidLiteral
Ограничение действительности: Уникальность имени нотации
Любое Name может быть использовано только в одной декларации.
XML процессор должен передать приложению название и внешний идентификатор(ы) всех нотаций, которые были декларированы и на которые имеется ссылка в значениях атрибутов, определениях атрибутов, либо декларациях сущностей. Кроме того, процессор может преобразовывать внешний идентификатор в системный идентификатор, имя файла или иную информацию, необходимую приложению чтобы вызвать процессор для обработки данных в описываемой нотации. (Впрочем, ситуация, когда XML документ декларирует и ссылается на нотацию, для которой не имеется соответствующего процессора обработки в системе, где работают XML процессор или приложение ошибочной не будет.)
[Определение: Сущность документа выступает в качестве корня дерева сущностей, а также как стартовая точка для XML процессора.] В данной спецификации не конкретизируется, каким именно образом XML процессор должен находить сущность документа - в отличие от других сущностей, сущность документа не имеет имени и вполне может появиться во входном потоке процессора вообще без какого-либо идентификатора.
5.1 Проверяющие и непроверяющие процессоры
XML процессоры, отвечающие требованиям спецификации, делятся на два класса: проверяющие и непроверяющие.
И проверяющие, и непроверяющие процессоры должны докладывать о нарушениях правил корректности данной спецификации, выявленных в содержимом сущности документа и содержимом других читаемых разобранных сущностей.
[Определение: Проверяющие процессоры должны сообщить (по выбору пользователя) о нарушении ограничений, сформулированных в декларациях Dtd, а также невозможности соответствовать критериям действительности, представленным в данной спецификации.] Чтобы выполнить это тренбование, проверяющий XML процессор должен прочесть и обработать весь Dtd и все внешние разобранные сущности, на которые в данном документе делается ссылка.
Для проверки корректности от непроверяющего процессора требется проанализировать лишь сущность документа, включая полный внутренний набор Dtd. [Определение: Хотя непроверяющий процессор и не обязан проверять действительность документа, он должен обработать все декларации, найденные во внутреннем наборе Dtd, а также во всех прочитанных им сущностях параметров, но только до первой ссылки на сущность параметра, которую он уже не должен читать. Иными словами, он должен использовать сведения из этих деклараций для нормализации значений атрибутов, подстановки текста замены для внутренних сущностей и предоставления значений по умолчанию для атрибутов.] За исключением случая standalone="yes", процессорам запрещается обрабатывать декларации сущностей и списков атрибутов, расположенные после ссылки на сущность параметра, последняя не читается, поскольку может содержать переопределяющие декларации.
5.2 Использование XML процессоров
Поведение проверяющего XML процессора в значительной мере предсказуемо: он должен почесть все части документа и сообщить обо всех нарушениях правил корректности и действительности. Меньшее требуется от непроверяющего процессора: он не должен читать какие-либо части документа кроме сущности документа. Для использования XML процессоров существенное значение могут иметь два эффекта:
Для достижения максимальной надежности взаимодействия различных XML процессоров, приложения, использующие непроверяющий процессор, не должны обращаться к функциям этих процессоров, не являющимся необязательными. Приложения, которым необходимы такие возможности, как использование атрибутов по умолчанию или внутренние сущности, декларированные во внешней сущности, должны пользоваться проверяющими XML процессорами.
Формальная грамматика языка XML строится в данной спецификации с помощью простой нотации Extended Backus-Naur Form (EBNF). Каждое правило в грамматике определяет один символ (symbol) в следующем формате:
symbol ::= expression
Каждый символ, являющийся оригинальным в языке нормативов, пишется с заглавной буквы. В остальных случаях, первая буква символа прописная. Строки текста помещаются в кавычки.
В правой части правила представлено выражение, использующее следующие конструкции, сопоставляемые строкам из одного или нескольких символов:
#xN
где N - шестнадцатеричное целое число. Данное выражение соответствует символу в кодировке ISO/IEC 10646, каноническое значение кода (UCS-4) которого как беззнаковое целое число, имеет указанное значение. Количество ведущих нулей в формате #xN значения не имеет. Количество ведущих нулей в соответствующем значении кода определяется используемой кодировкой символов и для XML значения не имеет.
[a-zA-Z], [#xN-#xN]
соответствует любому Char, чье значение попадает в указанный диапазон(ы) (включительно).
[abc], [#xN#xN#xN]
соответствует любому Char, чье значение имеется среди перечисленных символов. В пределах одного набора скобок перечисления и диапазоны могут сочетаться.
[^a-z], [^#xN-#xN]
соответствует любому Char, чье значение не входит в указанный диапазон.
[^abc], [^#xN#xN#xN]
соответствует любому Char, чьего значение нет среди указанных символов. В пределах одного набора скобок перечисления и диапазоны запрещенных значений могут сочетаться.
"string"
соответствует строке символов, совпадающей со строкой, представленной в двойных кавычках.
'string'
соответствует строке символов, совпадающей со строкой, представленной в одинарных кавычках.
Представленные символы могут комбинироваться в более сложные шаблоны следующим образом (где A и B представляют собой простые выражения):
(выражение)
данное выражение обрабатывается как единое целое и может комбинироваться с другими выражениями в соответствии с дальнейшим перечнем.
A?
соответствует A или ничему. Необязательная единица A.
A B
соответствует A, за которым следует B. Данный оператор имеет более высокий приоритет, чем оператор альтернативы. Таким образом, A B | C D эквивалентно (A B) | (C D).
A | B
соответствует A или B, но не обоим сразу.
A - B
любая строка, которая соответствует шаблону A, но не соответствует B.
A+
соответствует одному или нескольким экземплярам A. Конкатенация имеет более высокий приоритет, чем оператор альтернативы. Таким образом, A+ | B+ эквивалентно (A+) | (B+).
A*
соответствует нулю, одному или нескольким экземплярам A. Конкатенация имеет более высокий приоритет, чем оператор альтернативы. Таким образом, A* | B* эквивалентно (A*) | (B*).
Остальные нотации, используемые в сценариях:
/* ... */
комментарий.
[ wfc: ... ]
ограничение корректности. Идентифицирует по имени ограничение для корректных документов, связанное с неком сценарием.
[ vc: ... ]
ограничение действительности. Идентифицирует по имени ограничение для действительных документов, связанное с неким сценарием.
(Internet Assigned Numbers Authority) Официальные названия для наборов символов, редактор Keld Simonsen и другие. См. ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
IETF (Internet Engineering Task Force). RFC 1766: Тэги для идентификации языков, редактор H. Alvestrand. 1995. (см. http://www.ietf.org/rfc/rfc1766.txt.)
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 (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.
The Unicode Consortium. Стандарт Unicode, версия 2.0. Reading, Mass.: Addison-Wesley Developers Press, 1996.
The Unicode Consortium. Стандарт Unicode, версия 3.0. Reading, Mass.: Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5.
Aho, Alfred V., Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools. Reading: Addison-Wesley, 1986, откорректированный репринт 1988.
Berners-Lee, T., R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics. 1997. (В разработке, см. обновления к RFC1738.)
Brüggemann-Klein, Anne. Formal Models in Document Processing. Habilitationsschrift. Faculty of Mathematics at the University of Freiburg, 1993. (см. ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)
Brüggemann-Klein, 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.
James Clark. Сравнение SGML и XML. См. http://www.w3.org/tr/NOTE-sgml-xml-971215.
(Internet Assigned Numbers Authority) Registry of Language Tags, редактор Keld Simonsen и другие (см. http://www.isi.edu/in-notes/iana/assignments/languages/.)
IETF (Internet Engineering Task Force). RFC 2141: Синтаксис URN, редактор R. Moats. 1997. (см. http://www.ietf.org/rfc/rfc2141.txt.)
IETF (Internet Engineering Task Force). RFC 2279: UTF-8, a transformation format of ISO 10646, редактор F. Yergeau, 1998. (см. http://www.ietf.org/rfc/rfc2279.txt.)
IETF (Internet Engineering Task Force). RFC 2376: XML Media Types. редакция E. Whitehead, M. Murata. 1998. (см. http://www.ietf.org/rfc/rfc2376.txt.)
IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 1998. (см. http://www.ietf.org/rfc/rfc2396.txt.)
IETF (Internet Engineering Task Force). RFC 2732: Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. 1999. (см. http://www.ietf.org/rfc/rfc2732.txt.)
IETF (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.)
(International Organization for Standardization). ISO 639:1988 (E). Code for the representation of names of languages. [Geneva]: International Organization for Standardization, 1988.
(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 (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 (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.
ISO (International Organization for Standardization). ISO 8879:1986 TC2. Information technology -- Document Description and Processing Languages. [Geneva]: International Organization for Standardization, 1998. (см. http://www.sgmlsource.com)
Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (см. http://www.w3.org/tr/REC-xml-names/.)
Приводимые далее определения были представлены в стандарте Unicode. Все символы делятся на базовые символы (BaseChar, наряду с прочим сюда включены буквы латинского алфавита), идеографические символы (Ideographic), комбинированные символы (CombiningChar, в последнюю группу попадает также большинство диакритических символов). Выделяются также цифры (Digit) и расширения (Extender).
Символы
[84]
Letter
::=
BaseChar
| Ideographic
[85]
BaseChar
::=
[#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6]
| [#x00D8-#x00F6] | [#x00F8-#x00FF] | [#x0100-#x0131]
| [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E]
| [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5]
| [#x01FA-#x0217] | [#x0250-#x02A8] | [#x02BB-#x02C1]
| #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1]
| [#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC
| #x03DE | #x03E0 | [#x03E2-#x03F3] | [#x0401-#x040C]
| [#x040E-#x044F] | [#x0451-#x045C] | [#x045E-#x0481]
| [#x0490-#x04C4] | [#x04C7-#x04C8] | [#x04CB-#x04CC]
| [#x04D0-#x04EB] | [#x04EE-#x04F5] | [#x04F8-#x04F9]
| [#x0531-#x0556] | #x0559 | [#x0561-#x0586]
| [#x05D0-#x05EA] | [#x05F0-#x05F2] | [#x0621-#x063A]
| [#x0641-#x064A] | [#x0671-#x06B7] | [#x06BA-#x06BE]
| [#x06C0-#x06CE] | [#x06D0-#x06D3] | #x06D5
| [#x06E5-#x06E6] | [#x0905-#x0939] | #x093D
| [#x0958-#x0961] | [#x0985-#x098C] | [#x098F-#x0990]
| [#x0993-#x09A8] | [#x09AA-#x09B0] | #x09B2
| [#x09B6-#x09B9] | [#x09DC-#x09DD] | [#x09DF-#x09E1]
| [#x09F0-#x09F1] | [#x0A05-#x0A0A] | [#x0A0F-#x0A10]
| [#x0A13-#x0A28] | [#x0A2A-#x0A30] | [#x0A32-#x0A33]
| [#x0A35-#x0A36] | [#x0A38-#x0A39] | [#x0A59-#x0A5C]
| #x0A5E | [#x0A72-#x0A74] | [#x0A85-#x0A8B] | #x0A8D
| [#x0A8F-#x0A91] | [#x0A93-#x0AA8] | [#x0AAA-#x0AB0]
| [#x0AB2-#x0AB3] | [#x0AB5-#x0AB9] | #x0ABD | #x0AE0
| [#x0B05-#x0B0C] | [#x0B0F-#x0B10] | [#x0B13-#x0B28]
| [#x0B2A-#x0B30] | [#x0B32-#x0B33] | [#x0B36-#x0B39]
| #x0B3D | [#x0B5C-#x0B5D] | [#x0B5F-#x0B61]
| [#x0B85-#x0B8A] | [#x0B8E-#x0B90] | [#x0B92-#x0B95]
| [#x0B99-#x0B9A] | #x0B9C | [#x0B9E-#x0B9F]
| [#x0BA3-#x0BA4] | [#x0BA8-#x0BAA] | [#x0BAE-#x0BB5]
| [#x0BB7-#x0BB9] | [#x0C05-#x0C0C] | [#x0C0E-#x0C10]
| [#x0C12-#x0C28] | [#x0C2A-#x0C33] | [#x0C35-#x0C39]
| [#x0C60-#x0C61] | [#x0C85-#x0C8C] | [#x0C8E-#x0C90]
| [#x0C92-#x0CA8] | [#x0CAA-#x0CB3] | [#x0CB5-#x0CB9]
| #x0CDE | [#x0CE0-#x0CE1] | [#x0D05-#x0D0C]
| [#x0D0E-#x0D10] | [#x0D12-#x0D28] | [#x0D2A-#x0D39]
| [#x0D60-#x0D61] | [#x0E01-#x0E2E] | #x0E30
| [#x0E32-#x0E33] | [#x0E40-#x0E45] | [#x0E81-#x0E82]
| #x0E84 | [#x0E87-#x0E88] | #x0E8A | #x0E8D
| [#x0E94-#x0E97] | [#x0E99-#x0E9F] | [#x0EA1-#x0EA3]
| #x0EA5 | #x0EA7 | [#x0EAA-#x0EAB] | [#x0EAD-#x0EAE]
| #x0EB0 | [#x0EB2-#x0EB3] | #x0EBD | [#x0EC0-#x0EC4]
| [#x0F40-#x0F47] | [#x0F49-#x0F69] | [#x10A0-#x10C5]
| [#x10D0-#x10F6] | #x1100 | [#x1102-#x1103]
| [#x1105-#x1107] | #x1109 | [#x110B-#x110C]
| [#x110E-#x1112] | #x113C | #x113E | #x1140
| #x114C | #x114E | #x1150 | [#x1154-#x1155]
| #x1159 | [#x115F-#x1161] | #x1163 | #x1165
| #x1167 | #x1169 | [#x116D-#x116E] | [#x1172-#x1173]
| #x1175 | #x119E | #x11A8 | #x11AB
| [#x11AE-#x11AF] | [#x11B7-#x11B8] | #x11BA
| [#x11BC-#x11C2] | #x11EB | #x11F0 | #x11F9
| [#x1E00-#x1E9B] | [#x1EA0-#x1EF9] | [#x1F00-#x1F15]
| [#x1F18-#x1F1D] | [#x1F20-#x1F45] | [#x1F48-#x1F4D]
| [#x1F50-#x1F57] | #x1F59 | #x1F5B | #x1F5D
| [#x1F5F-#x1F7D] | [#x1F80-#x1FB4] | [#x1FB6-#x1FBC]
| #x1FBE | [#x1FC2-#x1FC4] | [#x1FC6-#x1FCC]
| [#x1FD0-#x1FD3] | [#x1FD6-#x1FDB] | [#x1FE0-#x1FEC]
| [#x1FF2-#x1FF4] | [#x1FF6-#x1FFC] | #x2126
| [#x212A-#x212B] | #x212E | [#x2180-#x2182]
| [#x3041-#x3094] | [#x30A1-#x30FA] | [#x3105-#x312C]
| [#xAC00-#xD7A3]
[86]
Ideographic
::=
[#x4E00-#x9FA5] | #x3007 | [#x3021-#x3029]
[87]
CombiningChar
::=
[#x0300-#x0345] | [#x0360-#x0361] | [#x0483-#x0486]
| [#x0591-#x05A1] | [#x05A3-#x05B9] | [#x05BB-#x05BD]
| #x05BF | [#x05C1-#x05C2] | #x05C4 | [#x064B-#x0652]
| #x0670 | [#x06D6-#x06DC] | [#x06DD-#x06DF]
| [#x06E0-#x06E4] | [#x06E7-#x06E8] | [#x06EA-#x06ED]
| [#x0901-#x0903] | #x093C | [#x093E-#x094C] | #x094D
| [#x0951-#x0954] | [#x0962-#x0963] | [#x0981-#x0983]
| #x09BC | #x09BE | #x09BF | [#x09C0-#x09C4]
| [#x09C7-#x09C8] | [#x09CB-#x09CD] | #x09D7
| [#x09E2-#x09E3] | #x0A02 | #x0A3C | #x0A3E
| #x0A3F | [#x0A40-#x0A42] | [#x0A47-#x0A48]
| [#x0A4B-#x0A4D] | [#x0A70-#x0A71] | [#x0A81-#x0A83]
| #x0ABC | [#x0ABE-#x0AC5] | [#x0AC7-#x0AC9]
| [#x0ACB-#x0ACD] | [#x0B01-#x0B03] | #x0B3C
| [#x0B3E-#x0B43] | [#x0B47-#x0B48] | [#x0B4B-#x0B4D]
| [#x0B56-#x0B57] | [#x0B82-#x0B83] | [#x0BBE-#x0BC2]
| [#x0BC6-#x0BC8] | [#x0BCA-#x0BCD] | #x0BD7
| [#x0C01-#x0C03] | [#x0C3E-#x0C44] | [#x0C46-#x0C48]
| [#x0C4A-#x0C4D] | [#x0C55-#x0C56] | [#x0C82-#x0C83]
| [#x0CBE-#x0CC4] | [#x0CC6-#x0CC8] | [#x0CCA-#x0CCD]
| [#x0CD5-#x0CD6] | [#x0D02-#x0D03] | [#x0D3E-#x0D43]
| [#x0D46-#x0D48] | [#x0D4A-#x0D4D] | #x0D57 | #x0E31
| [#x0E34-#x0E3A] | [#x0E47-#x0E4E] | #x0EB1
| [#x0EB4-#x0EB9] | [#x0EBB-#x0EBC] | [#x0EC8-#x0ECD]
| [#x0F18-#x0F19] | #x0F35 | #x0F37 | #x0F39
| #x0F3E | #x0F3F | [#x0F71-#x0F84] | [#x0F86-#x0F8B]
| [#x0F90-#x0F95] | #x0F97 | [#x0F99-#x0FAD]
| [#x0FB1-#x0FB7] | #x0FB9 | [#x20D0-#x20DC] | #x20E1
| [#x302A-#x302F] | #x3099 | #x309A
[88]
Digit
::=
[#x0030-#x0039] | [#x0660-#x0669] | [#x06F0-#x06F9]
| [#x0966-#x096F] | [#x09E6-#x09EF] | [#x0A66-#x0A6F]
| [#x0AE6-#x0AEF] | [#x0B66-#x0B6F] | [#x0BE7-#x0BEF]
| [#x0C66-#x0C6F] | [#x0CE6-#x0CEF] | [#x0D66-#x0D6F]
| [#x0E50-#x0E59] | [#x0ED0-#x0ED9] | [#x0F20-#x0F29]
[89]
Extender
::=
#x00B7 | #x02D0 | #x02D1 | #x0387 | #x0640
| #x0E46 | #x0EC6 | #x3005 | [#x3031-#x3035]
| [#x309D-#x309E] | [#x30FC-#x30FE]
Представленные здесь классы символов могут быть извлечены из базы данных символов Unicode 2.0 следующим образом:
C XML и SGML (Пояснения к спецификации)
XML построен как подмножество SGML, поэтому каждый XML документ должен также отвечать требованиям, предъявляемым к SGML документу. Детальное сравнение ограничений, которые языки XML и SGML накладывают на документы, см. в статье [Clark].
D Обработка ссылок на сущность и символ (Пояснения к спецификации)
В данном приложении содержатся некоторые примеры, иллюстрирующие последовательность распознавания и обработки ссылок на сущность и символ, которая была определена в главе 4.4 Обработка XML процессором сущностей и ссылок.
Если Dtd содержит декларацию
<!ENTITY example "<p>An ampersand (&#38;) may be escaped numerically (&#38;#38;) or with a general entity (&amp;).</p>" >
то в ходе обработки этой декларации сущности XML процессор обнаружит ссылки на символ и обработает их прежде чем следующая строка будет использована в качестве значения сущности "example":
<p>An ampersand (&) may be escaped numerically (&#38;) or with a general entity (&amp;).</p>
Появление в документе ссылки на элемент "&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>
В результате получается следующий сценарий:
xx" помещается в таблицу символов со значением "%zz;". И поскольку текст замены повторно не просматривается, ссылка на сущность параметра "zz" обнаружена не будет. (Если же это здесь произойдет, то будет зафиксирована ошибка, поскольку сущность "zz" еще не была декларирована.)
<" обрабатывается сразу, и сущность параметра "zz" обзаводится текстом замены "<!ENTITY tricky "error-prone" >", являющимся корректной декларацией сущности.
xx" и, соответственно, производится разбор текста замены для этой сущности (а именно, "%zz;"). При этом обнаруживается ссылка на сущность "zz" и тоже анализируется ее текст замены ("<!ENTITY tricky "error-prone" >"). В результате получаем декларацию общей сущности "tricky" с текстом замены "error-prone".
tricky". В итоге получаем полное содержимое элемента test в виде самодостаточной (и не связанной с какой-либо грамматикой) строки This sample shows a error-prone method.E Детерминистические модели содержания (Пояснения к спецификации)
Как указывалось в главе 3.2. Содержимое элемента, необходимо чтобы модели содержимого, даваемые в декларациях типов элементов, были детерминистическими. Данное требование необходимо для совместимости с языком 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 [Aho/Ullman]. Во многих таких алгоритмах для каждой части в регулярном выражении строится сопроводительный набор команд (то есть, в дереве синтаксиса данного регулярного выражения стоится каждый узел листа). Если какая-либо часть выражения имеет сопроводительный набор, в котором более одной позиции сопоставлено с типом элементов с одним и тем же названием, модель содержимого ошибочна и об этом можно сообщать как об ошибке.
Существуют алгоритмы, которые способны многие (хотя и не все) недетерминистические модели содержания автоматически привести к эквивалентным детерминистическым моделям (см. Brüggemann-Klein 1991 [Brüggemann-Klein]).
F Автоматическое определение кодировки символов (Пояснения к спецификации)
Декларация кодировки XML для каждой сущности действует как некий внутренний заголовок, указывающий используемую кодировку символов. Очевидно, что прежде чем XML процессор сможет прочесть внутренний заголовок, он должен выяснить используемую кодировку символов, то есть именно то, что пытается показать внутренний заголовок. В общем случае, это безвыходная ситуация. Однако для XML это не совсем так, поскольку XML в общем случае ограничен двумя положениями: предполагается, что каждая реализация поддерживает только ограниченный набор кодировок символов, а декларация кодировки XML занимает определенную позицию и имеет определенное содержание, что позволяет в обычных случаях осуществить автоматическое определение кодировки для каждой сущности. Кроме того, во многих случаях помимо собственно потока данных XML документа доступны и другие источники информации. В зависимости от того, была ли сущность XML представлена процессору с сопроводительной (внешней) информацией или же нет, можно наблюдать две ситуации. Сначала мы рассмотрим первую из них.
F.1 Определение без внешней информации о кодировке
Поскольку ни одна из сущностей XML не сопровождается внешней информацией о кодировке и не пользуется кодировками UTF-8 или UTF-16, то первой должна идти декларация кодировки XML. Первыми ее символами должны быть '<?xml', которые способен обнаружить любой процессор, отвечающий требованиям спецификации. Для этого ему необходимо получит от двух до четырех октетов, различные комбинации которых рассматриваются ниже. Изучая перечень этих комбинаций, полезно будет знать, что в кодировке 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:
00 00 00 3C
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 не сможет работать, если какая-нибудь программа поменяла используемый для сущности набор символов или кодировку, не изменив при этом соответствующим образом декларацию кодировки. Программистам, разрабатывающим процедуры кодирования символов, необходимо тщательно проверять достоверность внешней и внутренней информации, используемой для маркировки сущностей.
F.2 Приоритеты при наличии внешней информации о кодировке
Вторая из возможных ситуаций возникает когда XML сущность сопровождает информация о кодировке, извлекаемая из некоторых файловых систем и сетевых протоколов. Если имеется несколько источников информации, то их относительный приоритет и предпочтительный способ разрешения конфликтов должны определяться протоколом более высокого уровня, используемым для передачи XML документов. В частности, можно обратиться к [IETF RFC 2376] и наследующим его документам, определяющим типы MIME text/xml и application/xml, а также содержащим полезное руководство. Однако в целях совместимости желательно руководствоваться следующим правилом:
G Рабочая группа W3C XML (Пояснения к спецификации)
Данная спецификация была подготовлена и принята к публикации рабочей группой W3C XML (W3C XML Working Group, WG). Однако из того, что WG приняла данную спецификацию, не следует, что все члены WG единогласно проголосовали за это решение. Настоящие и бывшие члены XML WG:
H Основная группа W3C XML (Пояснения к спецификации)
Вторая редакция данной спецификации была подготовлена основной рабочей группой W3C XML (W3C XML Core Working Group, WG). Членами группы на момент опубликования этой редакции являлись:
I Рабочие заметки (Пояснения к спецификации)
Вторая редакция спецификации была также преобразована в XMLspec Dtd (для которой имеется соответствующая документация). HTML версии спецификации были получены с помощью XSLT стилей xmlspec.xsl, diffspec.xsl и REC-xml-2e.xsl. PDF версия документа была получена с помощью инструментария html2ps и программы выделения.
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 - пробельный символ
Внимание !