Расширяемый язык разметки

         

Нотация


Формальная грамматика языка XML строится в данной спецификации с помощью простой нотации Extended Backus-Naur Form (EBNF). Каждое правило в грамматике определяет один символ (symbol) в следующем формате:

symbol ::= expression

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

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

#xN

где N - шестнадцатеричное целое число. Данное выражение соответствует символу в кодировке ISO/IEC 10646, каноническое значение кода (UCS-4) которого как беззнаковое целое число, имеет указанное значение. Количество ведущих нулей в формате #xN значения не имеет. Количество ведущих нулей в соответствующем значении кода определяется используемой кодировкой символов и для XML значения не имеет.

[a-zA-Z], [#xN-#xN]

соответствует любому , чье значение попадает в указанный диапазон(ы) (включительно).

[abc], [#xN#xN#xN]

соответствует любому , чье значение имеется среди перечисленных символов. В пределах одного набора скобок перечисления и диапазоны могут сочетаться.

[^a-z], [^#xN-#xN]

соответствует любому , чье значение не входит в указанный диапазон.

[^abc], [^#xN#xN#xN]

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

"string"

соответствует строке символов, со строкой, представленной в двойных кавычках.

'string'

соответствует строке символов, со строкой, представленной в одинарных кавычках.

Представленные символы могут комбинироваться в более сложные шаблоны следующим образом (где A и B представляют собой простые выражения):

(выражение)

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



A?

соответствует A или ничему. Необязательная единица A.



соответствует A, за которым следует


A B

соответствует A, за которым следует B. Данный оператор имеет более высокий приоритет, чем оператор альтернативы. Таким образом, A B | C D эквивалентно (A B) | (C D).

A | B

соответствует A или B, но не обоим сразу.

A - B

любая строка, которая соответствует шаблону A, но не соответствует B.

A+

соответствует одному или нескольким экземплярам A. Конкатенация имеет более высокий приоритет, чем оператор альтернативы. Таким образом, A+ | B+ эквивалентно (A+) | (B+).

A*

соответствует нулю, одному или нескольким экземплярам A. Конкатенация имеет более высокий приоритет, чем оператор альтернативы. Таким образом, A* | B* эквивалентно (A*) | (B*).

Остальные нотации, используемые в сценариях:

/* ... */

комментарий.

[ wfc: ... ]

ограничение корректности. Идентифицирует по имени ограничение для документов, связанное с неком сценарием.

[ vc: ... ]

ограничение действительности. Идентифицирует по имени ограничение для документов, связанное с неким сценарием.


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


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

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



Обработка пробельных символов


В ходе редактирования XML документов часто бывает удобно воспользоваться "пробельными символами" (white space - пробелы, табуляторы и пустые строки) для выделения разметки для лучшей читаемости. Такие пробельные символы обычно не должны попадать в ту версию документа, которая передается в приложение. С другой стороны, часто встречаются "значимые" пробельные символы, которые должны быть оставлены в передаваемом документе, например если это стихи или исходный код программы.

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

К элементу может быть приставлен специальный , называемый xml:space, для того чтобы показать, что пробельные символы в этом элементе должны быть сохранены. Если этот атрибут используется в действительных документах, то, как и любой другой, он должен быть . Будучи декларирован, он должен быть представлен как , значениями которого являются одно или оба значения "default" и "preserve". Например:

<!ATTLIST poem xml:space (default|preserve) 'preserve'> <!-- --> <!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

Значение атрибута "default" говорит о том, что для данного элемента используется режим обработки пробельных символов, применяемый в приложениях по умолчанию. Значение "preserve" говорит о том, что приложения должны сохранить все пробельные символы. Декларированное таким образом правило относится ко всем элементам, находящимся среди содержимого того элемента, которому был назначен данный атрибут (при условии что это правило не было затем переопределено другим экземпляром атрибута xml:space).

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



Обработка XML процессором сущностей и ссылок


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

Ссылка в содержимом

Ссылка в любом месте элемента в интервале между и тэгами. Соответствует незавершенному (nonterminal) .

Ссылка в значении атрибута

Ссылка либо в значении атрибута , либо в значении по умолчанию из . Соответствует незавершенному .

Значение атрибута

Это не ссылка, а лексема типа . Выступает либо как значение атрибута, декларированного с типом ENTITY, либо как одна из лексем, перечисленных через пробел в значении атрибута, декларированного с типом ENTITIES.

Ссылка в значении сущности

Ссылка из параметра или внутренней сущности, находящихся в декларации сущности. Соответствует незавершенной .

Ссылка в DTD

Ссылка во внутреннем или внешнем наборе , не попавшая в конструкции , , , , , , а также содержимое игнорируемой условной секции (см. главу ).

Тип сущности Символ
Параметр Внутренняя общая Внешняя разобранная общая Неразобранная
Ссылка в содержимом Запрещен Включается
Ссылка в значении атрибута
Значение атрибута
Ссылка в значении сущности
Ссылка в DTD Запрещен



Общие синтаксические конструкции


В данной главе определяются некоторые символы, широко используемые в грамматике XML.

(пробельный символ, white space) состоит из одного или нескольких символов пробела (#x20), возврата каретки, конца строки или табулятора.



Построение текста замены для внутренней сущности


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

Строковое значение сущности, данное в декларации внутренней сущности (), может содержать ссылки на символ, на сущность параметра и на общую сущность. Такие ссылки должны целиком содержаться в строковом значении сущности. Реально текст замены должен содержать текст замены для всех сущностей параметров и все символы, на которые делалась ссылка, причем в тех местах строкового значения сущности, где эти ссылки находились. Вместе с тем, ссылки на общие сущности должны оставаться без изменений. Например, даны следующие декларации:

<!ENTITY % pub "&#xc9;ditions Gallimard" >

<!ENTITY rights "All rights reserved" >

<!ENTITY book "La Peste: Albert Camus, &#xA9; 1947 %pub;. &rights;" >

тогда текст замены для сущности "book":

La Peste: Albert Camus, © 1947 Éditions Gallimard. &rights;

Ссылка на общую сущность "&rights;" должна расшифроваться только тогда, когда ссылка "&book;" попадает в содержимое документа или значение атрибута.

Эти простые правила могут иметь сложные взаимоотношения. Детальное обсуждение сложного примера этого см. в Приложении .



Предопределенные сущности


[Определение: Ссылки на сущность и символ могут быть использованы для маскирования левой угловой скобки, амперсанта и других ограничителей. Для этой цели сформирован целый набор общих сущностей (amp, lt, gt, apos, quot). Также может использоваться числовая ссылка на символ, которая должна обрабатываться как символьные данные и заменяться соответствующим символом сразу по обнаружении. Таким образом, числовые ссылки "&#60;" и "&#38;" могут быть использованы для маскирования символов < и &, встречающихся среди символьных данных.]

Независимо от того, были ли указанные сущности декларированы, они должны распознаваться всеми XML процессорами. Чтобы обеспечить , действительные XML документы перед использованием должны декларировать эти сущности, как и любые другие. Если сущности lt или amp были декларированы, то они должны быть объявлены как внутренняя сущность, чей текст замены - это ссылка на соответствующий маскируемый символ (знак меньше или амперсант). Для этих сущностей необходимо двойное маскирование, чтобы ссылка на них давала корректный результат. Если декларируются сущности gt, apos или quot, то они должны быть представлены как внутренняя сущность, текст замены которой - это одиночный маскируемый символ (либо ссылка на этот символ, двойное маскирование здесь хотя и допустимо, но необязательно). Например:

<!ENTITY lt "&#38;#60;"> <!ENTITY gt "&#62;"> <!ENTITY amp "&#38;#38;"> <!ENTITY apos "&#39;"> <!ENTITY quot "&#34;">



Приложения


A

    A.1

    A.2

B

C (Пояснения к спецификации)

D (Пояснения к спецификации)

E (Пояснения к спецификации)

F (Пояснения к спецификации)

    F.1

    F.2

G Рабочая группа W3C XML (Пояснения к спецификации)

H (Пояснения к спецификации)

I (Пояснения к спецификации)

J (Пояснения к спецификации)



Пробельный символ


[3] S    ::=    (#x20 | #x9 | #xD | #xA)+

Для удобства символы делятся на буквы, цифры и остальные символы. Буквы состоят из алфавитных, слоговых и идеографических символов. Полное определение конкретных символов из каждого класса дается в Приложении .

[Определение: Имя (name) - это лексема (token), начинающаяся с буквы, либо одного из нескольких символов пунктуации, за которыми следуют буквы, цифры, дефисы, символы подчеркивания, двоеточия или точки (все они называются name character - символами имени).] Имена, начинающиеся с комбинации "xml" или какой-либо из строк, соответствующих шаблону (('X'|'x') ('M'|'m') ('L'|'l')), зарезервированы под стандартизацию в этой спецификации и ее последующих версиях.

Замечание:

Интерпретация имен, содержащих символ двоеточия, задается в документе Namespaces in XML Recommendation . Поэтому авторам не следует использовать символ двоеточия в именах XML, если это не связано с обращением к пространству имен. Вместе с тем, сами XML процессоры должны воспринимать двоеточие в имени как обычный символ.

(лексема имени) - это произвольное сочетание символов имени.



Пролог


[22] prolog    ::=    ? * ( *)?
[23]    XMLDecl    ::=    '<?xml' ? ? ? '?>'
[24]    VersionInfo    ::=    'version' ("'" "'" | '"' '"')/* */
[25]    Eq    ::=    ? '=' ?
[26]    VersionNum    ::=    ([a-zA-Z0-9_.:] | '-')+
[27]    Misc    ::=    | |

[Определение: В языке XML декларация типа документа либо сама содержит, либо ссылается на , которые определяют грамматику некого класса документов. Такую грамматику называют декларацией типа документа, или DTD (document type definition). Декларация типа документа может ссылаться на внешний набор, который также содержит декларацию разметки (специальный тип - ), может содержать свой внутренний набор деклараций разметки, а может сочетать оба варианта. DTD документа формируется из обоих этих наборов, обрабатываемых совместно.]

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



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


[Определение: Документ XML должен начинаться с декларации XML, указывающей версию используемого языка XML.] Например, в следующем примере представлен полноценный XML документ, , но :

<?xml version="1.0"?> <greeting>Hello, world!</greeting>

таким образом, имеем:

<greeting>Hello, world!</greeting>

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

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

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



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


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



Проверяющие и непроверяющие процессоры


, отвечающие требованиям спецификации, делятся на два класса: проверяющие и непроверяющие.

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

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

Для проверки корректности от непроверяющего процессора требется проанализировать лишь , включая полный внутренний набор DTD. [Определение: Хотя непроверяющий процессор и не обязан проверять действительность документа, он должен обработать все декларации, найденные во внутреннем наборе DTD, а также во всех прочитанных им сущностях параметров, но только до первой ссылки на сущность параметра, которую он уже не должен читать. Иными словами, он должен использовать сведения из этих деклараций для значений атрибутов, текста замены для внутренних сущностей и предоставления .] За исключением случая standalone="yes", процессорам запрещается и , расположенные после ссылки на сущность параметра, последняя не читается, поскольку может содержать переопределяющие декларации.



Рекомендация W3C от 6 октября 2000 года


Данный документ представляет собой перевод спецификации Extensible Markup Language (XML) 1.0 (Second Edition) (W3C Recommendation) на русский язык. При этом нормативным документом считается оригинальная спецификация на английском языке, которую можно найти по адресу

.

Перевод спецификации на русский язык представлен на страницах портала "Россия-Он-Лайн":

Перевод выполнен , ()

Представленный документ может содержать ошибки перевода.

Данная версия: (, , , с цветовым выделением исправлений) Последняя версия: Предыдущие версии: Редакторы: Tim Bray, Textuality и Netscape Jean Paoli, Microsoft C. M. Sperberg-McQueen, Университет Иллинойс в Чикаго и Text Encoding Initiative Eve Maler, Sun Microsystems, Inc. - Вторая редакция

© 2000 ® (, , ), Все права защищены. В отношении данного документа действуют правила W3C, касающиеся , , и .



The Extensible Markup Language, XML)


Расширяемый язык разметки ( The Extensible Markup Language, XML) - подмножество SGML, целиком описанное в представленном документе. Язык должен дать возможность передавать, получать и обрабатывать в Web общие документы SGML так же, как сейчас это можно делать с документами HTML. Язык XML спроектирован так, чтобы упростить реализацию и обеспечить взаимодействие SGML и HTML.

Секции CDATA


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


[18] CDSect    ::=   
[19]    CDStart    ::=    '<![CDATA['
[20]    CData    ::=    (* - (* ']]>' *))
[21]    CDEnd    ::=    ']]>'

В секции CDATA распознается только один элемент разметки - строка . Поэтому все символы левой угловой скобки и амперсанта могут предстать здесь в своем обычном текстовом виде. Эти символы не нужно (да и невозможно) маскировать с помощью комбинаций "&lt;" и "&amp;". Секции CDATA не могут быть вложенными.

Пример секции CDATA, в которой строки "<greeting>" и "</greeting>" будут распознаваться не как , а как обычные :

<![CDATA[<greeting>Hello, world!</greeting>]]>




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




[18] CDSect    ::=   
[19]    CDStart    ::=    '<![CDATA['
[20]    CData    ::=    (* - (* ']]>' *))
[21]    CDEnd    ::=    ']]>'

В секции CDATA распознается только один элемент разметки - строка . Поэтому все символы левой угловой скобки и амперсанта могут предстать здесь в своем обычном текстовом виде. Эти символы не нужно (да и невозможно) маскировать с помощью комбинаций "&lt;" и "&amp;". Секции CDATA не могут быть вложенными.

Пример секции CDATA, в которой строки "<greeting>" и "</greeting>" будут распознаваться не как , а как обычные :

<![CDATA[<greeting>Hello, world!</greeting>]]>



Символьные данные


[14] CharData    ::=    [^<&]* - ([^<&]* ']]>' [^<&]*)



Символьные данные и разметка


документа образуется сочетанием и разметки. [Определение: Разметка принимает форму , , , , , , разделителей , , , , и любых пробельных символов, которые располагаются на верхнем уровне сущности документа (то есть, вне элемента document и за пределами иных элементов разметки).]

[Определение: Текст, который не относится к разметке, формирует символьные данные документа (character data).]

Символ амперсанта (&) и левая угловая скобка (<) могут появиться в своем обычном текстовом виде только в том случае, если используются в качестве ограничителя разметки, либо находятся в пределах , или . Если же эти символы потребовались в документе где-либо еще, их следует , воспользовавшись для этого либо соответствующей (numeric character reference), либо строками "&amp;" и "&lt;" соответственно. Правая угловая скобка (>) может быть представлена в виде строки "&gt;". Кроме того, если правая угловая скобка в содержимом элемента попадает в комбинацию символов "]]>", которая не соответствует окончанию , то, , эту скобку необходимо заменить ссылкой на символ либо комбинацией "&gt;".

Символьные данные в содержимом элемента - это любая строка символов, которая не содержит начальных ограничителей какой-либо разметки. Символьные данные в секции CDATA - это любая строка символов, которая не содержит закрывающего ограничителя секции CDATA (комбинации символов "]]>").

Если в значение атрибута необходимо поместить символ одинарной или двойной кавычки, то апостроф или символ одинарной кавычки (') следует представить комбинацией "&apos;", а символ двойной кавычки (") - как "&quot;".



Символы


[Определение: Разобранная сущность (parsed entity) содержит текст - последовательности , образующие разметку и символьные данные.] [Определение: символ - это элементарная единица текста, описанная в ISO/IEC 10646 (см. также ). Допустимы символы табуляции, возврата каретки, конца строки, а также разрешенные символы из наборов Unicode и ISO/IEC 10646. Последние версии указанных стандартов, актуальные на момент подготовки данного документа, перечислены в Приложении . Перечисленные стандарты могут быть дополнены новыми символами в ходе обновления или при написании для них новых редакций. Соответственно, XML процессоры должны принимать любой символ из диапазона, указанного для . Использовать "символы совместимости", описанные в главе 6.8 из (см. также D21 в главе 3.6 из ), нежелательно.]



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


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



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


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



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


[43] content    ::=    ? (( | | | | ) ?)* /* */

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



Ссылка на символ


[66] CharRef    ::=    '&#' [0-9]+ ';'
| '&#x' [0-9a-fA-F]+ ';'

Ограничение корректности: Допустимый символ

Символ, на который дается ссылка, должен отвечать сценарию .

Если ссылка на символ начинается с комбинации "&#x", то все последующие цифры и буквы вплоть до завершающего символа ; образуют шестнадцатеричное представление для кода этого символа, указанного в ISO/IEC 10646. Если же ссылка начинается с комбинации "&#", то все последующие цифры вплоть до завершающего ; образуют десятичное представление кода символа.

[Определение: Ссылка на сущность обращается к содержимому именованной сущности.] [Определение: Ссылка на разобранные общие сущности использует в качестве ограничителей амперсант (&) и символ точки с запятой (;).] [Определение: Ссылка на сущность параметра используют в качестве ограничителей символы процента (%) и точки с запятой (;).]



Ссылка на сущность


[67]    Reference    ::=    |
[68]    EntityRef    ::=    '&' ';'
[69]    PEReference    ::=    '%' ';'

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

Для документа без какого-либо DTD, для документа, имеющего лишь внутренний набор DTD, который не содержит ссылок на сущность параметра, а также для документа с декларацией "standalone='yes'": для каждого в ссылке на сущность, которая не попадает ни во внешний набор, ни в сущность параметра, должен иметься Name в одной из , которые также не располагаются ни во внешнем наборе, ни в сущности параметра. Исключение составляют корректные (well-formed) документы, для которых нет нужды декларировать сущности amp, lt, gt, apos и quot. Декларация общей сущности должна предшествовать всем ссылкам на нее, которые могут иметься в декларации списка атрибутов в составе значения по умолчанию.

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

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

В документе с внешним набором или внешними сущностями параметра, который имеет декларацию "standalone='no'", лексема в ссылке на сущность должна Name в одной из . Чтобы обеспечить взаимодействие, действительные документы должны декларировать сущности amp, lt, gt, apos, quot в том формате, который описан в главе . Декларация сущности параметра должна предшествовать любым ссылкам на нее. Точно так же декларация общей сущности должна предшествовать любым декларациям списка атрибута, содержащим значение по умолчанию с прямой либо косвенной ссылкой на эту общую сущность.

Ограничение корректности: Разобранная сущность


Ссылка на сущность не должна содержать имени . Ссылаться на неразобранные сущности можно только в тех , которые были декларированы как имеющие тип ENTITY или ENTITIES.

Ограничение корректности: Отсутствие рекурсии

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

Ограничение корректности: В 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;

Ссылки на символ и сущность


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



Статус этого документа


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

В данном документе формулируется синтаксис, пригодный для использования в World Wide Web и построенный как подмножество уже имеющегося и широко используемого международного стандарта обработки текстов (Standard Generalized Markup Language, SGML, ISO 8879:1986(E) улучшенного и исправленного). Данный документ является результатом работ по проекту W3C XML Activity, детальное описание которого можно найти по адресу . Нормативную силу имеет только английская версия спецификации, однако по адресу можно найти перевод этого документа на другие языки. На странице можно найти перечень текущих рекомендаций W3C и других технических документов.

Вторая редакция не является новой версией языка XML (первая была опубликована 10 февраля 1998 года). Она всего лишь учитывает изменения, продиктованные удобством читателей и выявленными ошибками (которые можно увидеть по адресу ). Перечень ошибок, обнаруженных во второй версии спецификации, можно увидеть по адресу .

Об ошибках, обнаруженных в данном документе, просьба сообщать по адресу ; Доступен переписки.

Замечание:

Со времени публикации первой редакции C. M. Sperberg-McQueen поменял место работы. Теперь он работает в World Wide Web Consortium и с ним можно связаться по адресу .



Сущность документа


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



Терминология


Терминология, используемая для описания XML документов, также дается в данной спецификации. При построении определений и описании функций XML процессора используются термины из следующего перечня:

может (may)

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

должен (must)

[Определение: Документы и XML процессоры обязаны действовать именно так, как было описано. В противном случае имеет место ошибка.]

ошибка (error)

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

фатальная ошибка (fatal error)

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

по выбору пользователя (at user option)

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

ограничение действительности (validity constraint, VC)

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


ограничение корректности (well-formedness constraint, WFC)

[Определение: Правило, относящееся ко всем XML документам. Нарушение ограничения корректности классифицируется как .]

соответствие (match)

[Определение: (Для строк или имен:) Две сравниваемые строки или имени должны быть идентичны. Символы с несколькими возможными представлениями в ISO/IEC 10646 (например, символы, имеющие обе формы представления precomposed и base+diacritic) считаются совпадающими только тогда, когда в обеих строках они имеют одну и ту же форму представления. Преобразование регистра не производится. (Для строк и правил грамматики:) Строка отвечает сценарию грамматики если она принадлежит языку, генерируемому по этому сценарию. (Для содержимого и моделей содержимого:) Элемент соответствует своей декларации если он отвечает положениям, описанным в соответствующем ограничении .]

для совместимости (for compatibility)

[Определение: Выделяет фразу, описывающую функцию языка XML, которая была включена в спецификацию исключительно для того, чтобы убедиться в том, что XML сохраняет совместимость с языком SGML.]

для взаимодействия (for interoperability)

[Определение: Выделяет фразу, описывающую необязательную рекомендацию, которая была включена в спецификацию для увеличения возможности обработки XML документов с помощью уже установленных SGML процессоров, указанных в Приложении WebSGML Adaptations к ISO 8879.]


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


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


[54] AttType    ::=    | |
[55]    StringType    ::=    'CDATA'
[56]    TokenizedType    ::=    'ID'
| 'IDREF'
| 'IDREFS'
| 'ENTITY'
| 'ENTITIES'
| 'NMTOKEN'
| 'NMTOKENS'

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

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

Ограничение действительности: Один ID для каждого типа элементов

Любой тип элемента не может иметь более одного атрибута ID.

Ограничение действительности: Значение по умолчанию для атрибута ID

Для атрибута ID должно быть декларировано значение по умолчанию #IMPLIED или #REQUIRED.

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

Значения типа IDREF должны соответствовать сценарию , а значения типа IDREFS должны соответствовать . При этом каждое должно соответствовать значению атрибута ID в каком-либо элементе XML документа, то есть, значение IDREF должно соответствовать значению какого-либо из атрибутов ID.

Ограничение действительности: Имя сущности

Значения типа ENTITY должны соответствовать сценарию , значения типа ENTITIES должны соответствовать . Каждое при этом должно соответствовать названию одной из , декларированных в .

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

Значения типа NMTOKEN должны соответствовать сценарию , значения типа NMTOKENS должны соответствовать .

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



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


[57]    EnumeratedType    ::=    |
[58]    NotationType    ::=    'NOTATION' '(' ? (? '|' ? )* ? ')'
[59]    Enumeration    ::=    '(' ? (? '|' ? )* ? ')'

Атрибут NOTATION идентифицирует , которая была декларирована в DTD вместе с ассоциированными с нею системными и/или общими (public) идентификаторами, и которую следует использовать для интерпретации элемента, в котором был указан данный атрибут.

Ограничение действительности: Атрибуты нотации

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

Ограничение действительности: Одна нотация для каждого типа элемента

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

Ограничение действительности: Отсутствие нотаций для пустого элемента

Для сохранения , для элемента, объявленного как EMPTY, атрибут типа NOTATION декларироваться не должен.

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

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

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



Тэги пустых элементов


[44]    EmptyElemTag    ::=    '<' ( )* ? '/>'

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

Примеры пустых элементов:

<IMG align="left" src="http://www.w3.org/Icons/WWW/w3c_home" /> <br></br> <br/>



Условная секция


[61] conditionalSect    ::=    | ignoreSect
[62]    includeSect    ::=    '<![' S? 'INCLUDE' S? '[' ']]>' /* */
[63]    ignoreSect    ::=    '<![' S? 'IGNORE' S? '[' * ']]>' /* */
[64]    ignoreSectContents    ::=    ('<![' ']]>' )*
[65]    Ignore    ::=    * - (* ('<![' | ']]>') *)

Ограничение действительности: Правильная вложенность условной секции/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?)> ]]>



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


[Определение: Условная секция является фрагментом внешнего набора для , которая включается или исключается из логической структуры DTD в зависимости от значения управляющего ею ключевого слова.]



Уведомление


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



Включается


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



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


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

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

а этот - нет:

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



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


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



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


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

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



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


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



Внешний набор


[30] extSubset    ::=    ?
[31]    extSubsetDecl    ::=    ( | | )* /* */

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

Пример 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>

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



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


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

Внутренняя сущность является .

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

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



Возникновение языка XML и его задачи


Язык XML был разработан группой XML Working Group (первоначально называемой SGML Editorial Review Board), сформированной в 1996 году под патронажем World Wide Web Consortium (W3C). Председательствует в группе Jon Bosak из Sun Microsystems, принимающий также активное участие в работе группы XML Special Interest Group (ранее известной как SGML Working Group), которая тоже была сформирована W3C. Список членов XML Working Group представлен в Приложении. Связь группы с W3C обеспечивает Dan Connolly.

При разработке языка XML ставились следующие задачи:

XML должен быть пригоден для непосредственного использования в Интернет.

XML должен иметь широкий круг применения.

XML должен быть совместим с SGML.

Обработчики документов XML должны быть просты в написании.

Количество факультативных свойств в XML должно быть сведено к абсолютному минимуму, в идеале число их вообще должно быть нулевым.

XML документы должны быть удобны для чтения и достаточно понятны.

Подготовка XML документа должна осуществляться быстро.

Процедура построения XML документа должна быть формальной и точной.

Процедура создания XML документов должна быть проста.

Краткость при разметке XML документа имеет минимальное значение.

Данная спецификация в сочетании с остальными связанными с нею стандартами (Unicode и ISO/IEC 10646 для символов, Internet RFC 1766 для тэгов идентификации языка, ISO 639 для кодов с названием языка и ISO 3166 для кодов с названием страны) дает всю необходимую информацию для понимания языка XML (версия 1.0) и создания компьютерных программ для его обработки.

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



а также частично описывает работу


Расширяемый язык разметки (Extensible Markup Language, аббревиатура - XML) описывает класс объектов , а также частично описывает работу компьютерных программ, обрабатывающих объекты с данными, реализующими этот класс. XML - это прикладной уровень или усеченная форма SGML, Стандартного Обобщенного языка разметки . По своему построению, XML документ является полноценным SGML документом.
XML документы состоят из единиц размещения, называемых , которые содержат разобранные или неразобранные данные. Разобранные данные состоят из набора , часть которых образуют , часть - . Разметка образует описание схемы размещения и логической структуры документа. Язык XML дает механизм создания ограничений для указанной схемы размещения и логической структуры.
[Определение: Для чтения XML документа, доступа к его содержимому и структуре используется программный модуль, называемый XML процессором.] [Определение: Предполагается, что XML процессор выполняет свою работу по заданию другого модуля, называемого приложением.] Данная спецификация формулирует требования к работе XML процессора, указывая как именно он должен читать данные XML и какую информацию в результате он должен предоставить приложению.

Запрещен


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

появление ссылки на .

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

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



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


[60] DefaultDecl    ::=    '#REQUIRED' | '#IMPLIED'
| (('#FIXED' S)? )

Запись #REQUIRED в декларации атрибута означает, что этот атрибут должен присутствовать в элементе всегда, #IMPLIED означает, что значения по умолчанию для атрибута не предоставляется. [Определение: Если в декларации нет ни #REQUIRED, ни #IMPLIED, то значение содержит значение, декларированное по умолчанию. Ключевое слово #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">



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


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