Комментарии 79
YAML: YAML Ain't Markup Language
По сути YAML — это язык разметки
быть понятным человеку;
Я просто оставлю это здесь:
a: yes # boolean
b: yep # string
c: (-: # error
d: :-) # stringбыть лёгким в реализации и использовании.
У него самая сложная (многократно) грамматика среди языков описания данных.
быть переносимым между языками программирования;
Тут люди даже много более простой JSON перенести не могут: https://habr.com/ru/company/mailru/blog/314014/
использовать цельную модель данных для поддержки обычного инструментария;
Не очень ясно что имеется ввиду, но кажется аннотации типов этому противоречат, ибо позволяют расширять модель данных как угодно.
Подробнее я разбирал этот и другие форматы тут: https://habr.com/ru/post/503240/
Loader=yaml.C(Safe)Loader - 1.3s
Loader=yaml.(Safe)Loader - 12s
>>> file = open("/path/file.yaml").read()
>>> start_time=time.time(); r = yaml.load(file,Loader=yaml.CSafeLoader); print("--- %s miliseconds ---" % ((time.time() - start_time)*1000))
--- 1377.1591186523438 miliseconds ---
Цели создания
Сообщество разработчиков устало от «зоопарка» различных форматов для конфигов, им хотелось упростить себе жизнь и прийти к единому понятному формату. И в 2001 году Кларк Эванс создал YAML 1.0.
Так появился стопервый формат конфигов…
А вообще, YAML это про что угодно, но только не удобство, имхо
Yaml то круче, только json в обиходе и по дефолту во многих инструментах, тех же, что в примере. А это своего рода проблема критической массы.
В общем, на мой взгляд один из самых ужасных форматов конфигурации, который почему-то всюду засовывают.
Yaml vs. Json — что круче?
Дедушка XML: "Шли бы вы оба к себе в песочницу, детки!"
- Стандарт на 100% формализован. Поддерживается вообще везде.
- Не зависит от форматирования. Кодировка задается в контенте. Include из других файлов.
- Тэги, атрибуты, mixed content.
- XML Schema: полная семантика валидации, стандартные типы, кастомные типы, структуры, списки с границами, группы, расширения/сужения, ссылки, namespaces.
- Языки запросов: XQuery, XPath, темплейты XSLT
- Потоковый парсинг SAX/StAX
- База для кучи DSL-ей: https://en.wikipedia.org/wiki/List_of_XML_markup_languages
- Жутко тяжелый для любого джуна
что у JSON-формата есть некоторые ограничения:
Нельзя писать коментарии, так что как конфигурация Json сразу отпадает. Это тупо формат сериализации данных.
дедушка XML: многабукаф
а в остальном: всякие JSON'ы и YAML'ы — это упрощенные версии XML.
Вообще нет. Когда они появились такой вещи как json schema не было в помине. У xml xsd был сразу, это часть спецификации. А как только json/yaml начали тащить в продакшон и интерпрайз тут и начали отрастать json schema open api и прочие подобия xsd и wsdl
дедушка XML: многабукаф
Как точно подмечено!
Не так уж и много. По сравнению с прадедушкой SGML.
Но вообще разница в целях между сохранением конфигов и сохранением (сериализацией) документов всё же есть. Конфигам не так часто нужен потоковый парсинг, а вот комментарии и переменные — хороший синтаксический сахар.
1. null
2. true/false
3. массивы
4. даты
5. отличия строк от чисел
А то в лоб я могу придумать кучу способов, но какие правильные?
Ну и бонусом вопрос, в XML правильно игнорировать или ведущие пробелы или нет?
Емнип, правильно в текстовых нодах склеивать подряд идущие пробельные символы в один.
Вам сюда https://www.w3schools.com/xml/schema_intro.asp
Существует формализованные средства задачи валидации xml по схеме. Можно накрутить и свои условия причем довольно сложные.
Если серьёзно, то с XML я достаточно давно работаю, ещё с тех пор, как это было прорывом и кровавый энтерпрайз радостно залез на него. Я и читал многостраничные талмуды по форматам и сам писал, и делал сложные схемы, использовал xsd и xpath.
Но… каждый раз это всегда боль, одни и те же задачи все решают по-разному, реальные документы не бьются с документацией, схемы валятся (и у тебя выбор — это переписка на неделю с объяснением, что ты не верблюд, или подсовывание костыля).
XML это очень сложно, у него безумное количество фич, при этом он совершенно беспомощный в базовых вещах. Проблемы решаются валидацией по схеме, но не здравым смыслом. То, что на JSON очевидно — в XML должно быть специально описано, и в каждом, блин, случае обязательно будет по-разному.
А как в JSON очевидно вставить многострочный текст или комментарий?
То, что на JSON очевидно — в XML должно быть специально описано, и в каждом, блин, случае обязательно будет по-разному.
Простите что? А json schema по вашему что это? Тот же самый XSD. Фишка XSD в том что если вы его задали, то отвалидировать документ и сказать что в нем плохо можно именно по схеме банально одним вызовом. Как это сделать в JSON? Вот мне пришел JSON мне надо его проверить. Как это делать? Он к примеру не содержит никакой информации о том что в нем должно быть и где.
Есть полустандартное (для json) свойство @schema со ссылкой на используемую схему. Некоторые редакторы/IDE поддерживают
Давайте приведу аналогию, вы открываете сайт, и там есть текстовое поле с описанием «Я прочитал лицензионное соглашение». Вы догадаетесь что там надо ввести? Конечно, если вы не угадаете, то будет ошибка: «Необходимо ввести в это поле значение True/False» и станет понятно. Но в приличном обществе используют чекбоксы.
Вот и с XML та же подстава, отсутствует всякая типизация. А проверяется только строка на соответствие шаблону. И какой шаблон будет в конкретном случае — известно только разработчику данного формата. Может он сделает True/False, а может true/false или yes/no, 1/0, или вообще зафигачить всё в атрибут. Как вариант, сделать вложенный элемент <True/>. Есть множество способов, какие-то более распространённные, какие-то редкие. Но чтобы выяснить, что используется в конкретном случае, надо читать схему или пробовать методом научного тыка.
Эмм. Вы вообще смотрели что xml предлагает? Там есть стандартные простые типы это
- строка
- набор типов для даты и времени. Причем с конкретным указанием что именно надо и надо ли там таймзону. Дату и время кстати можно задавать как вместе так и отдельно.
- набор типов для чисел. Причем в том числе там есть не только float и integer а здоровый набор практически на любой вкус
- отдельно тип boolean
- ссылки
Посмотреть все типы можно тут https://www.w3schools.com/xml/schema_dtypes_string.asp
Просто листайте дальше.
Да xml всегда подразумевает наличие xsd схемы и это нормально. Это и позволяет избежать того самого тыка про который вы рассказываете. В случае JSON как этого избежать?
Ну и просто обращу ваше внимание что текущий стандарт OpenAPI включает в себя json-schema и в целом копирует все тот же старый добрый WSDL
И все это надо потому что внезапно стало надо организовывать интерфейс машина — машина.
Вы вообще смотрели что xml предлагает?
Элементы, текст, атрибуты и строки как их значения, если не вдаваться в директиві препроцессора и т. п… Могут быть ограничения типа IDREF, но не более. Никаких чисел или дат — это типы XML Schema, а не XML
Да xml всегда подразумевает наличие xsd схемы и это нормально.
Не всегда. Как минимум есть классическая альтернатива — DTD. Может в суровом энтерпрайзе DTD или XML Schema и обязательны, но мир им не ограничивается. Даже если я составлю DTD или схему для AJAX API, то далеко не факт, что её хоть кто-то когда-то загрузит. Я проверял :) Апишкой пользуются, а схема ни разу загружена не была за 2 года :(
Элементы, текст, атрибуты и строки как их значения, если не вдаваться в директиві препроцессора и т. п… Могут быть ограничения типа IDREF, но не более. Никаких чисел или дат — это типы XML Schema, а не XML
Представьте себе никто не использует xml без xsd. С тем же успехом можно передавать просто текстом.
Не всегда. Как минимум есть классическая альтернатива — DTD. Может в суровом энтерпрайзе DTD или XML Schema и обязательны, но мир им не ограничивается.
А прям json нам что-то гарантирует ага.
Представьте себе никто не использует xml без xsd.
Неправда. Well-formed документы очень многие используют в самых разных целях.
С тем же успехом можно передавать просто текстом.
С просто текстом сложно работать, а так DOM есть на всех или почти всех языках.
А прям json нам что-то гарантирует ага.
С JSON Schema даже что-то гарантирует, да и без неё гарантирует различаемость, например, булевых значений, строк и числел — уже больше чем XML даёт.
С тем же успехом можно передавать просто текстом.
Неправда. Well-formed документы очень многие используют в самых разных целях.
Может приведете пример?
да и без неё гарантирует различаемость, например, булевых значений, строк и числел — уже больше чем XML даёт.
Простите для кого? Вот я true/false могу написать и с ковычками и без ковычек иии? Да собственно ничего.
А в случае JSON Schema мы получаем жалкое подобие xsd. Но это и то лучше чем ничего как было раньше.
Может приведете пример?
Навскидку https://cloud.google.com/storage/docs/xml-api/get-bucket-list Может и есть где-то схема, но явно не для обычного использования
Простите для кого?
Для читателя. Если true — значит вы написали без кавычек )
Навскидку https://cloud.google.com/storage/docs/xml-api/get-bucket-list Может и есть где-то схема, но явно не для обычного использования
Ну я вас умоляю. Там прям в ответе же :)
xmlns='http://doc.s3.amazonaws.com/2006-03-01'
Для читателя. Если true — значит вы написали без кавычек )
Как бы когда у нас json начинает уезжать в сторону взаимодействия машина — машина у нас начинает вылазить небходимость однозначной валидации по схеме.
Не путайте разметку документа с его семантикой — это разные вещи. Семантика, т.е. способ интерпретации контента, задает парсер и доменная модель. Поэтому "стандартные" соглашения — это те, которые приняты в данной доменной модели, и на которые настроен парсер. В XML семантика может задаваться схемой, плюс есть технологии, которые из схемы могут генерить доменную модель (JAXB, XMLBeans, etc.). А вот JSON (а потом и его преемник Yaml) — выходец из JavaScript (по сути изначально это был кусок кода на JS), свои слабые типы JS встроили в саму разметку, породив при этом больше боли, чем выгоды: отличие true от "true", 42 от "42" и т.д.
- Чаще всего minOccurs=0 и отсутствие тэга интерпретируется как null. Для структур с фиксированным набором полей: nillable=true/xsi:nil="true". Такая же проблема двойственности есть и в Json: не указать тэг или поставить null?
- xs:boolean чем не подходит?
- maxOccurs='unbounded', для простых типов xs:list.
- date, time, dateTime и еще набор на все случаи жизни со стандартизированным форматом
- в самой разметке нет и не должно никаких отличий или запахов (flavours), отвечающих за интерпретацию контента (см. выше). В schema же есть широкий набор числовых и кастомных типов.
Ну и бонусом вопрос, в XML правильно игнорировать или ведущие пробелы или нет?
Да. Таким образом убирается зависимость от форматирования документа. Если необходимы пробелы, есть способ сделать через CDATA.
1. отсутствие тега — это undefined, null — это явное указание. И да, это вполне может использоваться. Маркать элемент атрибутом о том, что он null — это костыль на мой взгляд.
2. тем, что это соглашение для строки.
3. Один элемент — это массив из одного элемента или просто строка? Отсутствие элементов — это null или пустой массив? Или будем заворачивать в ещё один элемент? Тогда как называть внутренности?
4. Тут в JSON примерно так же
5. А я считаю, что вполне могут быть
Зависимость от форматирования — как раз проблема XML, в JSON её нет, в зависимости от парсера, он может сохранить их или убрать, CDATA в целом ничего не добавляет. Т.е. уже грабли на ровном месте, в зависимости от того, что нам надо, и как нам прислали документ.
Отличие true от «true» — это очень важно.
Только вот часть парсеров во благо совместимости схавает и "true" как boolеan значение
- тем, что это соглашение для строки.
Как бы ровно такое же соглашение в json. То что оно прописано не явно ничего не меняет. Вон я выше привел что большая часть парсеров схавает там и строку если в ней будет "true" или "false"
- Один элемент — это массив из одного элемента или просто строка? Отсутствие элементов — это null или пустой массив? Или будем заворачивать в ещё один элемент? Тогда как называть внутренности?
Вы xml на картинках видели? Это говорит о том что таких элементов может быть объявлено более одного.
- Тут в JSON примерно так же
Нет. В нем есть только date и date-time и что еще веселее это просто формат строки.
- А я считаю, что вполне могут быть
Нет ничего. Более того я никак не могу по стандарту указать в json что смотри вот эту схему для проверки документа. В xml можно.
Отличие true от «true» — это очень важно. Также как и отличия «0042» от 0042.
А отличие Date от строки не очень важно?
- тем, что это соглашение для строки.
Т.е. формат json date не соглашение для строки? Вообще сериализация и десериализация подразумевает сохранение значений в текстовой или бинарной форме. Любое примитивное значение так или иначе мепится в строку.
- А я считаю, что вполне могут быть
То, что вам в JS оставили boolean и еще пару примитивных типов, и на базе которых склепали JSON, совсем не значит, что в нормальных ЯП нет других примитивных (и кастомных) типов, которые тоже надо как-то мэппить. Задолбаетесь для каждого придумывать собственные кавычки :)
А отличие Date от строки не очень важно?
Важно. Мне это в JSON тоже очень не нравится. Раньше была идея писать /Date(timestamp)/ — но тоже костыль и не прижилось.
Вообще сериализация и десериализация подразумевает сохранение значений в текстовой или бинарной форме. Любое примитивное значение так или иначе мепится в строку.
Вот вообще не так для бинарной формы. Посмотрите хоть на Message Pack.
То, что вам в JS оставили boolean и еще пару примитивных типов, и на базе которых склепали JSON, совсем не значит, что в нормальных ЯП нет других примитивных (и кастомных) типов, которые тоже надо как-то мэппить.
Есть другие типы, да. Но практически во всех языках есть понятия числа/строки/массива/словаря и это разумная и понятная база.
Важно. Мне это в JSON тоже очень не нравится. Раньше была идея писать /Date(timestamp)/ — но тоже костыль и не прижилось.
Ну вот о чем и речь. В общем случае парсер не знает в какой тип замэпить значение поля, поэтому необходимо предоставлять ему метаданные о структуре документа и типах отдельно от самого документа. Так работают, например, Java-библиотеки типа Jackson и MOXy, которые мепят Json-документ в объекты Java. Поскольку вся информация о типах и структуре записана в классах, парсер знает в какой тип должно мэпится каждое поле. В этом сценарии нативные типы Json абсолютно рудиментарны: зная, что тип поля boolean, парсер одинаково хорошо распарсит значение и true и "true". С таким же успехом эти библиотеки парсят XML и вообще любой формат, где нет никаких boolean ни number.
С проблемами типов при сериализации я встречался в JS, Python, .NET, когда умный парсер подставляет самый подходящий тип, а потом начинает ломаться. В .NET был, кстати, самый забавный случай, когда он строку, похожую на дату считал датой и портил её. И это функционал по умолчанию.
Не все и не всегда делают маппинг json/xml => объект. Бывают абстрактные десериализации, в абстрактный объект, бывает миграция версий, особенно для конфигов, когда хочется оставить поддержку старой версии. И всё может замечательно стрелять.
Можно придумать такой пример (стырил из nginx):
мы пишем прокси, и у нас в конфиге есть параметр proxy_redirect, который может принимать значения: true — делать редирект, переписывая хост автоматически. Нужно большинству пользователей. false — не делать, или строка, которая говорит, на какой хост редиректить. Мы не различаем false и «false» и всё работает до тех пор, когда у кого-то не оказался хост с названием false. Может даже как-то заработает, но могут появиться спец.эффекты.
Решение: две настройки, или воспользоваться типизацией.
Иногда бывает относительно абстрактный маппинг, иногда бывают языки со слабой типизацией.
В таком случае семантика интерпретации задается самой программой. Универсальный парсер готовит дерево, не вдаваясь в типы каждого поля, и использует только string. А уже сама программа интерпретирует string-поле в зависимости от того, что она там ожидает.
И после таких утверждений, что нет разницы, true или «true» люди с фамилией Null или номерным знаком NULL начинают испытывать проблемы.
Могу предположить какие дикие батхерты испытывает чел с фамилией Null в цифровом веке :) Однако, если у вас поле "фамилия", так вы и должны интерпретировать ее как string и никак иначе. Особо умные парсеры типа Yaml пытаются оказать медвежью услугу и конвертнуть литерал в наиболее подходящий по их мнению тип. Отсюда и возникают проблемы с null, true и бедной Норвегией. С умными всегда тяжело — никогда не знаешь что от них ожидать :)
Можно придумать такой пример (стырил из nginx):
Это заведомо плохой дизайн, навеяный как раз полутипизированным парсером. Если мы зададимся вопросом, "какой тип будет у данного поля?", то он будет синтетическим: BooleanOrString, что достаточно нетривиально как со стороны юзера, так и со стороны кода. В данном случае гораздо проще и понятнее использовать два связанных поля с enumerated и string типами соответственно:
proxy_redirect: none|auto|host
proxy_redirect_host: url
Жутко тяжелый для любого джуна
Забавно, что моя карьера начиналась с создания документации на XML+XSLT+VRML.
Поддержу. В xml есть мощнейший механизм описания схемы данных; подключив правильную схему можно практически на 100% защититься от того, что конфиг окажется некорректным — IDE подскажет, что куда писать и подсветит все ошибки.
Но нет, давайте переходить на JSON, а корректность структуры проверять по документации… Окей, завезли JSON schema, с грехом пополам вроде заработало, немного приблизившись к xml+xsd.
В топку! Давайте все переходить на YML.
// не то чтобы я был большим фанатом XML, просто ситуация забавляет
И все проблемы XML автоматически вытекают из его достоинств, да.
Не зависит от форматирования. Кодировка задается в контенте.
Одна проблема — не все клиенты умеют во все кодировки. Соответственно, гарантии переносимости нет.
Include из других файлов.
Который создаёт туеву хучу проблем с безопасностью. Умудриться сделать RCE в языке разметки — это, конечно, вин.
Тэги, атрибуты, mixed content.
Самый, конечно, бессмысленный провал в дизайне языка. Начерта нужны атрибуты отдельно от дочерних нод — Тим Бернерс-Ли его знает. Не могу не отметить, что на значения атрибутов полагаются свои правила эскейпинга.
XML Schema: полная семантика валидации, стандартные типы, кастомные типы, структуры, списки с границами, группы, расширения/сужения, ссылки
Это ж в прямом виде нарушение инкапсуляции.
JSON — типизирован сам по себе. В нём по формату есть числа, строки, true, false и null.
А в XML, если тебе схемы не дали, всё — строка. Нет способа передать число.
А уж какие шикарные приёмы изобретают для отдачи null в xml — это ж просто сказка. Один xsl:nil чего стоит. null-евое значение с атрибутами — как вам концепт?
namespaces.
Нейсмпейсы — главный рак XML-я. Во-первых, опять нарушается инкапсуляция: чтобы написать код, обрабатывающий XML корректно, нужно блин знать все неймспейсы, которые в этом XML будут. Код из-за этого получается переусложнённый и нечитабельный. Впрочем, народ частенько забивает болт на неймспейсы и пишет на local name-ах.
Языки запросов: XQuery, XPath
Придумали проблему и героически её победили.
В 9 из 10 языков программирования я могу написать json_value["field_name"][0]["nested_name"] и не заморачиваться никакими *Path-ами. А если мне зачем-то понадобятся хитровыдуманные выборки — то блин по плоской структуре без атрибутов, неймспейсов и mixed-контентов они работают гораздо удобнее и производительнее.
темплейты XSLT
Как человек, который лет пять писал на XSLT, должен сказать следующее: единственным плюсом этой поделки является гарантия получения валидного XML на выходе. Во всём остальном это невероятно отвратительный язык, который вынуждает изобретать кучу велосипедов (погуглите «как на XSLT выбрать уникальные значения дочерних нод») и практически никак не отлаживается. Ну и да, xsl:variable, который на самом деле нельзя менять — просто возглавляет мой топ самых дурацких именований.
В сухом остатке: XML — невероятно переусложенный формат. Его проблема в том, что он не ложится нативно на структуры языка. Результатом парсинга XML будет объект типа XMLDocument, работа с которым вызывает в основном нравственные страдания. Результатом парсинга JSON будет нативный объект языка.
Одна проблема — не все клиенты умеют во все кодировки. Соответственно, гарантии переносимости нет.
UTF-8 и ISO умеют все. Если вам необходимо использовать экзотическую кодировку типа CP866 или KOI-8, то это конкретно проблема соглашений между вами и вашими клиентами.
Который создаёт туеву хучу проблем с безопасностью. Умудриться сделать RCE в языке разметки — это, конечно, вин.
Как бы это не язык разметки, а кривой дырявый парсер LSP4XML. С таким же успехом можно назвать дырявым и html и javascript и css и вообще все, что ссылается на внешние ресурсы. Причем в самой Java парсер устроен правильно — необходимо въявную указать свой ResourceResolver который будет подтаскивать внешние импорты.
Начерта нужны атрибуты отдельно от дочерних нод — Тим Бернерс-Ли его знает.
Чтобы понять, попробуйте скотвертировать типичную html страницу во что-то JSON-подобное и посмотрите что получится. Есть понятия данных и метаданных. В атрибутах хорошо хранить метаданные, например тип поля, а в тэгах — само значение.
нужно блин знать все неймспейсы, которые в этом XML будут
Никакого нарушения инкапсулации: неймспейс — такая же часть имени тэга, поэтому его нужно знать при парсинге. Геморроя больше с неймспейсами, согласен, однако он оправдан, когда у вас гетерогенная платформа с кучей систем и различных гетерогенных интерфейсов.
JSON — типизирован сам по себе. В нём по формату есть числа, строки, true, false и null.
А уж какие шикарные приёмы изобретают для отдачи null в xml — это ж просто сказка. Один xsl:nil чего стоит. null-евое значение с атрибутами — как вам концепт?
Как и товарищ выше по треду, вы не осознаете разницу между разметкой и семантикой. Просто в JS было зашито только 4 типа, и эти типы смогли перекочевать в json, который изначально и был куском JS кода. Но вот у вас появилось поле Date, и парсер уже бессилен сконвертить его, в результате чего приходится добавочно где-то писать логику, что данное поле следует интерпретировать как Date, а не как String, или писать для него конвертер — т.е. задавать семантику отдельно от самой разметки. А раз так, чем таким выделились boolean, number и null, чтобы для них делать отдельные правила разметки? Ведь в других языках даже для простого числа сущесвует 10-15 различных типов.
То же самое с нулом. Это не более чем "стандартное" соглашение в языке разметки. Как вы его семантически будете интерпретировать null — ваше личное дело. Кроме того, есть языки где значение NULL также может быть типизировано. Для этого могут потребоваться дополнительные атрибуты на тэге.
В 9 из 10 языков программирования я могу написать json_value["field_name"][0]["nested_name"] и не заморачиваться никакими *Path-ами
Не можете, ибо JSON — это не более чем строка с разметкой, а здесь у вас объект, созданный парсером на вашем любимом ЯП. Только не забывем делать проверку на null и index out of bound после каждого шага. XQuery, XPATH, XSLT не привязаны ни к какому языку и сами собой представляют определенный язык.
В сухом остатке: XML — невероятно переусложенный формат. Его проблема в том, что он не ложится нативно на структуры языка
Он не может ложиться нативно поскольку задумывался как независимый ни от одного из существующих языков, в отличие от Json, который изначально был кусоком JS кода. Есть специальные парсеры, которые мэпят XML в типы и структуры на каком-то языке (JAXB, Jackson, XMLBeans). А вот нативные парсеры для большинства платформ — это да, неудобоваримое дерьмо. Знаю по Java — наверное самый уродский и неудобный XML API, но при этом самый методичный и полный. Многих и отпугивало то, что в XML делать простые вещи стандартными средствами было достаточно сложно и контринтуитивно. Но практически везде есть куча сторонних библиотек для удобной работы.
всё ви врёти, XSLT божественно отлаживается в MSVS, например
Ну лично для меня главные недостатки JSON такие:
1) Нет родного типа для времени (вместо этого используют строки)
2) Нет родного типа для множеств, используют массивы
3) Нельзя ставить комментарии
Yaml ужасен, но лучше человечество для конфигов ничего не придумало
https://www.arp242.net/yaml-config.html
https://www.lucidchart.com/techblog/2018/07/16/why-json-isnt-a-good-configuration-language/
хлам этот ямл. TOML лучше для конфигов
Ямл доставляет историями — ставить кавычки или нет, True, true или "True". А самое любимое — мультилайн строки как значения ключей. Сколько там способов их описать?
Очень неплохо заходит для описания сложных конфигов и доступен в виде отдельной библиотеки — github.com/hashicorp/hcl
Yaml vs. Json — что круче?