XML must die
Эту статью стоило / можно было написать ещё 10/15 лет назад, когда XML был в большей степени на хайпе, чем сейчас. Сейчас, к счастью, его постепенно вытесняют другие текстовые форматы, более удобные в использовании. Но лучше написать поздно, чем никогда.
Любовь
XML, который мы так любим, был придуман ещё в конце 1990-х на фоне совершенно заслуженного успеха HTML. А в начале / середине 2000-х начался настоящий хайп вокруг этого формата — были выпущены десятки книг, написаны сотни восторженных статей. XML-евангелисты прочили ему захват мира; казалось, ещё немного — и вообще всё, что мы можем себе представить и помыслить в цифровом мире (ну разве что кроме видео и картинок) будет одним сплошным XML-документом (Как в старом фильме «Ничего не будет: ни кино, ни театра, ни книг, ни газет — одно сплошное телевидение»).
Мало того, был анонсирован и даже воплощён в реальности целый набор специализированных чипов, которые были заточены именно на обработку XML (DataPower XML Accelerator, Tarari XML Content Processor, Ternary XML Accelerator, Xelerator XML Accelerator, XA35 XML Accelerator).
На базе XML был разработан целый ряд других форматов и стандартов: SOAP, WSDL, SVG, MathML и т.п., включая форматы для хранения документов и электронных таблиц: OpenDocument Format (ODF), Office Open XML (OOXML), Excel Open XML (XLSX), OpenDocument Spreadsheet (ODS), GNUMERIC и т.д., а также для записи нот: MusicXML, MEI, Sibelius, Finale, MuseScore, MIDI XML и т.п.
Глубокое знание XML со всеми XML-cхемами, зачастую, входило в список обязательных требований на вакансии программистов.
В значительной доле самых разных проектов до сих пор конфиги и прочие настройки хранятся в XML.
И ненависть:
Однако, ещё лет 20 назад, когда начинался весь этот хайп вокруг XML, мне этот формат не приглянулся и я никогда не использовал его в своих проектах ни в каком качестве (разве только вынужденно, если приходилось обращаться к чужим API, которые на основе XML).
Причин, почему он ещё тогда не приглянулся, масса, но вот лишь некоторые из них, основные:
Чудовищная избыточность
Как минимум, почти везде нужны закрывающие теги, одно только это раздувает XML-документы в 2 раза. Ну, это понятная история и лежит на поверхности, много ума не надо, чтобы это заметить.
Чтобы как-то скрыть этот «нюанс» почти все форматы для хранения документов в XML сейчас архивируются. Документы представляют из себя фактически ZIP-файл с набором XML-файлов внутри. Как говорится, «сомнительно, но окей».
Неоднозначность преобразования в/их из встроенных структур данных ЯП
В современных высокоуровневых / динамических языках программирования (на примере Python, JS, PHP, Perl, Ruby и т.п.), за редким исключением, все структуры данных представляют из себя комбинацию скаляров (переменных, хранящих одно значение какого-то атомарного типа данных), списков и словарей (ассоциативных массивов). Для хранения / обработки данных внутри ЯП в основном используются комбинации / деровидные структуры из этих структур данных. Другие более хитрые структуры данных используются редко и только когда это зачем-то действительно сильно нужно.
Так вот, не существует единственного и взаимооднозначного способа преобразования таких структур данных в/из XML. Таких способов преобразования существует бесконечное количество (счётное, но бесконечное множество вариантов), поэтому для того, чтобы гонять данные туда/сюда нужны какие-то дополнительные соглашения / схемы. Просто так задампить данные в одном месте и «раздампить» в другим без доп. соглашений — невозможно, а это дополнительная интеллектуальная работа, время, объём кода и т.п.
Это и есть моя главная претензия к XML.
Сложность в определении схемы
Этот пункт отчасти вытекает из предыдущего. Для того, чтобы как-то упорядочить хаос и из бесконечного множества способов преобразования данных из стандартных структур данных ЯП выделить один единственно правильный способ, в том числе для этого нужны XML-схемы: отдельные документы (которые сами по себе часто являются XML-документами), где описана валидная структура интересующего нас вида XML-документов. Конечно, XML-схемы решают и другие задачи, включая контроль типов данных и сами структуры даных.
Этих форматов XML-схем также существует целый зоопарк: DTD, XSD, RelaxNG, Schematron, NVDL, RELAX и т.п., каждый со своими преимуществами и недостатками / неудобствами.
Конечно, наличие и необходимость подобных схем с описаниями ограничений структур и типов данных есть не только в мире XML, существуют подобные схемы и в мире JSON (JSON Schema, JSON LD) и YAML (YAML Schema, RAML), но используются там схемы гораздо реже (в основном только при реализации API) в силу более простой структуры базовых форматов и отсутствия неоднозначности преобразования, описанного в предыдущем пункте.
Человекочитаемость?
Изначально главным поинтом в пропаганде XML на старте звучала «человекопонятность» — человек на любом этапе сможет глазками посмотреть и проанализировать документ и понять, если что-то пойдёт не так.
Что же мы видим в реальности? Правильный ответ:
И это ещё вариант «лайт» — хард было лень искать. Всё в одну строку, без единого пробела. Ну понятно — экономим место же и ускоряем обработку. В подобной ситуации XML никаким образом не получает преимуществ в человекопонятности в сравнении с альтернативами.
Сравним ЭТО, например, с YAML, где сами правила форматирования (как и в Python, например), делают просто невозможным превращение документа в нечитаемый треш:
---
person:
name: John Doe
age: 30
email: john.doe@example.com
address:
street: 123 Main St
city: Anytown
state: CA
zip: 12345
phone_numbers:
- type: home
number: 555-1234
- type: work
number: 555-5678
employment:
- company: Acme Inc.
position: Software Engineer
start_date: '2015-07-01'
end_date: '2018-12-31'
- company: XYZ Corp.
position: Senior Software Engineer
start_date: '2019-01-01'
Скажут — «ну зачем тебе эта человекопонятность, всё равно всё делают машины!».
Не соглашусь. К примеру, я активно работаю с различными форматами нотной записи и зачастую в нотах бывают ошибки, например, при конвертации между форматами или в самой программе что-то пошло не так. Или мне нужно выполнить действие с нотами, которое не поддерживается пока самой программой (просто что-то не реализовано в интерфейсе), я могу просто открыть файл и отредактировать ручками нужные мне вещи.
В случае большого документа, например, в форматах MusicXML или MuseScore, редактировать XML, где, докучи, ещё и форматирование сильно едет (поскольку о красивом выравнивании XML в файлах разработчики, по понятным причинам не беспокоятся). Так вот, если бы эти форматы были не на основе XML, а на основе, скажем, YAML — анализировать и редактировать их руками было бы В РАЗЫ (если не на порядок) легче.
«Не всё так однозначно»
Не буду заниматься крючкотворством и концентрироваться на более мелких недочётах XML, приведённых аргументов про неудобство этого формата, вполне достаточно.
Однако, на мой взгляд, у XML остаются ниши, где он может быть, по прежнему, одним из лучших выборов. В первую очередь, это RICH-text в различных его вариантах, и такие форматы как ePUB, RSS, DocBook вполне имеют право на существование. Там, где относительно много текста и относительно мало тегов / служебных данных, XML — прекрасный выбор.
Собственно XHTML (тот же HTML, но с дополнительными ограничениями, делающими его валидным XML-документом) — прекрасный пример «как надо».
Что же делать, куда бежать?
Ответ прост:
Если вам нужен человекочитаемый / чиловекописуемый конфиг — используйте YAML. Меньше избыточности, гораздо лучшая «человекопонятность», очень удобно редактировать руками.
Если вы обмениваетесь данными между приложениями / сервисами (по API или как-то ещё), ваш выбор — JSON.
Если вы храните «документы» в файлах — также можете использовать любой из этих двух форматов в зависимости от того, нужна бОльшая человекочитаемость (тогда YAML) или большая компактность (JSON).
(В обоих случаях мы имеем дело с гораздо более простыми форматами, которые, при этом, взаимооднозначным образом конвертируются в / из структур данных высокоуровневых языков программирования.)
Если вы создаёте RICH-text документы, где не нужно сверхсложное форматирование — используйте MarkDown или аналоги.
Вывод
Сейчас, к счастью для меня, XML теряет популярность в том числе по описанным мною выше причинам. Если он будет терять эту популярность ещё быстрее, в том числе благодаря этой статье — я буду счастлив.
