Язык XML уже сильно распространён, но способы и методы его применения еще находятся в процессе развития. Кроме того, даже уже оформившиеся подходы часто имеют некачественный дизайн, что весьма затрудняет обработку данных и поддержку языка. Существенную часть этих проблем составляют сложности, связанные с инфраструктурой обслуживания XML. С целью решения данных проблем был организован ряд общественных обсуждений накоплиного опыта в области XML. Предлагаем вниманию читателей мнение одного из известных экспертов XML Юча Огбуджи (Uche Ogbuji), статьи которого неоднократно появлялись на страницах нашего Журнала. На этот раз он дает практические советы в области дизайна XML и рассуждает о наиболее передовых подходах к использованию XML.

Как не выглядеть некомпетентным в области XML

Хенри Сивонен (Henri Sivonen) написал весьма полезную статью — «Как избежать обвинений в некомпетентности при работе с XML» (HOWTO Avoid Being Called a Bozo When Producing XML) (см. раздел Ресурсы). В ней он обсуждает, как корректно работать с XML, используя пространства имен и возможности форматов загрузки Интернета на основе XML — RSS и Atom. Во введении к своей статье он огаваривает, что существуют разработчики, которые считают, что очень трудно или даже практически невозможно добиться корректности при создании документов XML путем программирования. Но в то же время есть разработчики, которые легко справляются с этой задачей и не могут понять, почему другие столь некомпетентны. Никто не хочет считать себя некомпетентным. Советы, приведенные ниже, помогут избежать этого неприятного ощущения.

Первый совет Хенри Сивонена заключался в том, что не надо рассматривать XML как текстовый формат. Автор настоящей статьи полагает, что это весьма опасный совет. Его основная идея верна: при создании или редактировании документа XML следует быть более осторожным, чем при работе с обычным текстовым документом. Но это относится ко всем текстовым форматам любой структуры. Однако утверждение, что документ XML не является текстом, — это отрицание одной из базовых характеристик XML, обозначенной в определении XML, которое дается в его спецификации («Текстовый объект является корректно оформленным документом XML [если он соответствует настоящей спецификации]»). Помимо этого, в XML существует техническое определение текста как последовательности символов, интерпретируемых как XML. Текст — это не просто символы, ограниченные элементами дерева или атрибутами. Данная структура технически называется символьными данными. Текст — основа всех сущностей XML, поэтому утверждение, что XML — это не текст, является противоречивым. Гораздо полезнее подчеркнуть специфические особенности, которые отличают XML от текстовых форматов, уже известных разработчикам.

Хенри Сивонен, безусловно, прав, предупреждая о том, что нельзя бездумно объединять все в одно понятие и надеяться, что документ XML будет корректно оформлен. При создании документов XML лучше использовать хорошо разработанные комплекты инструментов XML, а не простые текстовые инструменты (см. статью автора в разделе Ресурсы). Общий совет может быть таким: не использовать механизмы, если нет уверенности в том, что они приведут к созданию корректно оформленного документа XML. Одни из подходов к безопасному созданию документов XML — пересылка событий SAX1 с использованием для этого дерева, стека или парсера XML. Но при этом нужно помнить, что инструменты SAX могут не обеспечивать все необходимые операции по проверке корректности. Например, в XML не допускаются некоторые символы Unicode. Для выявления таких моментов могут понадобиться дополнительные проверки.

Разумным также выглядит предложение о том, что пользователи не должны вручную управлять пространствами имен. С пространствами имен XML необходимо обращаться очень осторожно. Обычно разработчики оперируют универсальными именами (пространство имени универсального указателя ресурса (Uniform Resource Identifier, сокр. URI) плюс локальное имя (local name)), но иногда им приходится иметь дело с префиксами или декларациями XML. В спецификациях, подобных XSLT (Extensible Stylesheet Transformation Language — расширяемый язык преобразования таблиц стилей), внутри значений атрибутов может использоваться класс QName (комбинация префикса и локального имени). При этом предполагается, что префикс интерпретируется в соответствии с внутренними декларациями пространств имен. Такой вариант использования называется контекстным оператором QName (QName in context). В данном случае разработчик должен контролировать заявленный префикс, в противном случае результирующая обработка XML не будет осуществлена. Но когда разработчики действительно полностью управляют собственными декларациями пространств имен, то результат часто оказывается непредсказуемым из-за сложности пространств имен XML.

