Extensible Markup Language 1.0-2000-3

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

Значения типа 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: Допустимость значения по умолчанию для атрибута] [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 процессор должен выполнить нормализацию полученного значения атрибута по описанному далее алгоритму либо как-нибудь иначе, например передав это значение отдельному приложению, реализующему указанный алгоритм.

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

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

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

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

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

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

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

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

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

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

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

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

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

Спецификация атрибута	a является NMTOKENS	a является CDATA
a="xyz"	x y z	#x20 #x20 x y z
a="&d;&d;A&a;&a;B&da;"	A #x20 B	#x20 #x20 A #x20 #x20 B #x20 #x20
a="

A

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

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

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

[Определение: Условная секция является фрагментом внешнего набора для декларации типа документа, которая включается или исключается из логической структуры 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?)> ]]>

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

[Определение: 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: Декларированная сущность] [WFC: Разобранная сущность] [WFC: Отсутствие рекурсии] [69] PEReference ::= '%' Name ';' [VC: Декларированная сущность] [WFC: Отсутствие рекурсии] [WFC: В DTD]

Ограничение корректности: Декларированная сущность

Для документа без какого-либо 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> (&#x3C;) to save options. This document was prepared on &docdate; and is classified &security-level;.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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]. Запрещенные символы необходимо маскировать следующим образом:

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

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

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

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

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

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

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

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

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

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

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