Десять правил XML, которые нужно знать

Как правильно использовать XML

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

Джек Д Херрингтон, главный инженер-программист, Leverage Software Inc.

Джек Д. Херрингтон (Jack D. Herrington) - главный инженер-программист с более чем двадцатилетним опытом работы. Он автор трех книг: "Генерирование кода в действии", "Podcasting Hacks" и "PHP Hacks". Написал более 30 статей. Вы можете связаться с Джеком по адресу jherr@pobox.com.



26.03.2012

XML как инструментальное средство

Часто используемые сокращения

  • CDATA: Character Data (символьные данные)
  • DOM: Document Object Model (объектная модель документа)
  • E4X: ECMAScript for XML (ECMAScript для XML)
  • IDE: Integrated Development Environment (интегрированная среда разработки)
  • W3C: World Wide Web Consortium (консорциум WWW)
  • XML: Extensible Markup Language (расширяемый язык разметки)
  • XSLT: Extensible Stylesheet Language Transformations (расширяемый язык преобразований таблиц стилей)

В настоящее время XML воспринимается как нечто само собой разумеющееся. Он повсюду! Но если посмотреть со стороны, то можно увидеть, что это мощная технология. Есть интегрированные среды разработки, которые помогают строить XML-деревья. Есть целый ряд технологий проверки корректности XML-кода. Есть XSLT – специальный язык преобразования XML. Поддержка XML встроена даже непосредственно в синтаксис некоторых языков (как, например, E4X в ActionScript).

Но у XML есть и обратная сторона. Его можно использовать неправильно. Его можно использовать плохо. Он может быть чрезмерно сложным. Он может быть недоопределенным. С ним может быть трудно работать. Что нужно сделать для более эффективного использования этой мощной технологии? В своей статье я дам 10 советов, которые помогут ответить на этот вопрос.


Не используйте XML в качестве имени файла или корневого тега

Много раз я видел XML-код, хранящийся в файлах с расширением .xml. Это бессмысленно. Такое расширение не скажет мне ничего, чего бы я не знал, просто выполнив команду cat. Как только я увижу теги, я сразу пойму, что это XML. Вместо этого расширения используйте расширение, имеющее смысл для пользователя. Также можно использовать уникальное расширение, чтобы при поиске Google возвращал ссылки на документацию или на примеры вашего формата XML-файла.

Еще одной проблемой в некоторых XML-документах является использование корневого тега <xml>. Это опять-таки ни о чем не говорит. Что находится в этом файле? Если это список контактов, корневым узлом должен быть тег <contacts>. XML должен быть читабельным, поэтому используйте имена тегов и атрибутов, имеющие отношение к бизнес-задаче, над которой работаете. Если корневым узлом является <contacts>, я предполагаю увидеть теги <contact>, а затем теги <name>, <first>, <middle>, <last> и т.д.


Не переопределяйте обобщенные или специфичные для языка конструкции

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

Этим я хочу сказать, что специфичные для языка конструкции нужно хранить вне XML. Как часто вы встречали <data type="NSDate">07-18-2010</data>? Что такое NSDate? Ага, это имя класса для работы с датами на прикладной платформе. Что произойдет при смене платформы или языка? Потребуется преобразование тегов NSDate во что-то другое, что используется на новой платформе.

Храните специфику языка вне XML и используйте простые теги, скажем <date>...<date>. Такой тег легко понимаем, читабелен и не зависит от конкретного языка или интегрированной среды.

Еще одно важное правило – избегайте использования в XML излишних обобщений. Взгляните на следующий пример (листинг 1):

Листинг 1. Обобщенное дерево узлов
<nodes>
    <node type="user">
        <node type="first">jack</node>
    </node>
</nodes>

Что это означает? Я понял, что это список пользователей. Но человеку трудно это читать и редактировать. Еще хуже то, что этот XML-код очень трудно использовать в средствах, подобных XSLT, или проверять его корректность при помощи схемы. В листинге 2 показано, что на самом деле означает приведенный выше XML-код.

Листинг 2. Более эффективное дерево узлов
<users>
    <user>
        <first>jack</first>
    </user>
</users>

Разве так не лучше? Код говорит то, что означает, и означает то, что говорит. Его легче читать и анализировать. Его легче проверять и преобразовывать при помощи XSLT. Он даже меньше по размеру.


Не делайте файлы слишком большими

