XML это еще актуально для межмашинного обмена?

ASN.1

Будь Ъ!

есть еще плюсы

Простой парсер ценой памяти. DTD.

или есть еще плюсы у этой технологии?

Запредельная человекочитаемость.

Ну навскидку: разделение данных на собственно данные и метаданные, хотя в этом аспекте у большинства разработчиков насрано и данные хранятся в атрибутах (предназначенных для мета).

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

Есть XSLT позволяющий как преобразовывать между разными форматами (в т.ч. выводить данные в другие text-based форматы), так и приводить к человекочитаемому (HTML) виду изначально машинные данные.

XML - хорошая поддержка в нормальных СУБД. Можно писать запросы как из таблицы.

Отлично. Данные у меня кое-где иерархические, т.е. надо хранить узлы и дочерние элементы с описанием. А что такое «валидация», прочитал что есть технологические приемы контроля корректности xml?

Возми жсон. Читаемость для человека у них одинаковая, если ты правильно организуешь структуру. При этом жсоны меньше по размеру, парсятся машинами быстрее, да и парсер жсон есть уже в стандартной библиотеке почти любого современного ЯП.

В стандартной библиотеке цепепе нет парсера JSON:-) Хотя, цепепе официально обновился в 2020-м :-)

xml - это по самому своему названию язык разметки текстовых документов. прендазначен для поедания xml-процессорами и выплевывания в виде красивого текста с картинкэ и табличкэ.

причем тут межмашинный обмен данными??? какой ненормальный притянул его за уши в обмен данными, где все это вообще не нужно?

У меня с одной стороны QT, python, java с другой java. Формат данных для машин вида

Device1 SENSOR1; START;12;12;8 SENSOR2; STOP;0;0;0 Device2; SENSOR1:

в цепепе нет парсера JSON

там и xml парсера нет. потому что он много сложнее…и много ненужнее, чем json.

Речь про JSON в стандартной библиотеке любого современного языка, вообще-то, как заявлялось выше :-) Ну, так то и JSON - это JavaScript Object Notation, вообще-то :-) Наверное, поэтому, его и нет в цепепе, т.к. ненужно :-)

Формат хороший, надежный и проверенный, но не очень удобный из-за того, что он сложный и из-за этого все средства для работы с ним давно написаны и их никто старается не трогать, чтобы не отвалилось что-нибудь, потому что где XML, там легаси, а где легаси, там «работает - не трогай», поэтому обычно стараются избегать в новых проектах по возможности, чтобы не обмазываться старым API. Те, кто пользуется микросервисами, иногда вообще выносят трансляцию из XML в свой формат в отдельный прокси-сервис и забывают о нем, как только он начинает просто работать.

Смотрите по вашим требованиям, если у вас есть вменяемые библиотеки и форматы/протоколы, тогда пользуйтесь тем, что нравится, если нет - берите что-то максимально простое и все.

Например, я работаю время от времени с огромной системой, где обмен между сервисами происходит по шине через SOAP, там XML, но его один раз пишут и забывают, а внутри в каком-то поле просто складывают JSON-пейлод. Можно смотреть на это, как на мутанта, а можно просто понять, что в какой-то момент это показалось приемлемым компромиссом и все.

Если трафик не важен, то хоть что угодно. иначе самому лепить сериализаци/десериализацию под свои нужды.
Мы когда-то пилили сетевой шутер, хотели больше данных по сети гонять, чтобы улучшить поведение врагов на экране игрока и регистрацию попаданий, так нам издатель сказал, что трафик дорогой, а игроки потерпят :-)

причем тут межмашинный обмен данными???

какой ненормальный притянул его за уши в обмен данными, где все это вообще не нужно?

Вспомним: https://ru.wikipedia.org/wiki/SOAP
https://ru.wikipedia.org/wiki/XML-RPC
https://www.w3.org/TR/2001/NOTE-wsdl-20010315
…

Вспомним

не нужно никогда вспоминать плохое. думайте только о хорошем.

Вспомним:
https://ru.wikipedia.org/wiki/SOAP
https://ru.wikipedia.org/wiki/XML-RPC
https://www.w3.org/TR/2001/NOTE-wsdl-20010315
…

Деды УМЕЛИ, а ныне «… и в production» …

не нужно никогда вспоминать плохое. думайте только о хорошем.

ТС антересуется

Какой интернационал ЛУЧШЕ ...

