Новый вид пространства имен

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

Читатели, разумеется, понимают, что выпуск новой технологии W3C не менее болезненнен, чем прорезыванием зубов. Рекомендации W3C - это вовсе не такие упакованные в целлофан посылки, каковыми их обычно считают. Вероятно, каноническим примером этого являются XML и Namespaces Recommendation, несколько неожиданный отклик на которые ощущается до сих пор; хотя обычно спецификацию восторженно представляет кто-либо из ее основных приверженцев.

Этим летом "трудным подростком" несомненно была W3C XML Schema. На www.xml.com уже рассматривался один из проблемных аспектов Schema: это использование неквалифицированных элементов в типах пространства имен. Дискуссия по XML-DEV, имевшая место в середине августа, хотя и не внесла ясности в этот вопрос, тем не менее позволила четко сформулировать мотивацию, лежащую в основе этого метода. Эта статья описывает мотивацию добавления XML Schema в XML новой формы пространства имен.

Чтобы познакомиться с этой темой поближе, возможно, стоит просмотреть прошедшие дискуссии, обобщенные в XML-Deviant. Тема была предложена в Schema Scuffles and Namespace Pains. Проблема была выявлена в структуре типа:

<foo:person xmlns:foo="http://best.practice.com">
  <familyName> KAWAGUCHI </familyName>
  <lastName> Kohsuke </lastName>
</foo:person>

W3C XML Schema поощряет создание таких структур. Основной претензией к ним является необходимость соответствующей XML Schema для понимания того, что типы элементов familyName и lastName принадлежат логическому модулю foo:person, поскольку, если они находятся в том же пространстве имен, очевидно предполагать, что они принадлежат к одному и тому же виду словаря. Саймон Сент-Лорен (Simon St.Laurent) пошел еще дальше, создав некоторое программное обеспечение, нормализующее такие структуры, и перемещающее familyName и lastName в то же пространство имен, что и person.

Дискуссия развивалась, и это представление стало восприниматься как в значительной степени зависящее от удачной реализации. Да, W3C XML Schema позволяет вам сделать это, однако, возможно, вам полезнее будет этого избежать. На самом деле W3C XML Schema поощряет такую практику, поддерживая по умолчанию дочерние элементы типа, не имеющие пространства имен. В Opening Old Wounds Лей Доддс (Leigh Dodds) несколько более подробно описал дискуссию, выявившую такую странную ситуацию, однако он высказался против правил конфиденциальности W3C, утверждая, что широкая общественность так и не получила объяснений по поводу решения Рабочей Группы Schema сделать дочерние элементы неквалифицированными по умолчанию.

За последнюю неделю при обмене мнениями Тима Брея (Tim Bray), бывшего редактора спецификации XML Namespaces, и Мэтью Фачса (Matthew Fuchs), участвовавшего в Рабочей Группе W3C XML Schema, на свет появилось еще больше информации. Выпуск Сент-Лореном своей программы для организации копий документов в соответствии с мировой квалификацией произвел в XML-DEV настоящий фурор. В ответ, Брей сказал, что "потратив определенное время на чтение этого обсуждения, я понял, что я не понимаю ни локальные типы, ни фильтры Симона". Далее Брей обобщает увиденное им в качестве мотивации этой ситуации.

Людям хочется использовать схему X для проверки допустимости элемента Y, но им не нужно, чтобы элемент Y был в пространстве имен (даже пространстве имен по умолчанию), они предпочитают связь, выбранную из пространства имен элемента-предшественниками, и "локальные типы элементов" допускают это.

С одной стороны это выглядит рациональным: "пожалуйста, воспользуйтесь следующим правилами для проверки допустимости элементов, не принадлежащих ни к каким пространствам имен, типом которых является Y, а предшественником - myNS:Z."

Определив мотивацию, Брей затем отметил другую сторону проблемы - что все это плохо согласуется с некоторыми базовыми идеями использования XML Namespaces.

С другой стороны, это противоречит исключительно простой процедуре связывания разметки с программным обеспечением XML+namespaces: определение разметки для программы путем помещения ее в пространство имен. Что уже довольно серьезно. По умолчанию, простой и очевидный способ организации в программном модуле X обработки элемента Y состоит в объявлении, что X обрабатывает элементы, относящиеся к пространству имен NSx. Это что-то вроде беспокойства о поддержке схемой невзаимодействующих, более сложных и менее устойчивых способов соединения разметки и программного обеспечения. Что такое ее поведение по умолчанию просто-таки недопустимо.

Отвечая Брею, Мэтью Фачс заметил, определив темой своего сообщения совпадение мотивации, лежащей в основе механизма локальных типов в W3C XML Schema с той, что привела к XML Namespaces. Для начала Фачс выступил против утверждения Брея о желании людей локально очерчивать область имен в их схемах.

Мотивация здесь та же, что и для любых языков определения данных, появившихся за последние 40 лет и локально очерчивающих область имен - использование конкретного имени в конкретном контексте должно не портить общий контекст, но позволять использовать одно имя для обозначения разных объектов в разных контекстах. Что на семантическом уровне означает в точности то, для чего и предназначены пространства имен - и не надо путать цель и конкретный синтаксис для ее достижения.

Далее Фачс объяснил желание использовать элементы с локально очерченной областью на простом примере. В словаре XML для согласования музыки, графики и текста, музыкант дизайнер и редактор имеют некоторые представления "строки" ("line"), и каждый из них желает, чтобы эти представления отличалось. Если локальное ограничение области было бы невозможно, тип элемента неопределенной строки имел бы глобальную область в схеме, и три представления были бы неразличимы. Если же каждое представление строки имело бы пространство имен, это решило бы проблему, но привело бы к появлению примеров, подобных этому:

<music><music:line>
... </music:line></music>

Фачс говорит, что исключение такой фрагментации как раз и является целью использования в XML Schema локальных имен.

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

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

Таким образом, в известной степени туман рассеялся. Добавление локально-ограниченных типов в XML Schema не является аномалией. Это действительно выглядит неожиданно, однако, потребовалось много времени, чтобы найти рациональное оправдание этой функциональной возможности. Тим Брей, похоже, был удовлетворен объяснением Фачса:

OK, я думаю, я понял. Локальные типы элементов допускают, чтобы элемент <line> имел различные правила проверки допустимости в зависимости от того, является ли он дочерним для <matt:music>, <matt:graphics> или <matt:text>. Это явно одна из тех вещей, которые невозможны, но очень желательны в DTD.

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

Автор: Эдд Дамбил (Edd Dumbill)