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

А не CSV это вообще не стандарт, а так, расплывчатая идея.

Я работал и с xml и с json для передачи данных (по работе, сам бы такое не сделал). XML вынес мозг, с json нормально все. В boost появился json. У nlohmann есть bson. Из практики: если говорит об обмене данными по сети (даже в перспективе) то первым горлышком станет сеть, а потому лишнее передавать через неё не надо. Лучше для таких целей вообще бинарный формат взять.

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

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

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

Сторонние библиотеки во многом стали предпочтительней предпочтительнее всегда стандартная.

требование никуда не делось.

Выберись из танка. Не C#-ом едины.

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

с какого перепуга? есть проблема использовать сторонние библиотеки?

Это не сходится с реальностью, но у тебя есть 100% право на это мнение :)

есть технологические приемы контроля корректности xml?

Если хранить xml в БД в поле с типом xml, а не в строке, то сервер будет автоматом ловить при попытки записи как минимум: ошибки парсинга и ошибки кодировки.

Также можно сделать схему представления данных и валидировать, что пришли именно те данные, что надо. Последнее не доводилось использовать, но можно поискать по запросу xml scheme validation + название sql server.

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

А, ну и еще неудобство в том, что в json AST и, следовательно, операции над ним можно понять за 15 секунд, а в случае с XML нужно получить PhD по атрибутам, нодам, тегам, элементам, декларациям и т.д.

А что на счет XML это совсем уже устаревшее решение или есть еще плюсы у этой технологии?

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

Вообще, слишком сильно париться не надо, если тебе нравится JSON и есть наработки — используй JSON. Если тебе нравится XML и есть наработки — используй XML.

Сколько раз я уже кидал на ЛОР эту ссылку (или ссылки на ответы), и похоже, мой дозор никогда не окончится.

От csv приходится отказываться, т.к. сделал одно ошибочное решение в ряде старых модулей. Проверяю на количество полей в строке и если их больше или меньше чем нужно рассматриваю это как ошибку. А сделал так из-за того что раньше при перекидывании из win в linux иногда символы конца строки менялись. А это значит при расширении формата или изменении порядка полей придется пересобирать все модули.

Кроме того если первое поле например ид, надо где-то описывать что id это 1, и еще что бы в коде не обращаться по номеру делать enum вида enum class { ID_POS = 1 }

Любой xml в WWW передается как gz.

При чем здесь WWW? Что-то мешает передавать другие форматы как gz?

Задержек при открытии и закрытии диалоговым форм нет, а удобств для бухгалтеров МНОГО.

С такими критериями вам подойдет любой формат хранения данных.

С такими критериями вам подойдет любой формат хранения данных.

Вы правы.
Для этой задачи /сохранение информации о диалоговых формах/ подойдет ЛЮБОЙ формат данных!
Почему xml использую?
В 1812 году взял https://github.com/leethomason/tinyxml2 и добавил в него классы и методы для совместимости с Microsoft https://docs.microsoft.com/en-us/cpp/build/reference/xml-documentation-visual-cpp?view=msvc-160 Кроме этого добавил в классы и свой API …

А так, ДА для этой задачи можно использовать любой формат …

добавил в него классы и методы для совместимости с Microsoft https://docs.microsoft.com/en-us/cpp/build/reference/xml-documentation-visual-cpp?view=msvc-160 Кроме этого добавил в классы и свой API …

По существу у меня а-ля MSXML 4.0 …

Нынче можно в блокчейнах.

можно

модно

Как минимум для xml есть потоковые парсеры, даже в отдельный класс выделены: sax. Для json я таких не находил, вроде и на лорчике мне такой готовый не смогли найти. Для xml, как первоклассные сущности есть как схемы, так и запросы, прям стандартизированные.

Но - xml это не модно. Поэтому, решение будет вызывать лёгкое отвращение у каждого встречного поперечного.

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

А на «ПОПЕРЕЧНЫХ» не нужно равняться.
У них знания

ПОПЕРЕЧНЫЕ ...

Для json я таких не находил, вроде и на лорчике мне такой готовый не смогли найти.

Даже на хабре смогли прочитать сайт жысона чуть внимательнее, же ну!

    C:
        JSON_checker
        JSON parser
        json-c
        M's JSON parser
        YAJL
        cJSON
        Jansson
        js0n
        LibU
    C++:
        jsoncpp
        zoolib
        JOST
        CAJUN
        libJSON
        nosjob

А что такое «валидация», прочитал что есть технологические приемы контроля корректности xml?

Ну тебе ж написали ещё во втором комментарии - DTD. Более конкретно - xml schema

«xml для энтерпрайз решений, json для веб» (с) ))) Это колесо переизобретения «человекочитабельных» форматов данных, которое всегда возвращается к бинарям (см. «protobuf» и что про это поделие пионеров c NIH синдромом сказано теми, кто видал рассвет и закат CORBA), потому что машинные генераторы форматов генерируют столько «человечитабельности», что человеку в жизни столько не прочитать.

XML де-факто умер. Встречается ещё кое-где как древнее legacy и вызывает сильнейшее отвращение (хотя когда-то 20 лет назад я сам купился на XML хайп и считал, что за ним будущее).

И, да, ещё в оффтопике и оффтопичных технологиях XML встречается на каждом шагу, как говорят американцы «to add insult to injury».

Для protobuf кстати тоже нет потокового парсера.

