Extensible Markup Language 1.0-2000-2

[Определение: Декларация разметки - это декларация типа документа, декларация списка атрибутов, декларация сущности или декларация нотации.] Перечисленные декларации могут целиком, либо частично располагаться в сущности параметра в соответствии с приводимыми далее ограничениями корректности и действительности. Дальнейшие подробности см. в главе 4 Физические структуры.

Декларация типа документа

[28] doctypedecl ::= '<!DOCTYPE' S Name (S ExternalID)? S? ('[' (markupdecl | DeclSep)* ']' S?)? '>' [VC: Тип корневого элемента]
[WFC: Внешний набор]
/* */
[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).

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

2.11 Обработка концов строк

Часто разобранные сущности XML, помещенные в компьютерные файлы, для удобства редактирования представляются в виде набора строк. В качестве разделителя для таких строк обычно используется некая комбинация символов возврата каретки (#xD) и конца строки (#xA).

Чтобы облегчить работу приложений, текст, который им передает XML процессор, должен быть таким, как если бы этот процессор при выводе перед обработкой нормализовал все концы строк во внешних разобранных сущностях (а также сущности самого документа). Осуществляться это должно путем замены последовательности из двух символов #xD #xA (а также одиночного #xD, за которым не следует #xA) одним символом #xA.

2.12 Идентификация языка

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

3 Логические структуры

[Определение: Каждый XML документ содержит один или несколько элементов, границы каждого из которых обозначены либо парой начальный тэг - конечный тэг, либо (если это пустой элемент) тэгом пустого элемента. Каждый элемент имеет определенный тип, который идентифицируется по имени и иногда называется "общим идентификатором" этого элемента (generic identifier - GI), а также может иметь набор спецификаций к атрибутам.] Каждая спецификация атрибута содержит его имя и значение.

Элемент

[39] element ::= EmptyElemTag
| STag content ETag [WFC: Соответствие типов элементов]
[VC: Действительность элемента]

Данная спецификация не ограничивает семантику, порядок использования (за исключением синтаксиса), выбор имен для атрибутов и типов элементов. Ограничение заключается в том, что имена, чье начало соответствует шаблону (('X'|'x')('M'|'m')('L'|'l')), зарезервированы для стандартизации в текущей и последующих версиях данной спецификации.

Ограничение корректности: Соответствие типов элементов

Параметр Name в конечном тэге элемента должен соответствовать типу элемента в начальном тэге.

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

Элемент считается действительным, если имеется декларация, соответствующая elementdecl, в которой параметр Name соответствует типу элемента, а также выполняется одно из следующих условий:

  1. Декларация соответствует EMPTY, а элемент не имеет содержимого.

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

  3. Декларация соответствует Mixed, а содержимое состоит из символьных данных и элементов-потомков, тип которых соответствует именам в модели содержимого.

  4. Декларация соответствует ANY, и был декларирован тип всех элементов-потомков.

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/>

3.2 Декларации типа элемента

Для достижения действительности, на структуру элементов в 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>

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 Детерминистические модели содержания.

Ограничение действительности: Правильная вложенность 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 Смешанный контент

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

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

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

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

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

<< Предыдущая глава | Следующая глава >>

РОЛ.RU