Хабрахабр

[Перевод] XML практически всегда применяется не по назначению

Язык XML был изобретен в 1996 году. Едва он успел появиться, как возможности его применения уже начали понимать неправильно, и для тех целей, к которым его пытались адаптировать, он был не лучшим выбором.

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

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

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

Далее я приведу несколько наиболее часто встречающихся примеров неправильно построенных схем.

<roоt> <item name="name" value="John" /> <item name="city" value="London" />
</roоt>

Здесь мы видим пример необоснованной и странной (хоть и весьма распространенной) попытки выразить языком XML простой словарь «ключ-значение». Если удалить все теги и атрибуты, останется пустая строка. По существу данный документ представляет собой, как бы абсурдно это ни звучало, семантическую аннотацию пустой строки.

<root name="John" city="London" />

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

<roоt> <item key="name">John</item> <item key="city">London</item>
</roоt>

Это уже кое-что получше, но теперь ключи по какой-то причине являются метаданными, а значения — нет. Весьма странный взгляд на словари. Если удалить все теги и атрибуты, будет потеряна половина информации.

Правильное выражение словаря в XML будет выглядеть приблизительно так:

<roоt> <item> <key>Name</key> <value>John</value> </item> <item> <key>City</key> <value>London</value> </item>
</roоt>

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

Такие файлы требуют загрузки XML-файлов запроса по TFTP, которые… В общем, вот отрывок из одного такого файла: Самая худшая схема XML? Кстати, приз за самую худшую схему XML, которую мне доводилось видеть, получает формат файла конфигурации автоматического выделения ресурсов для телефонов IP-телефонии Polycom.

<softkey softkey.feature.directories="0" softkey.feature.buddies="0" softkey.feature.forward="0" softkey.feature.meetnow="0" softkey.feature.redial="1" softkey.feature.search="1" softkey.1.enable="1" softkey.1.use.idle="1" softkey.1.label="Foo" softkey.1.insert="1" softkey.1.action="..." softkey.2.enable="1" softkey.2.use.idle="1" softkey.2.label="Bar" softkey.2.insert="2" softkey.2.action="..." />

Это не чья-то неудачная шутка. И это не моя выдумка:

  • элементы просто используются как предлог для прикрепления атрибутов, которые сами по себе имеют иерархические имена.
  • Если нужно приписать значения нескольким экземплярам записи определенного вида, для этого необходимо использовать имена атрибутов, в которых есть индексы.
  • Кроме этого, атрибуты, начинающиеся с softkey., нужно помещать на элементы <softkey/>, атрибуты, начинающиеся с feature., нужно помещать на элементы <feature/> и т. д., несмотря на то, что это выглядит совершенно излишним и на первый взгляд бессмысленным.
  • И, наконец, если вы надеялись, что первый компонент имени атрибута всегда совпадает с именем элемента — ничего подобного! Например, атрибуты up. должны прикрепляться к <userpreferences/>. Порядок прикрепления имен атрибутов к элементам — произвольный, причем практически полностью.

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

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

А в JSON порядок следования пар «ключ-значение» внутри объектов не имеет смысла и не определен. К примеру, в XML имеет значение порядок элементов. Но вы можете сформировать из этих данных много разных документов, поскольку в документе есть определенный порядок. Если вы хотите получить неупорядоченный словарь из пар «ключ-значение», фактический порядок, в котором следуют элементы в этом файле, не имеет значения. Метафорически это аналог документа на бумаге, хоть он и не имеет физических размеров в отличие от распечатки или файла PDF.

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

п.), где n — количество возможных комбинаций элементов в словаре, и это мы еще не учли другие возможные переменные. Другими словами, словарь (фрагмент структурированных данных) может быть преобразован в n различных возможных документов (в формате XML, PDF, на бумаге и т.

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

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

Да, сделать это в принципе возможно, но это не самый оптимальный путь, — разве что в крайнем случае, когда совсем нет других вариантов. Таким образом, процесс извлечения данных из документов XML не так уж сильно отличается от процесса распознавания отсканированных документов, содержащих, например, таблицы, образующие множество страниц численных данных. Разумным решением будет просто найти цифровую копию оригинальных данных, не заложенных в модель документа, в которой данные объединены с их конкретным текстовым представлением.

Причина этого именно в том, что формат документов (на бумаге) понятен и привычен для бизнеса, и там хотят продолжать пользоваться знакомой и понятной моделью. При этом меня совсем не удивляет, что XML популярен в бизнесе. Это касается даже тех документов, которые вряд ли когда-нибудь будут распечатываться (например, PDF-файл документации реестра из 8000 страниц). По той же самой причине в бизнесе слишком часто используют документы в PDF вместо более удобных для машинной обработки форматов — потому что они по-прежнему привязаны к понятию печатной страницы с определенным физическим размером. Людям понятна метафорическая идея печатной страницы ограниченного размера, и они понимают, как создавать бизнес-процессы на основе печатных документов. С этой точки зрения использование XML в бизнесе по сути — проявление скевоморфизма. Что не мешает им оставаться неверным и излишне скевоморфичным способом представления данных. Если это ваш ориентир, документы без ограниченного физического размера, являющиеся машиночитаемыми — документы XML — представляют собой инновацию, являясь при этом знакомым и комфортным аналогом документа.

На сегодняшний день единственными известными мне схемами XML, которые я действительно могу назвать правильным применением этого формата, являются XHTML и DocBook.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть