Статьи

Преступления против XML

Интеграция является важной частью любого приложения B2B, а XML является распространенным (IMHO хорошим) способом передачи данных между системами. Как правило, одна сторона должна сделать грязную работу по интеграции. Обычно это небольшая компания, в которой по тем или иным причинам я всегда работаю. Схемы БД могут быть болезненными для изменения, но схемы XML, особенно те, которые выставлены внешне, почти невозможно изменить. В свое время , я видел схему из ада , которые сделали меня хотят рвать на себе волосы и разрушенная , что могло бы быть очень хороший днем. Вот список того, что я считаю преступлениями XML.

Отсутствие схемы XML
Всякий раз, когда вы работаете с XML, у вас всегда должна быть схема. Это
Совершенно неуместно и непрофессионально распространять XML извне и не предоставлять схему (предпочтительно XSD ). Я удивлен, как часто я вижу людей, работающих с XML без схемы . Как еще вы собираетесь документировать и проверять свой XML? Не говоря уже о завершении кода и автогенерации.

Имея элементы, содержащие только атрибуты
Атрибуты , предназначенные для описания Свойс
х годов этого элемента, в основном их метаданных [1] . Иногда люди путаются и помещают все данные в атрибуты.
например

<artist name="Arcade Fire" country="Canada" type="Band"/>

Гораздо лучший способ представить эти данные:

<artist type="band">
<name>Arcade Fire</name>
<country>Canada</country>
</artist>

Почему это лучше? Во — первых , это « S так , как это было задумано, во- вторых, » s легче разобрать, и , наконец,s более расширяемой. Ключевым компонентом взаимодействия является согласованность: одни значения в атрибутах, а другие в элементах нарушают это правило.

Неправильная кодировка символов.
Кажется, что большинство разработчиков не понимают, что такое кодировка символов . Если у вас нет
очень веской причины, все XML должны быть закодированы как UTF-8 . Вы всегда должны добавлять декларацию XML вверху ваших документов.
например

<?XML version="1.0" encoding="UTF-8" ?> 

К лучшему или худшему, символы ASCII обычно имеют одинаковые кодовые точки в обычно используемых схемах кодирования. Это означает, что проблемы с кодированием обычно не возникают, пока система не заработает; обычно «` «является виновником на платформах Window. То, что у вас нет иностранных / странных персонажей или вы просто не заботитесь об интернационализации, не означает, что вы амнистированы за это преступление.

Еще один момент, который важно отметить, заключается в том, что добавление encoding = UTF-8 не означает, что оно закодировано как UTF-8. По умолчанию Java создает текстовые файлы в схеме кодирования вашей ОС ( 1251 в Windows), и Java не является единственным соучастником этого преступления.

Элементы, содержащие разделенные поля.
Лучше всего описать на примере:

<artist>
<name>Arcade Fire</name>
<members>Win Butler, Régine Chassagne, Richard Reed Parry, William Butler, Tim Kingsbury, Sarah Neufeld, Jeremy Gara</members>
</artist>

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

<artist>
<name>Arcade Fire</name>
<members>
<member>Win Butler</member>
<member>Régine Chassagne</member>
<member>Richard Reed Parry</member>
<member>William Butler</member>
<member>Tim Kingsbury</member>
<member>Sarah Neufeld</member>
<member>Jeremy Gara</member>
</members>
</artist>

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

Не упаковка повторяющихся элементов,
например

<artist>
<name>Arcade Fire</name>
<member>Win Butler</member>
<member>Régine Chassagne</member>
<member>Richard Reed Parry</member>
<member>William Butler</member>
<member>Tim Kingsbury</member>
<member>Sarah Neufeld</member>
<member>Jeremy Gara</member>
<album>Funeral</album>
<album>Neon Bible</album>
</artist>

Еще раз кошмар, чтобы разобрать, и это не совсем человекочитаемый. XML в этой структуре также приведет к неоднозначной схеме, которая, в свою очередь, разорится с генераторами авто-кода (например, JAXB ). Это намного лучше:

<artist>
<name>Arcade Fire</name>
<members>
<member>Win Butler</member>
<member>Régine Chassagne</member>
<member>Richard Reed Parry</member>
<member>William Butler</member>
<member>Tim Kingsbury</member>
<member>Sarah Neufeld</member>
<member>Jeremy Gara</member>
</members>
<albums>
<album>Funeral</album>
<album>Neon Bible</album>
</album>
</artist>

Повторение имен элементов в разных контекстах
Согласованность — это то, к чему все разработчики должны стремиться каждый день, а в чем-то столь же самодостаточном, как схема XML, это действительно не должно быть так сложно. Одно место XML-схем часто падает в именах, которые выбраны для атрибутов и элементов. В приведенном ниже примере элемент с именем «artist» появляется в двух местах, каждое из которых имеет свое значение и структуру.
например

<album>
<artist>
<name>Arcade Fire</name>
<members>
<member>Win Butler</member>
<member>Régine Chassagne</member>
<member>Richard Reed Parry</member>
<member>William Butler</member>
<member>Tim Kingsbury</member>
<member>Sarah Neufeld</member>
<member>Jeremy Gara</member>
</members>
</artist>
<track>
<name>Intervention</name>
<artist>Arcade Fire</artist>
</track>
</album>

Лучшая структура будет

<album>
<artist>
<name>Arcade Fire</name>
<members>
<member>Win Butler</member>
<member>Régine Chassagne</member>
<member>Richard Reed Parry</member>
<member>William Butler</member>
<member>Tim Kingsbury</member>
<member>Sarah Neufeld</member>
<member>Jeremy Gara</member>
</members>
</artist>
<track>
<name>Intervention</name>
<track-artist>Arcade Fire</track-artist>
</track>
</album>

Логическая и согласованная компоновка всегда делает синтаксический анализатор проще, а XML — более легким для чтения. Противоположность этому преступлению так же плоха, этот вариант подразумевает не использование одного и того же имени элемента / атрибута для полей, которые явно совпадают. Например, элементы «name» и «track-name» в приведенном ниже примере.

 <album>
<artist>
<name>Arcade Fire</name>
</artist>
<track>
<track-name>Intervention</track-name>
</track>
</album>

Гораздо более логичная структура — использовать один и тот же элемент «name» в обоих местах.

 <album>
<artist>
<name>Arcade Fire</name>
</artist>
<track>
<name>Intervention</name>
</track>
</album>

Сокращение имен элементов / атрибутов
Да XML очень многословен, и файлы могут стать очень большими, но сокращение имен элементов или атрибутов для экономии места не является хорошей идеей.

<a>
<n>Arcade Fire</n>
</a>

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

Поиск значения ключа
Худшая XML-схема, которую я когда-либо видел. Я думаю, что пример достаточно описания

<root>
<entry>
<key>Artist</key>
<value>Arcade Fire</value>
</entry>
<entry>
<key>Country</key>
<value>Canada</value>
</entry>
</root>

Это действительно бросает вызов всему, что представляет XML, вы можете просто иметь простой текстовый файл.

Вывод

При разработке схемы XML придерживаются следующих двух правил:

  1. Убедитесь, что XML является машиночитаемым
  2. Убедитесь, что XML читается человеком

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