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

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

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

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

3.2.2 Смешанный контент

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

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

[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.1 Типы атрибутов

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

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

[54]    AttType    ::=    StringType | TokenizedType | EnumeratedType [55]    StringType    ::=    'CDATA'[56]    TokenizedType    ::=    'ID'[VC: ID][VC: Один ID для каждого типа элементов][VC: Значение по умолчанию для атрибута ID]| 'IDREF'[VC: IDREF]| 'IDREFS'[VC: IDREF]| 'ENTITY'[VC: Имя сущности]| 'ENTITIES'[VC: Имя сущности]| 'NMTOKEN'[VC: Лексема имени]| 'NMTOKENS'[VC: Лексема имени]

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

Типы перечислимых атрибутов

[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) идентификаторами, и которую следует использовать для интерпретации элемента, в котором был указан данный атрибут.

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

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

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

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

[60]    DefaultDecl    ::=    '#REQUIRED' | '#IMPLIED' | (('#FIXED' S)? AttValue)[VC: Обязательный атрибут][VC: Допустимость значения по умолчанию для атрибута][WFC: Отсутствие символов < в значениях атрибута][VC: Фиксированное значение атрибута по умолчанию]

Запись #REQUIRED в декларации атрибута означает, что этот атрибут должен присутствовать в элементе всегда, #IMPLIED означает, что значения по умолчанию для атрибута не предоставляется. [Определение: Если в декларации нет ни #REQUIRED, ни #IMPLIED, то значение AttValue содержит значение, декларированное по умолчанию. Ключевое слово #FIXED устанавливает, что данный атрибут обязан всегда иметь значение по умолчанию. Если было декларировано значение по умолчанию, то когда XML процессор не обнаруживает этого атрибута, он должен поступать так, словно атрибут присутствует и имеет значение, декларированное по умолчанию.]

Примеры деклараций списка атрибутов:

<!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.