I know that the lack of comments makes some people sad, but it shouldn't.
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
Не драматизируй. Если уж так нужно описание на каждый чихкаждое поле, то юзай доп. поля для описаний/хак-методы/etc. Али пару лишних байтов пожалел? Ну и всегда есть json-scheme/любой лишний парсер/etc для особо поехавших. Я лично не жалею байтики, поэтому использую просто доп. поля.
Ну и для совсем мазахистовэкстремалов - конфигурируйте сразу уж скриптами, че уж.
Никакой. О XML можно даже не заикаться, ублюдство не годящееся вообще никуда, JSON убог ненужными кавычками и отсутствием комментариев, YAML слишком навороченный.
Самое удобное для сильно структурированного конфига - как у nginx или irssi либо key-value, но намного лучше когда структурированный конфиг не требуется - тогда что-то ini-подобное.
Сказки, сотни приложений постарше тебя живут с key=value конфигами. Кроме того, структурированный nginx/irssi-подобный формат делается из key=value сохраняя прямую совместимость тривиальным образом.
если ты решишь использовать протокол, который передаёт в xml\json много данных, ты без проверки схемы эти данные читать будешь? обмажешься эксепшенами?
для перечисленных «языков» товарищи из altova сделали нормальную экосистему.
а конфиги? как это прочитать и быть уверенным что порт не равен нулю или хост - это ipv4 без схемы?
Сказки, сотни приложений постарше тебя живут с key=value конфигами. Кроме того, структурированный nginx/irssi-подобный формат делается из key=value сохраняя прямую совместимость тривиальным образом.
как это прочитать и быть уверенным что порт не равен нулю или хост - это ipv4 без схемы?
Конкретно человеку не надо быть уверенным. А программа может и проверить. Таким образом можно сделать конфигурацию на чем угодно и она не будет зависеть от схемы. И да, это не так уж и сложно.
На Луа же. PS. Что здесь делают пункты 2 и 3, если у нас не обмен машина-машина и зачем кому-то выше понадобилась схема для чтения своего же собственного конфига не понятно. 1 не встречал ни разу, глубокого залегания похоже.
при всей своей кажущейся простоте очень сложен для написания, особенно при наличии вложенных структур.
Это как? Не запомнить что `:` для хешей а `-` для массивов :) ?
Самое рисковое в ямле - кавычки пропускать, если не знаешь особенностей. Остальное терпимо вроде.
TOML (ini-like)
TOML - это полный звиздец, взлетевший исключительно благодаря личности автора. Глядя на YAML и общаясь с его авторами я вижу, что он overengineered т.к. в него пытались заложить слишком много интересных идей. Глядя на TOML - я вижу что автор вообще ни хера не в курсе синтаксисов и слепил наболевшее по наитию.
Френд, для валидации есть json-schema. Не вали в кучу разные сущности. XML это конечно круто, и иногда даже нужно, но для многих типовых задач - абсолютно избыточно и не практично.
Использовал все 3. Если человеку надо читать/модифицировать, xml. json совсем уж не для конфигов. В yaml вникать надо, поскольку не особо он распространён, но если в конфиге есть подстановочные параметры, то он удобен, емнип.