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