Ну правильно, в JSON есть поля{"AAA":{...},"BBB":{...},"CCC":{...}}

Проблема в том, что AAA обязательно должно присутствовать и значение должно быть числовое, BBB - опциональное поле и тип строка, но не больше 100 символов, CCC - обязательное поле и перечисление, а есть еще DDD - bool и еще 100 других полей. Можно конечно все это описать в PDF, но кто их читает? ;) Я уж не говорю о контроле, т.к. в какой-то момент команда A решает, что поле BBB теперь обязательное, рассылает всем PDF и валидуруй каждое поле в кучном режиме :)

это на сколько идиотами должны быть разрабы в командах, если они не договорились, что будет лежать в форматах для AAA, BBB, CCC? Тут валидация адекватности разрабов важна, а не городить "прогграммирование ради программирования".

Ну вот мы например фирма в Германии даем спецификацию фирме в Японии. Мы друг с другом вообще не разговариваем, в лучшем случае диалог есть при посредничестве клиента. В хорошем варианте, клиент передаст нам е-мыл другой конторы и мы сможем запросить их спеки и отправить свои. Но обычно мы даем спеки клиенту, а клиент пересылает их дальше. Так что никаких договоренностей в большинстве случаев нет.

Да и в пределах одной фирмы договоренности есть далеко не всегда. Кто-то просто предоставляет интерфейс и все.

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

XSD файл - это контракт (в терминах C# это интерфейс) по которому общаются (программно) несвязанные меджу собой модули. Имея на руках XSD ты всегда можешь проверить соответствует ли твой код заданному контракту. Если два модуля не работают друг с другом, то всегда можно определить почему. При этом определить можно в автоматическом режиме.