Знаю, что вы скажете: "Дисковая память стоит дешево. За десять центов я куплю еще один терабайт". Это верно. Вы действительно можете создавать гигабайтные XML-файлы. Но программирование – это постоянные компромиссы. Приходится менять дисковое пространство на время или память на время. А при работе с огромным XML-файлом вы получаете худшие стороны и того, и другого. Файл занимает много места на диске, а на его анализ и проверку уходит много времени. Кроме того, большой файл исключает использование DOM-анализатора, поскольку построение дерева требует бесконечного времени и огромного количества памяти.

Какова же альтернатива? Можно создать несколько файлов. Один выступает в качестве индекса, а другие содержат большие ресурсы, которые, возможно, будут нужны не всем пользователям этого XML. Другой вариант– вынос всех больших фрагментов CDATA из XML-файла и помещение их в свои собственные файлы с собственными форматами. Если вы хотите хранить все данные вместе, запакуйте все файлы в новый файл с новым расширением. Любой популярный язык программирования имеет модули, облегчающие быструю упаковку и распаковку файлов.


Не используйте пространства имен, если в этом нет острой необходимости

Пространства имен (namespace) – это мощная составляющая XML-лексикона. Они облегчают реализацию расширяемых форматов файлов. Вы можете определить базовый набор тегов для всех потребностей вашего приложения, а затем разрешить пользователям добавлять свои собственные данные в свое собственное пространство имен в файле, не затрагивая ваше дерево объектов.

Однако пространства имен очень затрудняют синтаксический анализ и управление данными. Они сбивают с толку расширения языков программирования, такие как E4X. Они затрудняют использование XML в XSLT. Наконец, они делают XML-файлы намного более трудными для чтения.

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


Не используйте специальные символы

Все мои советы направлены на поддержание чистоты, простоты и легкости восприятия вашего XML-кода. В этом смысле даже спецификация XML позволяет многое, что совсем необязательно использовать. Например, в названиях элементов и атрибутов можно использовать тире. Но это очень затрудняет использование такого XML-кода в расширениях языка, например в E4X. Вопрос в том, стоит ли?

Я рекомендую избегать использования любых специальных символов в названиях элементов и атрибутов.


Используйте XML Schema

Синтаксический анализ XML является непростой задачей. Для точного анализа необходимо проделать большую работу по защите кода от возможного отсутствия и некорректного использования тегов или атрибутов. Это дополнительная работа по написанию кода, дополнительная сложность, а также затенение реальной бизнес-логики, являющейся вашей главной заботой. Как избежать этого? Проверяйте XML перед его использованием. Для этого можно использовать несколько стандартов. Можно указать Document Type Definition (DTD) или XML Schema (ссылки на информацию о DTD и XML Schema приведены в разделе Ресурсы). Лично я нахожу XML Schema намного более простой в работе, но если вы новичок в этом деле, попробуйте различные системы проверки корректности.

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


Нумеруйте версии

Очень легко упустить из виду тот факт, что XML, хранящийся в файлах, эквивалентен формату файла. Первое, что должен содержать файл любого формата, – это номер версии. Его достаточно легко добавить: <customers version="1">...</customers>. Код, выполняющий чтение файла, должен проверить, что номер версии не больше его текущей версии, и сгенерировать исключительную ситуацию, если это не так. Это гарантирует, что любые последующие версии кода не будут конфликтовать с более старыми версиями при использовании новых тегов. Конечно же, вы должны обеспечить поддержку всех старых версий файлов при дальнейшей разработке своего приложения.


Сочетайте узлы и атрибуты

Инженеры довольно ленивый народ. Я могу это утверждать, поскольку сам такой. Не спорьте, все мы такие. Если интегрированная среда разработки предложит выполнить экспорт XML вместо нас, мы наверняка согласимся. Но обычно интегрированная среда создает очень плохой XML-код. Вероятно, вы уже встречались с чем-то похожим на листинг 3:

Листинг 3. Список пользователей
<users>
    <user>
        <id>1</id>
        <first>jack</first>
    </user>
</users>

Должен ли <id> быть тегом? Я утверждаю, что он должен быть атрибутом. Код становится более коротким и осмысленным, появляется возможность искать пользователя по идентификатору при помощи простого XPath-выражения (/users/user[@id=1]).

Чтобы код был читабелен, несомненно лучше использовать атрибуты, как показано в листинге 4.

Листинг 4. Более удобный список пользователей
<users>
    <user id="1">
        <first>jack</first>
    </user>
</users>

Понятно, что интегрированная среда сгенерировала листинг 3, потому что всегда безопаснее использовать узлы. Но атрибуты позволяют идентифицировать важные элементы в DOM-дереве, поэтому следует использовать их.


