Щас не хватает времени. Но я до пятницы проверю. И если это правда - то создам топик на тему
Xml-Schema vs Json-Schema. Who is stricter?

Почему? JSon readers существуют. И я думаю что их много. Просто CSV регламентирует
некую однородность записей а JSon - в общем случае - нет.

Да. Все верно. Я-же написал - если "делать запросы" к содержимому. Типа SELECT узлы WHERE какое-то свойство
e.t.c.

JSon в общем случае не является заменой XML, т.к. в последнем заложено больше семантики, больше смыслов.

Любые попытки заменить XML на Json сегодня сродни попыткам например заменить реляционные DBMS на NoSQL
системы. В частных случаях это срабатывает но в общем - мы теряем. Теряем возможности и смыслы которые были
заложены создателями изначально.

Как в данной теме смешались стандартизация и человекочитаемость? Это две разные мои
мысли, которые зачем-то кто-то спутал.

Ради бога. Деайте тсв. Развеж я вас остановлю?

Это ... даже несеръезно. При чем здесь split? И при чем здесь какие-то "осталые" сишники?

(руки вверх)

Всё ты победил! Делай на сплитах! Мне просто эта тема не интересна.

Архитектурно, на этапе создания стандарта в XML были заложены namespaces.
Это позволяло в 1 документ включать разные расширения таким образом что твой парсер
может обрабатывать только свои (известные теги) а неизвестные просто пропускать.
В Json такое сделать невозможно. Или как-то можно но наверное с потерей смыслов.
Namespaces имеют полезное применение в Java frameworks в части конфигураций.

Трансформация документов. Ты можешь создать XML-содержимое которое обработается
браузером и к нему применится XSLT скрипт который адаптирует контент к HTML со стилями
например. Эта фича редко применялась. В основном на back-end, хотя IE 100% ее поддерживал
в 2000 годах точно. Сам скрипт должен быть доступен по http:// или file:// чтобы двигатель
трансформации его увидел. По аналогии с #include в C++.
Тоесть - никакого JavaScript а просто трансформация языком очень высокого уровня. На
эту тему у нас даже есть подфорум https://www.sql.ru/forum/xml . Я немнжко не в теме
т.к. последний раз работал с этим очень давно и многое поменялось. Но вот что я помню - то рассказал.

Обработка инструкций. Сейчас насколько я помню эта фича отключается из-за безопасности. Но вкратце,
в хедер XML можно включать команды операционки например. И они по идее должны исполнятся в момент
открытия файла. Как это полезно исопльзовать - ХЗ но стандарт есть.

Синтаксические удобства для публикации комментариев и блоков не-структурированного содержания (CDATA).

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

Это всё - смыслы.

Тоесть если подытожить - то XML является наиболее строгим описательным способом для данных и знаний.
Для JSon повторить подобное наверное тоже возможно - но придется придумывать НАД-стандарты сверху
над простым и примитивным JSon. В рамках одной рабочей группы или проекта это возможно, но если
топить за интеграцию между проектами и между кастомерами - то лучше наверное XML. Так проще. И меньше
будет технических споров и недо-пониманий на этапе простого согласования формата RPC например.

Что мешает пропускать неизвестные значения в JSON?

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

Прочитал название значения, не смог распознать название - пропустил всё до конца значения.

Точно так же в XML: прочитал открывающий тэг, не смог его опознать - пропустил всё до
закрывающего тэга.

Где проблема?

Нет декларативности. В случае с явным указанием namespace - читающий (допустим это человек) может
в документе глазами увидеть доменную модель которая доступна для интерпретации.

В случае хардкодом этой логики в тело XML/Json парсера - эта информация для читающего неизветна. И ему надо
будет консультироваться с L3 например чтобы понять почему тег <credit:amount> или "credit_amount" не виден в системе.