Ты еще забыл, что возможности описания схемы и последующей валидации у XML развиваются уже несколько десятилетий. Неплох RelaxNG, в том числе его compact.

Еще ты забыл XPath.

Плюс нормальные GUI инструменты у XML, правда в основном дорогие. С этим у JSON тоже туго.

JSON в практическом применении малополезная грамматика. Никакие кастомные данные или документы на JSON в разумном виде выразить невозможно.

JSON и XML это принципиально разные подходы.

JSON это массивы, отображения, строки, числа, булеаны.

XML это дерево элементов с атрибутами и строками.

Нельзя их напрямую сравнивать. Если ты делаешь формат для книги, там XML подходит лучше.

Конкретно для межмашинного обмена, как правило, JSON подходит лучше.

парсер жсон есть уже в стандартной библиотеке почти любого современного ЯП.

Java, C, C++, Rust

da17, все зависит от объема данных.
Для небольшого объема обрабатываемых данных можно использовать любой формат …

обмена данными между машинами (небольшие файлы) перейти к чему-то стандартно

XML

есть еще плюсы у этой технологии

Ааа… Как же полыхает. Надеюсь, что тот кто выдумал эту ерунду в Аду! Бесконечная длинющая лапша от которой уже не отказаться, ужас!

Как же хорошо, что я уволился со старого места работы. Обсуждать XML? Тьфу-тьфу-тьфу через левое плечо.

Для небольшого объема обрабатываемых данных можно использовать любой формат …

… и любой ГК

Дураки такие дураки.

XML в миллион раз более нормальный формат чем всё это yaml/json говно.

Нет, XML неактуально. И никогда не было. XML не читаем ни человеком, ни машиной, избыточен, нетипизирован, переусложнён и небезопасен. Его нельзя распарсить в дерево простых контейнеров (list/dict) и скаляров. Он плох ну просто всем.

Кто-то из адептов будет вякать про схему и валидацию, но это ложь, потому что валидировать нужно абстрактную структуру данных, которая может быть распарсена вообще из чего угодно - хоть json, хоть yaml, хоть ini, хоть сгенерирована налету. Но с XML так нельзя по уже упомянутой причине - у него нет стандартного внутреннего представления, поэтому он требует собственных велосипедов для валидации. Поэтому их наличие - не плюс, а огромный минус.

Ровно то же самое можно сказать про трансформацию, которая ещё менее актуальна поскольку XML, к великому счастью, не только не захватил мир, но и, по сути, мёртв, и трансформировать надо в любые другие форматы, чего xslt не умеет и никогда не научится.

Посмотрел видео создателя json так он говорит, что дескать «xml - сложно», но на мой взгляд что json что xml

Значит ты с XML просто никогда не работал. Можешь попробовать сам если времени не жалко, придёшь к тем же выводам.

А так да, json или protobuf это, пожалуй, два лучших варианта. Protobuf я бы выбрал если критична производительность и/или предполагается работа из статически типизированных языков. Иначе json.

Для небольшого объема обрабатываемых данных можно использовать любой формат …

Вот к примеру в 1С у меня любая диалоговая форма сериализуется/десериализуется в xml.
В них сохраняется информация: какой элемент объекта используется, …, …, …
Задержек при открытии и закрытии диалоговым форм нет, а удобств для бухгалтеров МНОГО.

Что у вас за задачи и объемы данных?
От этого зависят и ответы …

валидировать нужно абстрактную структуру данных, которая может быть распарсена вообще из чего угодно - хоть json, хоть yaml, хоть ini

Докукарекался про «абстрактную структуру данных, которая может быть распарсена вообще из чего угодно» и сел в лужу.

Но с XML так нельзя по уже упомянутой причине - у него нет стандартного внутреннего представления, поэтому он требует собственных велосипедов для валидации.

Все зависит от задач, а так и xlsx, docx, … КУЧА xml в zip …

И НИЧЕГО ...

Давай da17, НЕ ТЕМНИ …

ТС, в утешение вас открою ТАЙНУ.
Любой xml в WWW передается как gz.
То бишь оригинальная длина скажем 500KB, а по сети передается 50 KB …

Java

не знал

C, C++

Я же сказал «современного»

Rust

serde_json почти стандарт.

Я же сказал «современного»

C++20 недостаточно современен?

serde_json почти стандарт.

Почти не считается.

PS если что, то я считаю, что, то, что JSON-а нет в стандартной библиотеке это хорошо и у Rust в принципе самый адекватный подход к стандартной библиотеке.