Одни из способов корректировки синтаксиса пространств имен, который может нарушиться в процессе обработки XML, — это вставка так называемого канонического шага (canonicalization step), т.е. шага, независимого от конечной реализации, в конце обработки. Канонизация XML исключает ту синтаксическую вариабельность, которая разрешается XML 1.0 и пространствами имен XML, в том числе различные особенности деклараций пространств имен. Но при этом следует учесть, что канонизация не может исключить абсолютно всех проблем, которые делают декларации пространств имен ненадежными для разработчиков. Канонизация не помогает в решении вопросов, связанных с QNames в контекстных проблемах, поскольку она не меняет префиксы, используемые в документе. Но она все же существенно сокращает беспорядок деклараций пространств имен — до такой степени, когда разработчик может с лёгкостью распознать проблемы или даже написать программу для их автоматического устранения. Библиотека GenX автоматически генерирует канонический документ XML, многие другие комплекты инструментов предоставляют возможности канонизации как опцию.

По мнению автора, совет Хенри Сивонена относительно недопустимости включения пробелов структурной распечатки программы в символьные данные является несколько натянутым. По мнению Хенри Сивонена, если документ XML представлен в виде, показанном в листинге 1, то, как правило, представление его в виде, показном в листинге 2, не является безопасным.

Листинг 1. Пример XML
bar

Листинг 2. Пример XML с пробелами, добавленными к символьным данным

bar

Но если структурно распечатать документ XML, представленный в листинге 3, то эта операция будет безопасной (листинг 4).

Листинг 3. Еще один пример XML
bar

Листинг 4. Пример XML из листинга 3 с пробелами, добавленными к символьным данным

bar

Многие инструменты сериализации распознают эту разницу между сравнительно безопасной и относительно небезопасной структурной распечаткой. Важно понимать, что формы структурных распечаток, показанные в листингах 3 и 4, могут вызывать искажения, если пробелы добавлены к смешанному содержанию. Этих проблем можно легко избежать, если преобразование будет управляться схемой. Но на практике большинство словарей, использующих смешанное содержание, не столь чувствительны к нормализации пробелов, поэтому не стоит уделять много внимания структурной распечатке. Просто необходимо помнить об этой потенциальной проблеме и быть уверенным, что существует возможность отключения структурной распечатки (предпочтительно, чтобы эта опция по умолчанию была отключена). Хенри Сивонен рекомендует тип структурной распечатки, представленный в листинге 5, но автор настоящей статьи не согласен с ним, поскольку такая разметка выгляди плохо и неудобна для работы.

Листинг 5. Структурная распечатка, предложенная Хенри Сивоненом, но не поддерживаемая автором настоящей статьи

>bar
>

Еще несколько советов тем, кто работает с XML

XML устроен относительно просто, поэтому использование его для работы со слишком сложными структурами не является оптимальным. Этим проблемам посвящен достаточно подробный материал Симона Сенлорена (Simon St. Laurent) «»Монастырский« XML» (Monastic XML) (см. раздел Ресурсы). Автор этого материала обсуждает фундаментальную роль символьных данных и разметки (элементов и атрибутов). Кроме того, он объясняет, почему родовой идентификатор (generic identifier), также называемый именем типа элемента, является важной концепцией и каким образом он может быть сделан единственным основным ключевым элементом структуры размеченной информации. В реальности при использовании пространств имен XML основным ключевым элементом является универсальное имя (пространство имени URI плюс локальное имя). Такая сложность — это одна из причин, по которой Сенлорен призывает к осторожности в использовании пространств имен. Еще одна проблема XML — это работа с деревьями. Хотя с первого взгляда кажется, что иерархическая структура XML может быть легко распространена на графические структуры, на практике моделирование графов в XML оказывается непростым делом. Наконец, еще один важный совет относится к области оптимизации разметки для обработки документов XML. XML — это декларативная технология, и данный факт составляет как его главную силу, так и источник разочарований для многих разработчиков. Те разработчики, кто старается слишком приблизить дизайн XML к деталям обработки, в конечном итоге обнаруживают, что обработка становится более сложной. Ключ к успешной работе с XML — это обращение основного внимания на сущность информации, которая должна быть представлена в абстрактном виде. При этом необходимо дистанцироваться от технического дизайна систем, которые будут заниматься обработкой этой информации.

Заключение

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