Взаимные превращения JSON, YAML, XML

[@thatsme]

Нужно ещё больше парсинга. Парсинг должен жрать как можно больше ЦПУ. А ещё всё ч-з стримы, чтобы их тоже парсить. Весь этот популизм с JSON и CBOR и «зелёная» экономия, совсем не суровый энтерприйз. Как можно жить беза стэка из 10 парсеров?

[@igor_suhorukov]

Когда волшебные единороги будут кушать радугу и на выходе будет один лишь эффективный, компактный бинарный формат, то жизнь разработчиков, в окружении бабочек, станет радостной и беззаботной. А пока приходится извлекать и трансформировать то, что выдают десятки разных приложений в их «родных» форматах.

[@Busla]

XML в большинстве случаев можно проверить и десереализовать в объект более-менее стандартными инструментами. А для того, что я нередко вижу на YAML нужен каждый раз какой-то индивидуальный подход. Например, в docker-compose имена серверов — не значения (value), а ключи (key).

[@Tishka17]

Можно подумать, в xml нельзя записать что-то в тело, а что-то в аттрибут тэга. Или вот есть ещё интерксный формат plist, основанный на xml.

[@mayorovp]

Можно. Но в чем проблема-то?

[@Tishka17]

Ну вот выше у человека проблема, что имя сервера в docker-compose.yml — ключ, а не значение. Неужели это большая проблема чем то, что я написал про xml?

[@mayorovp]

Да. Известные мне десериализаторы не испытывают никаких проблем с чтением атрибутов элемента.

А вот в случае когда имя является ключом в json — то единственным вариантом становится десериализация в словарь или какой-нибудь JObject. В обоих случаях имя сервера оказывается «оторвано» от остальной информации о сервере.

[@Busla]

«Тело» — надо понимать как содержимое? — аналогом в данном случае будет сам тэг, его имя.

[@mspain]

В смысле «более менее», jaxb уже сколько лет? и json-b уже подоспело, ух заживём!

[@igor_suhorukov]

Все зависит от предприятия. Там где закупили у интеграторов Websphere и Weblogic на астрономические суммы и вложились в SOA, конечно YAML и JSON редкость.