Как не выглядеть некомпетентным в области 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 - пересылка событий SAX с использованием для этого дерева, стека или парсера 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
<foo>bar</foo>
Листинг 2. Пример XML с пробелами, добавленными к символьным данным
<foo> bar </foo>
Но если структурно распечатать документ XML, представленный в листинге 3, то эта операция будет безопасной (листинг 4).
Листинг 3. Еще один пример XML
<doc><foo>bar</foo></doc>
Листинг 4. Пример XML из листинга 3 с пробелами, добавленными к символьным данным
<doc> <foo>bar</foo> </doc>
Многие инструменты сериализации распознают эту разницу между сравнительно безопасной и относительно небезопасной структурной распечаткой. Важно понимать, что формы структурных распечаток, показанные в листингах 3 и 4, могут вызывать искажения, если пробелы добавлены к смешанному содержанию. Этих проблем можно избежать, если преобразование будет управляться схемой. Но на практике большинство словарей, использующих смешанное содержание, не столь чувствительны к нормализации пробелов, поэтому не стоит уделять много внимания структурной распечатке. Просто необходимо помнить об этой потенциальной проблеме и быть уверенным, что существует возможность отключения структурной распечатки (предпочтительно, чтобы эта опция по умолчанию была отключена). Хенри Сивонен рекомендует тип структурной распечатки, представленный в листинге 5, но автор настоящей статьи не согласен с ним, поскольку такая разметка выгляди плохо и неудобна для работы.
Листинг 5. Структурная распечатка, предложенная Хенри Сивоненом, но не поддерживаемая автором настоящей статьи
<foo >bar</foo >
