Extensible Markup Language 1.0-2000-1

Расширяемый язык разметки (XML) 1.0 (вторая редакция)

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

Copyright © 2000 W3C^® (MIT, INRIA, Keio), Все права защищены. В отношении данного документа действуют правила W3C, касающиеся обязательств, торговой марки, использования документа и лицензирования программного обеспечения.

Резюме

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

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

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

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

Вторая редакция не является новой версией языка XML (первая была опубликована 10 февраля 1998 года). Она всего лишь учитывает изменения, продиктованные удобством читателей и выявленными ошибками (которые можно увидеть по адресу http://www.w3.org/XML/xml-19980210-errata). Перечень ошибок, обнаруженных во второй версии спецификации, можно увидеть по адресу http://www.w3.org/XML/xml-V10-2e-errata.

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

Замечание:

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

1 Введение

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

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

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

1.1 Возникновение языка 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 ставились следующие задачи:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

может (may)

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

должен (must)

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

ошибка (error)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 Документы

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

Каждый XML имеет логическую и физическую структуру. Физически документ состоит из элементов, называемых сущностями. Любая сущность может ссылаться на другие сущности, обеспечивая их включение в данный документ. Документ начинается с "корня" или сущности документа. С логической точки зрения, документ строится из деклараций, элементов, комментариев, ссылок на символ и инструкций обработки. Все они размечаются в документе явным образом. Логические и физические структуры должны иметь корректную вложенность, как было описано в главе 4.3.2 Корректные разобранные сущности.

2.1 Корректные XML документы

[Определение: Текстовый объект становится корректным (well-formed) XML документом, если:]

1. Как единое целое, он соответствует сценарию document.

2. Отвечает всем ограничениям корректности, представленным в этой спецификации.

3. Все разобранные сущности, на которые в данном документе прямо или косвенно делается ссылка, являются корректными (well-formed).

Документ

[1] document ::= prolog element Misc*

Соответствие сценарию document подразумевает следующее:

1. В данном объекте содержится один или несколько элементов.

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

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

2.2 Символы

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

Диапазон символов

[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* любой символ Unicode, исключая суррогатные блоки, FFFE и FFFF. */

Механизм шифрования символьных кодов использует битовые шаблоны, которые могут меняться от сущности к сущности. Все XML процессоры должны иметь возможность работать с кодировками UTF-8 и UTF-16 из набора 10646. Механизм для указания используемой кодировки и подключения новых кодировок обсуждается позднее в главе 4.3.3 Кодирование символов в сущностях.

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

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

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

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

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

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

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

Замечание:

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

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

Имена и лексемы

[4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender [5] Name ::= (Letter | '_' | ':') (NameChar)* [6] Names ::= Name (S Name)* [7] Nmtoken ::= (NameChar)+ [8] Nmtokens ::= Nmtoken (S Nmtoken)*

Строковые данные (literal data) - это любая заключенная в кавычки строка, внутри которой нет кавычек, которые можно было бы принять за разделители этой строки. Строковые данные, или литералы (literals), применяются для указания содержимого внутренних сущностей (EntityValue), значений атрибутов (AttValue) и внешних идентификаторов (SystemLiteral). Заметим, что идентификатор SystemLiteral может быть обработан без проверки разметки.

Литералы

[9] EntityValue ::= '"' ([^%&"] | PEReference | Reference)* '"' |  "'" ([^%&'] | PEReference | Reference)* "'" [10] AttValue ::= '"' ([^<&"] | Reference)* '"' |  "'" ([^<&'] | Reference)* "'" [11] SystemLiteral ::= ('"' [^"]* '"') | ("'" [^']* "'") [12] PubidLiteral ::= '"' PubidChar* '"' | "'" (PubidChar - "'")* "'" [13] PubidChar ::= #x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]

Замечание:

Хотя сценарий EntityValue и позволяет определить сущность, состоящую из одного единственного простого символа < в строке данных (имеется ввиду <!ENTITY mylt "<">), настоятельно рекомендуется избегать подобной практики, поскольку любая ссылка на указанную сущность приведет к появлению ошибки корректности.

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

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

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

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

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

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

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

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

2.5 Комментарии

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

Комментарии

[15] Comment ::= '<!--' ((Char - '-') | ('-' (Char - '-')))* '-->'

Пример комментария:

<!-- declarations for <head> & <body> -->

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

<!-- B+, B, or B--->

2.6 Инструкции обработки

[Определение: Инструкции обработки (processing instruction, PI) позволяют размещать в документе инструкции для приложений.]

Инструкции обработки

[16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>' [17] PITarget ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))

Хотя PI не относятся к символьным данным документа, они точно так же должны быть переданы приложению. Инструкция PI начинается с указания адреса (PITarget), используемого для идентификации приложения, которому предназначается эта инструкция. Адреса с названиями "XML", "xml" и аналогичными зарезервированы для стандартизации в текущей и последующих версиях спецификации. Для формального декларирования адресата инструкции PI может использоваться механизм нотаций XML. Ссылки на сущность параметра в инструкциях обработки не распознаются.

2.7 Секции CDATA

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

Секции CDATA

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

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

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

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

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

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

Пролог

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

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

Читать дальше >>

РОЛ.RU