3 Логические структуры
[Определение: Каждый XML документ содержит один или несколько элементов, границы каждого из которых обозначены либо парой начальный тэг - конечный тэг, либо (если это пустой элемент) тэгом пустого элемента. Каждый элемент имеет определенный тип, который идентифицируется по имени и иногда называется "общим идентификатором" этого элемента (generic identifier - GI), а также может иметь набор спецификаций к атрибутам.] Каждая спецификация атрибута содержит его имя и значение.
Элемент
Данная спецификация не ограничивает семантику, порядок использования (за исключением синтаксиса), выбор имен для атрибутов и типов элементов. Ограничение заключается в том, что имена, чье начало соответствует шаблону (('X'|'x')('M'|'m')('L'|'l')) , зарезервированы для стандартизации в текущей и последующих версиях данной спецификации.
Ограничение корректности: Соответствие типов элементов
Параметр Name в конечном тэге элемента должен соответствовать типу элемента в начальном тэге.
Ограничение действительности: Действительность элемента
Элемент считается действительным, если имеется декларация, соответствующая elementdecl, в которой параметр Name соответствует типу элемента, а также выполняется одно из следующих условий:
Декларация соответствует EMPTY, а элемент не имеет содержимого.
Декларация соответствует непосредственному потомку элемента, а последовательность его непосредственных элементов - потомков, принадлежит языку, генерируемому регулярным выражением в модели содержимого с необязательным пробельным символом (символами, соответствующими неграничному S) между начальным тэгом и первым из непосредственных элементов-потомков, между элементами-потомками, между последним элементом-потомком и закрывающим тэгом. Заметим, что в секция CDATA, содержащая лишь пробельный символ, не соответствуют нетерминальному S, а следовательно в указанных позициях появиться не может.
Декларация соответствует Mixed, а содержимое состоит из символьных данных и элементов-потомков, тип которых соответствует именам в модели содержимого.
Декларация соответствует ANY, и был декларирован тип всех элементов-потомков.
3.1 Начальные тэги, конечные тэги и тэги пустых элементов
[Определение: Начало любого непустого XML элемента помечается начальным тэгом.]
Начальный тэг
Параметр Name в начальном и конечном тэгах определяет тип элемента. [Определение: Пара Name - AttValue называется спецификацией атрибута для данного элемента], [Определение: Параметр Name в каждой такой паре называется именем атрибута], а [Определение: содержимое поля AttValue - текст в одинарных (' ) или двойных (" ) кавычках - называется значением атрибута.] Заметим, что очередность появления спецификаций атрибутов в начальном тэге или тэге пустого элемента значения не имеет.
Ограничение корректности: Уникальность спецификации атрибута
В границах одного начального тэга (или тэга пустого элемента) одно и то же имя атрибута не может появляться более одного раза.
Ограничение действительности: Тип значения атрибута
Атрибут должен быть декларирован, его значение должно иметь тот тип, который был декларирован для него. (Описание типов атрибутов см. в главе 3.3 Декларации списков атрибутов.)
Ограничение корректности: Отсутствие ссылок на внешние сущности
Значение атрибута не может иметь содержать прямых или косвенных ссылок на внешние сущности.
Ограничение корректности: Отсутствие символов < в значениях атрибута
Символ < не может содержаться в тексте замены для сущностей, на которые в значении атрибута прямо или косвенно дается ссылка.
Пример начального тэга:
<termdef id="dt-dog" term="dog"> |
[Определение: Любой элемент, чье начало отмечено начальным тэгом, должен завершиться конечным тэгом, имя которого повторяет тип элемента, указанный в начальном тэге:]
Конечный тэг
[42] |
ETag |
::= |
'</' Name S? '>' |
Пример конечного тэга:
[Определение: Текст, заключенный между начальным и конечным тэгами, называется содержимым элемента:]
Содержимое элементов
[Определение: Элемент без содержимого называется пустым элементом.] Пустой элемент может быть представлен либо в виде начального тэга, за которым сразу же следует конечный тэг, либо как тэг пустого элемента. [Определение: Тэг пустого элемента имеет специальный формат:]
Тэги пустых элементов
Тэг пустого элемента может быть использован для любого элемента, не имеющего содержимого, независимо от того, был ли последний декларирован с ключевым словом EMPTY. В целях совместимости, тэг пустого элемента должен использоваться для элементов, которые были декларированы как EMPTY, и только для них.
Примеры пустых элементов:
<IMG align="left"
src="http://www.w3.org/Icons/WWW/w3c_home" />
<br></br>
<br/> |
3.2 Декларации типа элемента
Для достижения действительности, на структуру элементов в XML документе могут быть наложены ограничения в виде деклараций типов используемых элементов и списков атрибутов. Декларирование типа элемента накладывает ограничение на его содержание.
Декларация типа элемента часто конкретизирует тип его непосредственных потомков. По выбору пользователя, XML процессор может генерировать предупреждение если в декларации был упомянут тип элемента, для которого не было предоставлено соответствующей декларации, однако ошибочной эта ситуация не считается.
[Определение: Декларация типа элемента имеет вид:]
Декларация типа элемента
где параметр Name определяет декларируемый тип элемента.
Ограничение действительности: Уникальность декларации типа элемента
Ни один тип элемента не может быть декларирован более одного раза.
Примеры деклараций типа элемента:
<!ELEMENT br EMPTY>
<!ELEMENT p (#PCDATA|emph)* >
<!ELEMENT %name.para; %content.para; >
<!ELEMENT container ANY> |
3.2.1 Содержимое элемента
[Определение: Тип элемента определяет содержимое элемента, если элементы указанного типа обязаны не иметь символьных данных, а только непосредственные элементы-потомки, которые могут отделяться друг от друга пробельными символами (символами, соответствующими неграничному S).] [Определение: В этом случае накладываемое на элемент ограничение содержит модель содержимого - простую грамматику, управляющую допустимыми типами непосредственных элементов-потомков и порядком, в котором им разрешено появляться.] Указанная грамматика строится из фрагментов содержания (cp), которые содержат название, списки выбора и последовательные списки фрагментов содержания:
Модели содержимого элемента
где каждая запись 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;)*> |
3.2.2 Смешанный контент
[Определение: Какой-либо тип элемента имеет смешанный контент, если элементы этого типа могут содержать символьные данные, возможно чередуемые с элементами-потомками.] В таком случае ограничения модели могут касаться лишь типа непосредственных элементов-потомков, но не порядка их следования и количества экземпляров:
Декларация смешанного контента
где параметр 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 Начальные тэги, конечные тэги и тэги пустых элементов. Декларация списка атрибутов может быть использована для:
формирования перечня атрибутов, относящихся к определенному типу элементов.
ограничения по типу атрибутов.
формирования значений по умолчанию для атрибутов.
[Определение: для каждого атрибута, относящегося к элементам определенного типа, в соответствующей декларации списка атрибутов определяются имя, тип данных и, возможно, значение по умолчанию:]
Декларация списка атрибутов
В поле Name в правиле AttlistDecl указывается тип элемента. По выбору пользователя, XML процессор может генерировать предупреждение, если атрибуты, декларированные для такого типа элементов, сами декларированы не были, однако ошибкой такая ситуация не считается. Параметр Name в правиле AttDef соответствует имени описываемого атрибута.
Если для какого-либо из типов элементов было дано несколько деклараций AttlistDecl, то содержимое всех их суммируется. Если для некого типа элементов было дано несколько деклараций одного и того же атрибута, то использоваться должна только первая декларация, а все последующие будут игнорироваться. Для сохранения совместимости, авторы DTD могут придерживаться правила давать для любого типа элементов не более одной декларации списка атрибутов, не более одной декларации для каждого имени атрибута, представленного в декларации списка атрибутов и, по крайней мере, одну декларацию атрибута в каждой из деклараций списка атрибутов. В целях совместимости, XML процессор по выбору пользователя может генерировать предупреждение, если для какого-либо типа элементов было представлено более одной декларации списка атрибутов, или для какого-либо атрибута было представлено более одной декларации, однако описанные ситуации ошибочными не являются.
3.3.1 Типы атрибутов
Все типы XML атрибутов делятся на три класса: строковый тип, набор символьных (tokenized) типов и перечислимые (enumerated) типы. Строковый тип может иметь в качестве значения одну строку. Символьные типы содержат различные лексические и семантические ограничения. Ограничения действительности, обсуждаемые в данной грамматике, начинают действовать после того, как значение атрибута было нормализовано в соответствии с описанием в главе 3.3 Декларации списков атрибутов.
Типы атрибутов
Ограничение действительности: ID
Значения типа ID должны соответствовать сценарию для Name. Имя, соответствующее значению этого типа, должно появляться в XML документе не более одного раза. Иными словами, значения ID должны уникальным образом идентифицировать элементы, в которых они находятся.
Ограничение действительности: Один ID для каждого типа элементов
Любой тип элемента не может иметь более одного атрибута ID.
Ограничение действительности: Значение по умолчанию для атрибута ID
Для атрибута ID должно быть декларировано значение по умолчанию #IMPLIED или #REQUIRED.
Ограничение действительности: IDREF
Значения типа IDREF должны соответствовать сценарию Name, а значения типа IDREFS должны соответствовать Names. При этом каждое Name должно соответствовать значению атрибута ID в каком-либо элементе XML документа, то есть, значение IDREF должно соответствовать значению какого-либо из атрибутов ID.
Ограничение действительности: Имя сущности
Значения типа ENTITY должны соответствовать сценарию Name, значения типа ENTITIES должны соответствовать Names. Каждое Name при этом должно соответствовать названию одной из неразобранных сущностей, декларированных в DTD.
Ограничение действительности: Лексема имени
Значения типа NMTOKEN должны соответствовать сценарию Nmtoken, значения типа NMTOKENS должны соответствовать Nmtokens.
[Определение: Перечислимый атрибут может выбирать одно значение из перечня, предоставленного в декларации]. Существует два вида перечислимых типов:
Типы перечислимых атрибутов
Атрибут NOTATION идентифицирует нотацию, которая была декларирована в DTD вместе с ассоциированными с нею системными и/или общими (public) идентификаторами, и которую следует использовать для интерпретации элемента, в котором был указан данный атрибут.
Ограничение действительности: Атрибуты нотации
Значения указанного типа должны соответствовать одному из представленных в декларации названий нотации. Все названия нотаций в декларации в свою очередь также должны быть декларированы.
Ограничение действительности: Одна нотация для каждого типа элемента
Для типа элемента не может указываться более одного атрибута NOTATION.
Ограничение действительности: Отсутствие нотаций для пустого элемента
Для сохранения совместимости, для элемента, объявленного как EMPTY, атрибут типа NOTATION декларироваться не должен.
Ограничение действительности: Перечисление
Значения этого типа должны соответствовать одной из лексем Nmtoken, указанных в декларации.
Чтобы обеспечить взаимодействие, один и тот же Nmtoken должен появляться среди перечислимых типов атрибутов, относящихся к одному типу элементов, не более одного раза.
3.3.2 Значения атрибутов по умолчанию
Декларация атрибута предоставляет сведения о том, обязательно ли присутствие в элементе данного атрибута и, если нет, то как XML процессор должен реагировать на отсутствие в документе декларированного атрибута.
Значение атрибута по умолчанию
Запись #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 процессор должен выполнить нормализацию полученного значения атрибута по описанному далее алгоритму либо как-нибудь иначе, например передав это значение отдельному приложению, реализующему указанный алгоритм.
Все концы строк при выводе должны быть приведены к #xA, как было описано в главе 2.11 Обработка концов строк, поэтому остальная часть данного алгоритма оперирует текстом, уже нормализованным подобным образом.
Начинается с нормализованного значения, состоящего из пустой строки.
Для каждого символа, ссылки на сущность и ссылки на символ в ненормализованном значении атрибута, с первого до последнего, должны выполняться следующие действия:
Для ссылки на символ к нормализованное значение поместить символ, на который делалась ссылка.
Для ссылки на сущность над текстом замены для указанной сущности рекурсивно выполнять третий шаг обсуждаемого алгоритма.
В случае пробельного символа (#x20, #xD, #xA, #x9) в нормализованное значение помещать символ пробела (#x20).
Остальные символы просто помещать в нормализованное значение.
Если тип атрибута - не 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 |
|
x y z |
#x20 #x20 x y z |
|
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 в зависимости от значения управляющего ею ключевого слова.]
Условная секция
Ограничение действительности: Правильная вложенность условной секции/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?)>
]]> |
Назад |
Содержание |
Вперед
|
|