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

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

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

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

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

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

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

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

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

[Определение: Литерал 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.1 Декларация текста

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

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

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

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

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

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

Внутренняя общая разобранная сущность является корректной если ее текст замены соответствует сценарию 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 Декларация текста), содержащей декларацию кодировки:

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

В сущности 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.1 Не распознается

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

4.4.2 Включается

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

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

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

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

4.4.4 Запрещен

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

• появление ссылки на неразобранную сущность.

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

• ссылка на внешнюю сущность в значении атрибута.

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

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

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

а этот - нет:

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

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

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

4.4.7 Пропускается

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

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

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