> Вкусовщина чистой воды, имхо. Для хранния произвольных данных ничто не лучше, всё
> имеет свои сферы применения.Угу. Для XML такой сферой является разметка текста. Не конфига.
>А с XML удобно работать с помощью XQuery.
На самом деле не удобно. XML и библиотеки к нему мне всегда напоминали Java тем насколько там всё погрязло в оверинжиниринге. Я хочу взять и сделать что-то типа:
Config cfg = read_cfg("~/.my-config");
Theme theme = cfg.get("app").get("theme").or(DEFAULT_THEME);
Что-то типа, не обязательно именно так. Можно скажем так:
Theme theme = cfg.get("app/theme").or(DEFAULT_THEME).
Или
theme_t theme = json_get(cfg, "app.theme") || DEFAULT_THEME;
Или даже
(defparameter *theme* +default-theme+)
(unwind-protect
(eval (read "~/.my-config"))
(msg "There is an error in your config, so if you see something weird, try to fix it in the config"))
Как нибудь так, без всей вот этой хрени, с именами функций по 50 символов, которые принимают не меньше пяти аргументов, половина которых задаёт режим работы функции, от чего начинаешь задаваться вопросом: нахрена было 50 символов в имя пихать, чтобы потом уточнять ещё режим работы функции аргументами? И при этом, одной функции всегда будет мало, надо будет сделать по три вызова на каждый запрос. Ах да, ещё и парсинг xml радостно и необратимо обломается, при малейшей ошибке или несоответствии dtd.
XQuery крайне неудобен без обёртки над ним. Это корпоративная хрень для разработки корпоративных аппликух на Java, которые радуют глаз эффективного менагера. Даже в javascript никто не использует XQuery, предпочитая всякие обёртки над ним, css-селекторы и проч.
Это с точки зрения API. С точки зрения пользователя xml-конфига всё не сильно лучше: объём полезной информации в конфиге минимален, потому что по большей части там сплошные угловые скобки, слеши, многократные повторы имён тегов... То есть захламлено всё так, что дальше некуда. Это мутное разделение на атрибуты и контент тега -- зачем делать и так и эдак? Никто до конца не понимает, потому у каждого своё понимание, что пихать в атрибут, что в контент: атрибут вроде удобнее, он меньше писанины требует, но нет ведь у всех какие-то глубинные идеи, типа one-to-one отношение, или one-to-many, и "может быть когда-нибудь понадобится one-to-many, поэтому давайте пользователи прямо сейчас начнут страдать от ещё одного вложенного тега в конфиге вместо няшного атрибута, а если one-to-many не понадобится никогда и страдания будут бесцельными, то нам покакать на них".
