B Классы символов

Приводимые далее определения были представлены в стандарте Unicode. Все символы делятся на базовые символы (BaseChar, наряду с прочим сюда включены буквы латинского алфавита), идеографические символы (Ideographic), комбинированные символы (CombiningChar, в последнюю группу попадает также большинство диакритических символов). Выделяются также цифры (Digit) и расширения (Extender).

Символы

Представленные здесь классы символов могут быть извлечены из базы данных символов Unicode 2.0 следующим образом:

• Начальные символы Name (Name start) должны иметь одну из следующих категорий: Ll, Lu, Lo, Lt, Nl.

• Символы Name, за исключением Name-start, должны иметь одну из следующих категорий: Mc, Me, Mn, Lm, or Nd.

• В XML именах нельзя использовать символы из области совместимости (то есть, символы с кодом, большим чем #xF900 и меньшим чем #xFFFE).

• Нельзя использовать символы, имеющие шрифт или расклад совместимости (то есть, имеющие "тэг совместимости форматирования" в 5-м поле базы данных - имеющие метку в поле 5, начинающемся с "<").

• Символы [#x02BB-#x02C1], #x0559, #x06E5, #x06E6 обрабатываются как name-start символы, а не как символы name, поскольку классификатор определяет их как алфавитные.

• Символы #x20DD-#x20E0 исключены (в соответствии с требованиями Unicode 2.0, глава 5.14).

• Символ #x00B7 классифицируется как расширение, поскольку именно таким образом он идентифицируется в перечне свойств.

• Символ #x0387 добавлен как name символ, поскольку #x00B7 является его каноническим эквивалентом.

• Символы ':' и '_' допустимы в качестве name-start символов.

• Символы '-' и '.' допустимы в качестве name символов.

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

XML построен как подмножество SGML, поэтому каждый XML документ должен также отвечать требованиям, предъявляемым к SGML документу. Детальное сравнение ограничений, которые языки XML и SGML накладывают на документы, см. в статье [Clark].

D Обработка ссылок на сущность и символ (Пояснения к спецификации)

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

Если DTD содержит декларацию

<!ENTITY example "<p>An ampersand (&#38;#38;) may be escaped numerically (&#38;#38;#38;) or with a general entity (&amp;amp;).</p>" >

то в ходе обработки этой декларации сущности XML процессор обнаружит ссылки на символ и обработает их прежде чем следующая строка будет использована в качестве значения сущности "example":

<p>An ampersand (&#38;) may be escaped numerically (&#38;#38;) or with a general entity (&amp;amp;).</p>

Появление в документе ссылки на элемент "&example;" приведет к тому, что этот текст будет разобран снова. Будут обнаружены начальный и конечный тэги элемента p, а также будут обнаружены и обработаны все три ссылки. В результате элемент p будет иметь следующее содержание (все данные, но без ограничителей и разметки):

An ampersand (&) may be escaped numerically (&) or with a general entity (&).

Более сложный пример полностью проиллюстрирует эти правила и их эффективность. (Номера строк в следующем примере нужны лишь для комментариев.)

1 <?xml version='1.0'?> 2 <!DOCTYPE test [ 3 <!ELEMENT test (#PCDATA) > 4 <!ENTITY % xx '&#37;zz;'> 5 <!ENTITY % zz '&#60;!ENTITY tricky "error-prone" >' > 6 %xx; 7 ]> 8 <test>This sample shows a &tricky; method.</test>

В результате получается следующий сценарий:

• в строке 4 ссылка на символ с кодом 37 обрабатывается сразу, и сущность параметра "xx" помещается в таблицу символов со значением "%zz;". И поскольку текст замены повторно не просматривается, ссылка на сущность параметра "zz" обнаружена не будет. (Если же это здесь произойдет, то будет зафиксирована ошибка, поскольку сущность "zz" еще не была декларирована.)

• в строке 5 ссылка на символ "<" обрабатывается сразу, и сущность параметра "zz" обзаводится текстом замены "<!ENTITY tricky "error-prone" >", являющимся корректной декларацией сущности.

• в строке 6 обнаруживается ссылка на сущность "xx" и, соответственно, производится разбор текста замены для этой сущности (а именно, "%zz;"). При этом обнаруживается ссылка на сущность "zz" и тоже анализируется ее текст замены ("<!ENTITY tricky "error-prone" >"). В результате получаем декларацию общей сущности "tricky" с текстом замены "error-prone".

• в строке 8, обнаруживается и обрабатывается ссылка на общую сущность "tricky". В итоге получаем полное содержимое элемента test в виде самодостаточной (и не связанной с какой-либо грамматикой) строки This sample shows a error-prone method.

E Детерминистические модели содержания (Пояснения к спецификации)

Как указывалось в главе 3.2. Содержимое элемента, необходимо чтобы модели содержимого, даваемые в декларациях типов элементов, были детерминистическими. Данное требование необходимо для совместимости с языком SGML (в котором детерминистические модели содержания обозначаются термином "unambiguous"). XML процессоры, построенные на базе систем SGML, могут выявлять недетерминистические модели содержания как ошибочные.

К примеру, модель содержимого ((b, c) | (b, d)) является недетерминистической, поскольку, получив исходный b, XML процессор не может знать, какому b в исходной модели он соответствует, не проследив далее по строке, какой элемент следует за указанным b. В данном случае обе ссылки на b можно свести в одну общую ссылку, преобразовав рассматриваемую модель в (b, (c | d)). Теперь исходный элемент b соответствует ровно одному имени в модели содержания, и процессору нет нужды заглядывать вперед чтобы увидеть, что за ним следует. Это может быть и c, и d.

Или более формально: с помощью стандартных алгоритмов по модели содержания может быть выстроен автомат конечных состояний, например алгоритм 3.5 из главы 3.9 в книге авторов Aho, Sethi и Ullman [Aho/Ullman]. Во многих таких алгоритмах для каждой части в регулярном выражении строится сопроводительный набор команд (то есть, в дереве синтаксиса данного регулярного выражения стоится каждый узел листа). Если какая-либо часть выражения имеет сопроводительный набор, в котором более одной позиции сопоставлено с типом элементов с одним и тем же названием, модель содержимого ошибочна и об этом можно сообщать как об ошибке.

Существуют алгоритмы, которые способны многие (хотя и не все) недетерминистические модели содержания автоматически привести к эквивалентным детерминистическым моделям (см. Brüggemann-Klein 1991 [Brüggemann-Klein]).

F Автоматическое определение кодировки символов (Пояснения к спецификации)

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

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

Данная спецификация была подготовлена и принята к публикации рабочей группой W3C XML (W3C XML Working Group, WG). Однако из того, что WG приняла данную спецификацию, не следует, что все члены WG единогласно проголосовали за это решение. Настоящие и бывшие члены XML WG:

• Jon Bosak, Sun (Председатель)
• James Clark (Технический руководитель)
• Tim Bray, Textuality and Netscape (XML со-редактор)
• Jean Paoli, Microsoft (XML со-редактор)
• C. M. Sperberg-McQueen, U. of Ill. (XML со-редактор)
• Dan Connolly, W3C (представитель W3C)
• Paula Angerstein, Texcel
• Steve DeRose, INSO
• Dave Hollander, HP
• Eliot Kimber, ISOGEN
• Eve Maler, ArborText
• Tom Magliery, NCSA
• Murray Maloney, SoftQuad, Grif SA, Muzmo and Veo Systems
• MURATA Makoto (FAMILY Given), Fuji Xerox Information Systems
• Joel Nava, Adobe
• Conleth O'Connell, Vignette
• Peter Sharpe, SoftQuad
• John Tigue, DataChannel

H Основная группа W3C XML (Пояснения к спецификации)

Вторая редакция данной спецификации была подготовлена основной рабочей группой W3C XML (W3C XML Core Working Group, WG). Членами группы на момент опубликования этой редакции являлись:

• Paula Angerstein, Vignette
• Daniel Austin, Ask Jeeves
• Tim Boland
• Allen Brown, Microsoft
• Dan Connolly, W3C (работа с персоналом)
• John Cowan, Reuters Limited
• John Evdemon, XMLSolutions Corporation
• Paul Grosso, Arbortext (со-председатель)
• Arnaud Le Hors, IBM (со-председатель)
• Eve Maler, Sun Microsystems (Редактор второй редакции)
• Jonathan Marsh, Microsoft
• MURATA Makoto (FAMILY Given), IBM
• Mark Needleman, Data Research Associates
• David Orchard, Jamcracker
• Lew Shannon, NCR
• Richard Tobin, University of Edinburgh
• Daniel Veillard, W3C
• Dan Vint, Lexica
• Norman Walsh, Sun Microsystems
• Franзois Yergeau, Alis Technologies (редактор списка ошибок)
• Kongyi Zhou, Oracle

I Рабочие заметки (Пояснения к спецификации)

Вторая редакция спецификации была также преобразована в XMLspec DTD (для которой имеется соответствующая документация). HTML версии спецификации были получены с помощью XSLT стилей xmlspec.xsl, diffspec.xsl и REC-xml-2e.xsl. PDF версия документа была получена с помощью инструментария html2ps и программы выделения.