Используйте CDATA, но не злоупотребляйте этим

XML налагает множество ограничений на использование определенных символов: кавычек, амперсандов, знаков "меньше" и "больше" и т.д. Однако на практике эти символы используются очень часто. Поэтому приходится либо преобразовывать все в безопасный для XML формат, либо помещать большие фрагменты текста, кода или еще чего-нибудь в блоки CDATA. Мне кажется, что разработчики избегают использования CDATA, поскольку думают, что это затруднит синтаксический анализ. Но разделы CDATA анализировать не труднее, чем что-либо другое – большинство DOM-анализаторов обрабатывает их самостоятельно, поэтому вам даже не нужно думать об этом.

Еще одной важной причиной использования CDATA является сохранение точного форматирования данных. Например, при экспорте Wiki-страницы вы наверняка захотите в точности сохранить позиции таких символов как возврат каретки и перевод строки, поскольку они играют особую роль в Wiki-формате.

Почему же не использовать разделы CDATA постоянно? Потому что они очень затрудняют чтение документа. Это особенно неприятно, когда в них нет необходимости. Итак, используйте их и поощряйте их использование пользователями ваших XML-файлов в тех ситуациях, когда данные, по вашему мнению, будут содержать специальные символы и когда нужно сохранить первоначальное форматирование. Но не используйте CDATA в прочих ситуациях.


Храните необязательные данные в отдельной области

До сих пор я рассказывал об XML-документах с жестким форматом. Я даже рекомендовал использовать технологию проверки корректности, (например, XML Schema), гарантирующую жесткую структуру. Тому есть веская причина: структурированные данные легче анализировать. А если нужна определенная гибкость? Я рекомендую размещать необязательные данные в отдельном блоке в своем собственном узле. Взгляните, например, на листинг 5.

Листинг 5. Неупорядоченная запись о пользователе
<users>
    <user id="1">
        <first>jack</first>
        <middle>d</middle>
        <last>herrington</last>
        <runningpace>8:00</runningpace>
    </user>
</users>

Эта запись содержит все ожидаемые данные о пользователе. Я согласен с first, middle, last, но зачем здесь runningpace? Это необходимо? Будете ли у вас много таких полей? Будут ли они расширяемыми? Если ответ на все эти вопросы утвердителен, я порекомендовал бы сделать так (см. листинг 6):

Листинг 6. Хорошо структурированная запись о пользователе
<users>
    <user id="1">
        <first>jack</first>
        <middle>d</middle>
        <last>herrington</last>
        <userdata>
        <field name="runningpace">8:00</field>
        </userdata>
    </user>
</users>

При таком подходе вы можете иметь сколько угодно полей, не загромождая пространство имен родительского элемента <user>. Вы даже можете проверить корректность этого документа, а также обратиться к определенному полю при помощи XPath-выражения (//user/userdata/field[@name='runningpace').


Заключение

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

Ресурсы

Научиться

  • Оригинал статьи: Five XML dos and five don'ts that you need to know (EN).
  • Эксперты по языку скорее всего захотят познакомиться со спецификацией W3C XML Specification. Станьте экспертом по языку и узнайте подробнее об XML - простом, очень гибком текстовом формате, предназначенном для публикации электронных документов и играющем важную роль в обмене данными в Web и повсюду.
  • Document Type Definition (DTD) в Википедии: информация о DTD - наборе объявлений разметки, определяющих тип документа для семейства языков разметки SGML (SGML, XML, HTML).
  • XML Schema в Википедии: краткое описание типа XML-документа, ограничивающееся структурой и содержимым документов данного типа.
  • Спецификация W3C XSLT: информация о замечательном способе преобразования XML в разнообразные форматы.
  • Спецификация W3C XPath: очень полезное средство, которое можно использовать для быстрого и удобного поиска узлов даже в самом сложном XML-документе.
  • Расширение E4X для Actionscript (ECMAScript): отличный способ интегрировать XML непосредственно в логику вашего приложения. Это расширение настолько полезно, что де-факто становится открытым стандартом хранения в языке (Википедия).
  • Другие статьи данного автора (Джек Херрингтон (Jack Herrington), developerWorks, с марта 2005 года по настоящее время): статьи об Ajax, JSON, PHP, XML и других технологиях.
  • Сертификация IBM по XML: информация о получении сертификата IBM-Certified Developer по XML и смежным технологиям.

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

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=XML
ArticleID=806892
ArticleTitle=Десять правил XML, которые нужно знать
publish-date=03262012