Заметка об XML, или "А Баба-Яга - против!"

Священная война вокруг xml поутихла и пришло время, когда можно здраво разобраться, что же нам этот самый xml принес. Многие приложения в эпоху бума перешли на использование xml, даже скорее не просто перешли, а перепрыгнули, поскольку процесс перехода был революционным. В отличие от априорных спекуляций мы рассмотрим, где же сегодня на практике используется xml и нужен ли он там. Можно выделить следующие широко распространенные области применения:

• Конфигурационные файлы


Фактически, это замена юниксовым plain-text конфигурационным файлам и виндовым ini-файлам. Кроссплатформенный пример - VirtualBox. Можно придумать много резонов делать именно так, но на практике ясно одно - более неудобную реализацию еще поискать. Руками править плохо, делать скрипт для правки сложно (ага, есть некоторые утилиты, облегчающие жизнь, но с plain-text все намного проще). И самое плохое - разработчики, использующие xml для конфигов, для своего удобства и во избежание лишних затрат на парсинг xml дублируют информацию в разных файлах! Например, в VirtualBox при переносе виртуалки между хостами приходится править как основной конфиг, так и конфиги отдельных виртуальных машин. Как итог - явно провальная затея, лучше было бы вернуться к plain-text.


• Обменный формат для _разных_ приложений


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


• Обменный формат в рамках одного приложения


Основная область, разумеется, веб - производительностью обычно пренебрегают (иногда вполне разумно, но чаще - наоборот), и здесь очень распространены "модные" технологии. Здесь мы видим, что на стороне сервера xml генерить накладно, передавать приходится чрезмерный объем данных, на стороне клиента (браузер) разбирать ресурсоемко и долго... В качестве аргументов "за" называют наличие множества библиотек, упрощающих создание xml (разумеется, библиотеки перегружены и намного увеличивают накладные расходы, но об этом редко вспоминают), удобство отладки (скорее, стоит говорить о возможности отладки, а не об удобстве, т.к. "глазами" увидеть ошибку в xml затруднительно), и некое малопонятное "удобство использования" (под которым обычно подразумевают возможность запихнуть вместо xml большой кусок xhtml). Безусловно, не обходится и без ссылок на "авторитеты" (это проблема Рунета в целом), причем опять-таки обсуждается не целесообразность, а лишь возможность применения. Впрочем, в настоящее время заметен эволюционный переход на формат JSON, который решает многие из названных проблем. Разве что пока не хватает средств CSS непосредственно для JSON, без необходимости преобразовывать JSON в элементы документа, такое развитие было бы вполне закономерным.


• Формат документов


Безусловно, лучше, чем бинарный формат, но автоматизированная обработка документов (например, индексация для поиска) чрезвычайно затратна и требует специализированных парсеров для каждого формата. В очередной раз сталкиваемся с проблемой смешения содержания и представления. Вероятно, намного более выгодной будет реализация на основе встраиваемой СУБД (например, стиль оформления в БД может храниться в отдельной таблице и иметь ключ, указывающий на форматируемый элемент, а сам элемент содержания не иметь никакой привязки к оформлению). Представляется небесполезным обратить внимание на то, что при генерации документов на основе некоторой БД (которая заполняется через веб-формы или на основе автоматизированной обработки различных массивов информации) вся затея с xml-форматом документов начинает "дурно пахнуть" - формализованный набор данных превращается в слабо формализованный и смешанный с элементами оформления (xml), а при необходимости дальнейшей (автоматизированной) обработки с большими усилиями снова преобразуется в формализованное представление! Тем не менее, существует одно веское "но" - xml удобнее для представления иерархических данных. Именно последнее соображение и приводит к xml-форматам для сложных документов. Можно предположить, что развитие средств рекурсивного SQL во встаиваемых СУБД способно решить указанную проблему.


• Формат хранения


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

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