Хм, где ты был раньше :) И странно почему я сиё не нашёл когда надо было…

Надо вспоминать контекст, видимо там больше требований было…

А так да - для json тоже появляются схемки и запросики. Вот только я давно не проверял, что из этого есть хоть как-то стандартизировано.

Для JSON есть JSON Schema

Довольно головоломная в нескольких местах спека, с нерешёнными (нерешаемыми?) вопросами. Но базовые задачи решает.

А зачем для межмашинного обмена текстовый формат данных?

А зачем для межмашинного обмена текстовый формат данных?

Шутка

А WWW это межмашинный обмен данных?

Потому что машины разной системы: двоичная и троичная белковая и кремниевая

текстовый формат

Лучше было бы выбрать голосовой формат или узелковое письмо.

А WWW это межмашинный обмен данных?

Это игра такая.

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

XML - это ад.

xmls, docs содержат штук по 15 xml в zip.
Фирма Microsoft с вами не согласна …

2021

парсить текст

Microsoft

на винфак, быдло

Почитай Eric Raymond, Art of UNIX Programming. Он там подробно этот вопрос разбирает, почему текстовый. Обрати внимание, что HTTP, SMTP, IMAP, POP3, FTP и многие другие традиционные юниксовые протоколы именно текстовые. Это не просто так. HTTP после второй версии стал бинарным, правда, но то уже гугл подгадил.

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

Если лень читать, то в двух словах - текстовые протоколы ощутимо упрощают разработку за счёт использования кучи готовых текстовых утилит, легко посмотреть внутрь протокола и без всяких понять, что там происходит. А текстовый оверхед тривиально устраняется опциональным gzip-ом поверх основного протокола, например как это сделано в HTTP.

Почитай Eric Raymond, Art of UNIX Programming

HTTP, SMTP, IMAP, POP3, FTP

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

Ага, все эти причины были актуальны 30+ лет назад.

А текстовый оверхед тривиально устраняется опциональным gzip-ом поверх основного протокола, например как это сделано в HTTP

Парситься он от gzip быстрее не станет, да и другие преимущества современных бинарных форматов от этого в нём не появятся.

Ага, все эти причины были актуальны 30+ лет назад.

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

Парситься он от gzip быстрее не станет, да и другие преимущества современных бинарных форматов от этого в нём не появятся.

Скорость парсинга не важна практически никогда. Всё равно твоя сетевая столько не прожуёт. А если прожуёт, значит поставить побольше серверов проблем никаких не будет. А если и прожуёт и серверы ставить не можешь, значит ты в каком-то диком 0.001%, тогда можешь делать как считаешь нужным.

Вот HTTP попал в этот 0.001%, когда стал самым используемым протоколом в мире с огромным отрывом и там любые оптимизации стали экономить сотни миллионов долларов и мегаватты электричества. Но другим протоколам это просто не нужно.

Именно из-за этого и взяли, что бы можно было стандартными утилитами sed awk парсить и быстро отлаживать т.к. удобно глазами пробежаться и сразу все понятно.

XML никогда не был актуален для межмашинного обмена! Либо JSON, либо бинарный формат, либо "параметр=значение\n". Последнее мне больше всего нравится, т.к. позволяет из нетката по-человечески отлаживать…

если быть внимательным, то можно заметить, что я писал о М2М только.

для локальных форматов - не вопрос, он может решать свои задачи (SVG, например), хотя лично я не вижу целесообразности именно текстового представления. единственная вещь, оправдывающая именно текстовое представление - возможность вести версионирование тем же гитом, но тогда должно быть строчное деление внутри файла (а оно точно есть в тех же упакованных XML докса?), без него любой чих будет полным апдейтом всего файла и тогда мы возвращаемся к бинарям ).

имхо XML (и соап в частности) жив исключительно благодаря IBM, который успел его впарить в нулевые всем большим бизнесам. куча интеграторов погрела руки втюхивая программно-аппаратные решения на базе всяких WSBI с тонной железа (а иначе этот XML-чугуний было не переварить). из личного опыта - в билайне биллинг и вся инфра была на базе xml-ного соапа. даже AAA - они диаметер декодировали в SOAP и отправляли в биллинг. думаю, сможете догадаться сколько стоек железа продали интеграторы с таким решением ))

Скорость парсинга не важна практически никогда.

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

HTTP попал в М2М случайно и это очень печальная страница индустрии ибо он не для этого создавался.

Нет, везде JSON или бинарные протоколы.

разделение данных на собственно данные и метаданные

В чём разница?

Если лень читать, то в двух словах - текстовые протоколы ощутимо упрощают разработку за счёт использования кучи готовых текстовых утилит, легко посмотреть внутрь протокола и без всяких понять, что там происходит. А текстовый оверхед тривиально устраняется опциональным gzip-ом поверх основного протокола, например как это сделано в HTTP.

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

Скорость парсинга не важна практически никогда

Очень категоричное заявление.

Ну и про остальные плюсы бинарных форматов ты вообще ничего не сказал.

твоя сетевая столько не прожуёт

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

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

вот в моё время между машинами дискеты носили и ты косатик носи, оно так надёжнее.

Это дискеты то надежнее? В мое время носили катушки перфоленты, т.к. перфокарты уже отмерли. Вот перфокарты - самые надежные! Их можно делать и металлическими и гранитными.