Полезные советы для работы с 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 - пересылка событий 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
>

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

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

Заключение

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

Ресурсы

Образовательные

1. Статьи в Интернете, обсуждаемые в этом материале:
   • Хенри Сивонен (Henri Sivonen). Как избежать обвинений в некомпетентности при работе с XML (HOWTO Avoid Being Called a Bozo When Producing XML);
   • Симон Сенлорен (Simon St. Laurent). 'Монастырский' XML (Monastic XML).
2. Основные черты сущности XML:
   • Принципы дизайна XML (Design Principles for XML);
   • Юч Огбуджи (Uche Ogbuji). Нет оправданий для игнорирования i18n в XML (Once again: no excuses to ignore i18n in XML);
   • Аннотированная спецификация XML (The Annotated XML Specification).
3. Опасности создания документов XML с помощью неосторожного печатания текстов:
   • Юч Огбуджи (Uche Ogbuji). Корректные результаты использования XML в языке Python (Proper XML Output in Python).
     Детали работы с Python и Unicode:
   • Юч Огбуджи (Uche Ogbuji). Проблемы с формами хранения Python для Unicode (Confusion over Python storage form for Unicode).
4. Юч Огбуджи (Uche Ogbuji). Введение в канонические формы XML (Introducing XML canonical form).
5. Ресурсы, связанные с XML, на сайте developerWorks:
   • прошлые статьи рубрики Thinking XML;
   • Эффективный XML (Harold's Effective XML);
   • Разбор секретов XML (Hacking XML Hacks).
6. Юч Огбуджи (Uche Ogbuji). Принципы дизайна XML (Principles of XML design).
7. Информация о том, как стать Сертифицированным разработчиком IBM в области XML и других смежных технологий (IBM Certified Developer in XML and related technologies).
8. Книги по данной и другим техническим тематикам.

Продукты и технологии

Тестовая версия программных средств IBM.

Дискуссии

1. Дискуссионный форум.
2. Блоги developerWorks.

Об авторе

Юч Огбуджи (Uche Ogbuji) - консультант и один из создателей компании Fourthought, Inc., - поставщика программных средств и консалтера, специализирующегося на решениях XML для корпоративного управления знанием (enterprise knowledge management). Компания разрабатывает платформу 4Suite. Это платформа с открытым кодом для приложений XML, RDF и управления знанием. Юч Огбуджи также является ведущим разработчиком языка запросов Versa для RDF. Юч Огбуджи - компьютерный инженер и писатель, он родился в Нигерии, а сейчас живет и работает в г. Боулдер (Boulder) штата Колорадо (Colorado), США. Более подробную информацию о нем можно найти на его web-логе Copia, его электронный адрес - uche.ogbuji@fourthought.com.

---

¹(обратно к тексту)     SAX - это простой интерфейс прикладного программирования для XML (Simple API for XML). Дополнительную информацию можно найти на сайте http://www.saxproject.org/ (на английском). (прим. переводчика).