xml - это по самому своему названию язык разметки текстовых документов. прендазначен для поедания xml-процессорами и выплевывания в виде красивого текста с картинкэ и табличкэ.

причем тут межмашинный обмен данными??? какой ненормальный притянул его за уши в обмен данными, где все это вообще не нужно?

Вот поддержу. По простому: XML-документ, JSON-данные.

XML+XSD+XSLT и у тебя мощный инструмент предварительной обработки документов.

Для не больших данных: JSON или BSON, CBOR, Protobuf, Toml и т.д.

Для не больших данных: JSON или BSON, CBOR, Protobuf, Toml и т.д.

У разработчиков MongoDB, иное мнение …

Java, C, C++, Rust

А сними есть проблемы? По мне, так ни каких. Для каждого есть популярное решение. На последних трёх лично использовал json. Для C++ сейчас nlohmann/json чуть ли не де-факто стандарт, во всю появляются библиотеки использующие его. Для rust использовать что-то кроме Serde уже какой-то моветон.

У разработчиков MongoDB, иное мнение …

А они тут при чём? На сколько удобно обмениваться базами данных? Я ещё понимаю sqlite не плохо смотрится для этого.

А они тут при чём? На сколько удобно обмениваться базами данных?

Тестовые форматы не эффективны для обмена …

Sorry, «Текстовые»

Так для этого и создавались BSON, CBOR и т.п.

У XML одно преимущество: если XML кривой, то ты это обнаружишь раньше за счёт закрывающих тегов. Платой является размер.

Мне сложно представить, в каком случае это может быть реально важно, так что бери JSON и не выделывайся.

Так для этого и создавались BSON, CBOR и т.п.

Вот, уже «горячо» …

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

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

По моему опыту КРАЙНЕ редко на практике нужно для обмена данными что-то сложнее DSV delimeter separated values. Так что фтопку и xml и все эти json с ямлами и прочая херня. Хотя если Xml иногда имеет смысл как валидируемый формат файла, то json уже точно нафиг не нужен в приличном обществе, только жабоскриптокод если.

А сними есть проблемы?

Может и есть, не знаю.

По мне, так ни каких. Для каждого есть популярное решение.

Только для Java я сходу назову 3 популярных решения.

На последних трёх лично использовал json. Для C++ сейчас nlohmann/json чуть ли не де-факто стандарт, во всю появляются библиотеки использующие его. Для rust использовать что-то кроме Serde уже какой-то моветон.

Речь о стандартной библиотеке.

По моему опыту КРАЙНЕ редко на практике нужно для обмена данными что-то сложнее DSV delimeter separated values.

Угу, только вчера писал свой парсер, чтобы исправить тот кривой CSV, который выплёвывает одна утилита.

С невалидным JSON по крайней мере я в природе не встречался.

XML - это не сложно, а просто громоздко и неудобно. при использовании json запросы/ответы меньше

У XML одно преимущество: если XML кривой, то ты это обнаружишь раньше за счёт закрывающих тегов. Платой является размер.

Если только речь про теги, то люди, которые ещё были совсем настоящими программистами, ещё в 1960-х в IBM придумали SGML и DTD для валидации SGML, но в 90-х набирающим силу вебмакакечеству sgml показался слишком сложным и из него поначалу как подмножество выделили xml. Однако если sgml мог быть составлен из многих записей и поэтому его можно было использовать в потоке данных, то у xml есть только один root элемент, что сразу породило множество извращений при его практическом использовании

Речь о стандартной библиотеке.

Уже давно прошли времена когда требовалось что бы стандартная библиотека решала максимум задач. Сторонние библиотеки во многом стали предпочтительней, т.к. они могут развиваться активнее компиляторов.

Я лично против тянуть в стандартную библиотеку С++ json и т.п. Ему там не место. Есть популярные решения для этой задачи. И они могут спокойно развиваться с развитием плюшек стандарта.

Так что на вопрос: «есть ли в Java, C, C++, Rust поддержка json» ответ будет: «Да, на уровне популярных сторонних библиотек». И этого достаточно для принятия решения использовать или нет json в проектах на Java, C, C++, Rust

Ну CSV - это вариант dsv от Microsoft, а у них есть талант даже из правильных идей создать пример как НЕ нужно делать, об этом про csv ещё Эрик Реймонд писал

И кстати я встречал кривой json - генерился прошивкой одной китайской железяки за много килобаксов, причём сцуко не все время кривой, а изредка при некоторых параметрах работы