Пространства имен в XML 1.1

В 15-ом номере Журнала мы писали о проекте обновлений пространств имен в XML
1.1. Предложение международного консорциума W3C вызвало неоднозначную реакцию в
стане разработчиков. Предлагаем вашему вниманию статью Ли Додза, в которой
автор объясняет причины столь оживленной полемики.

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

Новый проект

Если пробежаться по рабочему проекту обновлений пространств имен (Namespaces in XML 1.1 Working Draft) нетрудно заметить, что предложенные изменения - для удобства они выделены цветом - минимальны. После же изучения прилагаемого списка требований (requirements document) становится ясно, что сделано это умышленно. За исключением некоторых незначительных исправлений, технология пространств имен в XML 1.1 получит только одну единственную дополнительную характеристику - появится возможность не декларировать (undeclare) префикс (prefix) пространства имен.

Применительно к этим изменениям в требованиях объясняется, что новая спецификация должна получить статус Рекомендации в дополнение к XML 1.1. В своей колонке на XML-DEV Ричард Тобин (Richard Tobin) определил отношение между этими двумя спецификациями следующим образом:

"Планируется, что пространства имен 1.1 будут жестко привязаны к XML 1.1, так что они будут использоваться только в документах XML 1.1. Парсеры (parser), обрабатывающие только XML 1.0, будут отклонять документы, помеченные как 1.0, а процессоры, распознающие пространства имен 1.1, будут применять пространства имен 1.0 к документам 1.0, а пространства имен 1.1 к документам 1.1".

В "Часто спрашиваемых вопросах о пространствах имен" (Namespace FAQ explains) Рональд Бауррет (Ronald Bourret) пишет, что хотя можно не декларировать пространство имен, используемое по умолчанию, нельзя не декларировать пространство имен, связанное с префиксом. Согласно списку требований к пространствам имен 1.1, это является значительной проблемой, которая затрагивает несколько других спецификаций, включая XQuery, SOAP and Xinclude.

Основная сложность состоит в том, что в соответствие с рекомендацией по XML Infoset, каждый элемент имеет ряд "информационных единиц пространства имен" ('namespace information items'), один для каждого из объявлений пространства имен, находящегося в области видимости этого элемента. Пространство имен, находящееся в области видимости - это любое пространство имен, объявленное на индивидуальном элементе или на одном из его предков. А это проблематично, поскольку каждый элемент, заканчиваясь, несет дополнительный "багаж" в виде объявлений пространств имен, в которых он не нуждается.

При работе с большими документами - подобная ситуация может возникнуть, например, при генерации XQuery над XML-базой - эти свойства, вероятно, добавят большое количество протокольных данных в информационный набор Infoset, особенно для глубоко иерархических данных. Эта проблема также характерна для XInclude, который позволяет включать фрагменты других документов в один главный документ. Если сравнить набор пространств имен, находящихся в области видимости, может оказаться, что в первоначальном документе он был меньше, чем в новом контексте. Точное преобразование этих данных в поток затруднительно, так как полный обход по Infoset не может быть передан в XML без добавления в повторно анализируемый (reparsed) Infoset дополнительных свойств, которые не были частью оригинала.

Так что, несмотря на то, что эта новая функциональность и является логическим расширением существующей технологии, ее появление в значительной степени объясняется тем, как разработан Infoset. Способность не декларировать пространства имен на самом деле не предоставляет автору документа дополнительные возможности: при желании он уже может связывать префикс с новым URI. Вероятный побочный эффект этого изменения - полный обход по XML-документу может внести лексические изменения - дополнительные атрибуты для того, чтобы не декларировать пространства имен - просто для сохранения модели данных.

Пытаясь понять, почему рекомендация по Infoset была разработана таким образом, я поместил следующий вопрос на XML-DEV: "зачем элементу нужны информационные единицы пространства имен?" Особенно, когда Infoset связывает пространство имен и префикс с каждой информационной единицей элемента (element information item).

Заглядывая в корень

Я получил несколько ответов, в том числе и от Ричарда Тобина (соредактора спецификации Infoset) - он пояснил, что парсеры не требуют информационные единицы пространства имен. На самом деле, они необходимы для того, чтобы корректно интерпретировать QNames> (namespace qualified names, квалифицированные имена пространств имен) в контексте элемента и атрибута. А Майк Кэй показал, какие проблемы могли бы возникнуть при движении элементов между Infoset-ми, если такая информация недоступна. Он также отметил, что решение позволить QNames быть значениями элемента и атрибута, возможно, было ошибочным, но, по его мнению, его слишком поздно менять:

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

Постоянные читатели XML-Deviant помнят статью "Значение имен в атрибутах" (The Value of Names in Attributes) Кендалла Кларка (Kendall Clark), в которой он подвел итог дискуссии по данному вопросу.

Теперь, когда стало понятно, зачем Infoset требует, чтобы эта информация была доступна, можно рискнуть заново сформулировать требование по введению пространств имен 1.1: "необходимость исправить побочные эффекты присутствия QNames в значениях элемента и атрибута". Взглянув на проблему под таким углом, невольно задаешься вопросом: а не увидим ли мы другие побочные эффекты, как только ощутим влияние других проектных решений?

Проблемы области видимости

Майк Кэй пошел немного дальше и предположил, что первопричина всех этих сложностей кроется в непонимании влияния пространств имен на структурном уровне:

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

Эти слова отражают точку зрения многих членов XML-DEV. Наибольшее раздражение вызвало требование"быстро приготовить" эти исправления. Так, учитывая ограниченный объем изменений, Эллиотт Хэрольд (Elliotte Harold) призвал Рабочую группу (XML Working Group) "найти время сделать это надлежащим образом или не делать вообще". Оценивая работу консорциума W3C в целом, он отметил, что "основной акцент делается на то, чтобы выкинуть хоть что-нибудь, вместо того, чтобы отбросить действительно то, что ненужно".

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

"Вершина айсберга по имени пространства имен", - именно так охарактеризовал Майк Чэмпион (Mike Champion) предлагаемые изменения. Он составил список проблем, которые характерны для альтернативных моделей пространств имен нескольких других спецификаций W3C, отметив, что:

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

Во время обсуждения было выдвинуто предложение объединить спецификации XML и пространств имен в единый документ. Мнения по этому поводу диаметрально разделились: некоторые видят XML и пространства имен истинной основой. Другие не желают отказываться от возможности игнорировать пространства имен или же принимать альтернативные варианты. Проект Skunkworks XML 2.0 Тима Брея (Tim Bray) был приведен в качестве иллюстрации того, как можно было бы достигнуть указанного объединения; однако, документ Брея в свою очередь вызвал дополнительные опасения, поскольку он удаляет DTD из основной спецификации. В результате, последовал жаркий спор о том, как можно было бы усовершенствовать DTD для лучшей поддержки пространств имен XML. Мы не будем пытаться резюмировать всю дискуссию - она слишком длинна, однако стоит заметить, что в проекте ISO DSDL присутствует раздел, посвященный "Обработке пространств имен с DTD синтаксисом" (Namespace-aware processing with DTD syntax), который возможно будет реализован вне консорциума W3C.

Итак, несмотря на бурную реакцию, объем изменений XML 1.1 и пространств имен в XML 1.1 останется точно таким, как он был изложен в нынешних требованиях. Во всяком случае, Ричард Тобин ясно дал это понять. Остается только гадать, потребуется ли в дальнейшем дорабатывать эти и другие спецификации.

Автор: Ли Доддз (Leigh Dodds)