Язык 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? Кстати, приз за самую худшую схему XML, которую мне доводилось видеть, получает формат файла конфигурации автоматического выделения ресурсов для телефонов IP-телефонии Polycom. Такие файлы требуют загрузки XML-файлов запроса по TFTP, которые… В общем, вот отрывок из одного такого файла:
<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, которые чаще всего не являются машиночитаемыми.
К примеру, в XML имеет значение порядок элементов. А в JSON порядок следования пар «ключ-значение» внутри объектов не имеет смысла и не определен. Если вы хотите получить неупорядоченный словарь из пар «ключ-значение», фактический порядок, в котором следуют элементы в этом файле, не имеет значения. Но вы можете сформировать из этих данных много разных документов, поскольку в документе есть определенный порядок. Метафорически это аналог документа на бумаге, хоть он и не имеет физических размеров в отличие от распечатки или файла PDF.
В моем примере правильного представления словаря на языке XML показан порядок следования элементов в словаре, в отличие от представления на языке JSON. Я не могу игнорировать этот порядок: такая линейность изначально свойственна модели документов и формату XML. Кто-то при интерпретации этого XML-документа может решить проигнорировать порядок, но спорить по этому поводу бессмысленно, поскольку данный вопрос выходит за рамки обсуждения собственно формата. Более того, если сделать документ просматриваемым в браузере, прикрепив к нему каскадную таблицу стилей, можно будет увидеть, что элементы словаря следуют в определенном порядке, и ни в каком другом.
Другими словами, словарь (фрагмент структурированных данных) может быть преобразован в n различных возможных документов (в формате XML, PDF, на бумаге и т. п.), где n — количество возможных комбинаций элементов в словаре, и это мы еще не учли другие возможные переменные.
Вместе с тем из этого также следует, что если вы хотите передать одни только данные, то использовать для этого машиночитаемый документ будет не эффективно. В нем используется модель, которая в этом случае лишняя, она будет только мешать. К тому же, для того чтобы извлечь исходные данные, необходимо будет написать программу. Вряд ли есть смысл использовать XML для чего-то такого, что на определенном этапе будет форматироваться в виде документа (скажем, с помощью CSS или XSLT, либо и того, и другого), поскольку это главная (если не единственная) причина для того, чтобы придерживаться модели документа.
Более того, поскольку в XML нет понятия чисел (или булевых выражений, либо других типов данных), все представленные в этом формате числа считаются лишь дополнительным текстом. Для извлечения данных должна быть известна схема и ее связь с соответствующими выражаемыми данными. Также необходимо знать, когда исходя из контекста тот или иной элемент текста представляет собой число, и его следует преобразовывать в число, и т. д.
Таким образом, процесс извлечения данных из документов XML не так уж сильно отличается от процесса распознавания отсканированных документов, содержащих, например, таблицы, образующие множество страниц численных данных. Да, сделать это в принципе возможно, но это не самый оптимальный путь, — разве что в крайнем случае, когда совсем нет других вариантов. Разумным решением будет просто найти цифровую копию оригинальных данных, не заложенных в модель документа, в которой данные объединены с их конкретным текстовым представлением.
При этом меня совсем не удивляет, что XML популярен в бизнесе. Причина этого именно в том, что формат документов (на бумаге) понятен и привычен для бизнеса, и там хотят продолжать пользоваться знакомой и понятной моделью. По той же самой причине в бизнесе слишком часто используют документы в PDF вместо более удобных для машинной обработки форматов — потому что они по-прежнему привязаны к понятию печатной страницы с определенным физическим размером. Это касается даже тех документов, которые вряд ли когда-нибудь будут распечатываться (например, PDF-файл документации реестра из 8000 страниц). С этой точки зрения использование XML в бизнесе по сути — проявление скевоморфизма. Людям понятна метафорическая идея печатной страницы ограниченного размера, и они понимают, как создавать бизнес-процессы на основе печатных документов. Если это ваш ориентир, документы без ограниченного физического размера, являющиеся машиночитаемыми — документы XML — представляют собой инновацию, являясь при этом знакомым и комфортным аналогом документа. Что не мешает им оставаться неверным и излишне скевоморфичным способом представления данных.
На сегодняшний день единственными известными мне схемами XML, которые я действительно могу назвать правильным применением этого формата, являются XHTML и DocBook.
