.NET und C# ohne Web?
А эачем это нужно?
Для взаимодействия с разными вендорами.
Ну вот простейший пример - наше приложение обрабатывает входящие сообщения, нам из этого сообщения важны 4 поля, все остальные данные нас не интересуют. При этом есть несколько производителей оборудования, которые хотят отправлять нам сообщения. Какое решение? Мы делаем XSD и отправляем его вендорам. Очень удобно - мы делаем спецификацию и требуем ее исполнения.
Ну общается бек с фронтом, послал данные, в чем проблема-то?
Проблема в том, что бек и фронт зачастую делаются в разных командах и надо как-то договариваться о формате данных. Я уж не говорю о том, что данные существуют не только в вебе.
Меня. У меня бывают такие объемы ХМЛа, что обработать можно только чем-то типа сортировки слиянием...
Простейший пример - дифф и мерже - ну хотя бы а 100-200 mб...
Ну у тебя и код генерится шаблонами :) Давай по чесноку - твои задачи и броблемы сложно назвать типичными юз-кейсами ;)
веб это узкая область?
Это узкая специализация. В вэбе много чего делается, но веб - это довольно узкая область в программировании.
Тем не менее для JSON есть и схема и валидирование.
Есть и этих схем и валидатором ЕМНИП даже больше одной. И все они являются разработкой энтузиастов и требуют согласования. В мире XML такого бардака нет.
Прежде чем спорить стоит читать сообщения целиком.
"YAML используется как замена .properties"
Почему-то один ты собираешься читать и парсить последовательно, а другой - грузить разом и создавать дополнительный набор данных...
И на этом основании заявляешь что одно хуже другого?!!
Потому что кто-то не в курсе про все возможности XML. Включая XPath или idref. Часто без DOM не обойтись, SAX не хватает. Ну и парсить XML сложнее, даже SAX жрёт больше памяти и времени.
Вот только проблема - чел на анализе 5-6 килобайта все одно сдохнет...
Какой-то у тебя тупой человек. 5-6 килобайт это ну, пусть 200 коротких строчек. И "анализировать" их не надо - надо посмотреть парочку значений.
Вижу - недостаток. Например, при экспорте из систем, где дальше EBCDIC
Это исключительно твои проблемы. Хосты даже в немецких банках и страховках вымирают, и ориентироваться на них - верх тупости.
Ну и какбэ latin-1 тоже имеет свои проблемы при обмене с мейнфреймами. Короче садись, два. Высосанный из пальца недостаток не канает.
сложно назвать типичными юз-кейсами ;)
------
Как раз типичная ситуация на любом среднен и крупном предприятии...
Другой вопрос - чистые прикладники редко заморачиваются этими вопросами
Ибо для них производительность системы определяется количеством систем в кластере...
Какой-то у тебя тупой человек.
-----
Увы, но он такой и есть...
Часто без DOM не обойтись, SAX не хватает.
-----
Это - аргумент. Сильный. Правда в пользу ХМЛ. В силу того что ЯМЛ в дерево конвертируется сложнее.
И, кстати, не встречал задач, в которых нельзя обойтись без ДОМа.
А обратные - когда ДОМ не проходит уже приводил.
"YAML используется как замена .properties"
-----
Т.е. ты подтверждаешь, исходное что утверждение верно при размере ЯМЛа в 10 строк.. 
Как только потребуется что-то более крупное - придет полярная лисичка...
даже в немецких банках и страховках
------
Ты пропустил авиацию - там оно живее всех живых...
парсить XML сложнее
-----
Хи-хи...
Т.е. вот прямо так - сложнее парсить полностью размеченный документ...
Предлагается "упростить" процесс исключив из раметки маркеры окончания элемента...
Во-первых, это не преимущество YAML, а скорее недостаток конкретного парсера XML.
Не совсем. XML сложнее парсить. Так что и преимущества формата.
кого в современном мире волнует память для DOM
Ха-ха. Всех, кому приходят жалобы от клиентов, мол, открыл две ваших странички, и щё не работает. Смотрим - а хром сожрал все его 8 гигов памяти.
Потому что "программизды" тоже думали "а кого волнует память" и вхренячили 500 меговый xml. А чо? По локальной сетке, на десктопе с 32 гигами всё быстро работает.
В-третьих, я не очень хорошо представляю себе проект, в котором скорость десериализации будет иметь какое-то более или менее серьезное значение.
А зря. Год 2019. Смена формата с XML на JSON на одной страничке сэкономила нам около 10 секунд времени загрузки. Яваскрипт, понимаешь ли. Пора прекращать думать десктопами. ПО крайней мере на ближайшие 10 лет. Потом опять наверняка "откроют" что делать все приложения в браузере - тупо, надо улучшать установку модулей, станет модно уменьшать "сетевой футпринт", и может быть даже забудут жабаскрип как кошмарный сон, блин.
Да, в мире приложений для мобил XML тоже не канает. Уж слишком большой оверхед. Разница в размерах между представлением тех же самых данных в JSON и XML может быть 2-3х кратная.
Г5 эго здорово, но на GPRS принимать 500 кб или 200 очень ощутимо по времени.
А вот отсутствие стандартной возможности описать данные и валидировать их - серьезная проблема (в том числе и для JSON)
Добро пожаловать в мир будущего! JsonSchema вместо XmlSchema, OpenAPI как замена WSDL.
Что самое смешное, JSON выходил на сцену под кукареканье "свобода! чо хочу то и леплю! никаких скучных ошибок валидации! надо добавить 10 новых полей - добавляем!" Не прошло и 10 лет, как попугайчики стали перерисовывать XML Schema для своего JSON (и придумывать TypeScript для жабаскрипта).
Подводя итоги. И XML и YAML (и JSON как подмножество YAML) имеют свою нишу. XML сейчас "не секси", JSON - супермодель. Но однозначной замены той же автоматической валидации или приличной генерации кода из схемы ни для JSON ни для YAML нет. Даже для явы с генерацией кода из JsonSchema всё достаточно хреновенько. Есть что-то работающее, но как только начинается что посложнее юзера с именем и возрастом - лезут проблемы.
Для общения клиент-сервер сегодня я бы взял JSON. Сервер-сервер сравнивал бы JSON с XML.
ПыСы. Для котика - с z/OS мы общаемся через CICS и MQшные очереди JSON-овскими (ага, UTF-8) сообщениями. Хост справляется их перекодировать в UTF-EBCDIC или UTF-16.
Предлагается "упростить" процесс исключив из раметки маркеры окончания элемента...
На досуге почитай спецификацию XML. Откроешь для себя много интересного. И сравни её со спецификацией YAML. Или лучше JSON. Его ещё проще парсить.
Да даже разницы между аттрибутами и субэлементами нет. Потом как аттрибутов нет.
Проблема в том, что бек и фронт зачастую делаются в разных командах и надо как-то договариваться о формате данных. Я уж не говорю о том, что данные существуют не только в вебе.
Ну правильно, в JSON есть поля
{"AAA":{...},"BBB":{...},"CCC":{...}}
это на сколько идиотами должны быть разрабы в командах, если они не договорились, что будет лежать в форматах для AAA, BBB, CCC? Тут валидация адекватности разрабов важна, а не городить "прогграммирование ради программирования".
Все так и не понимаю для чего валидация нужна, кроме надуманных случаев когда команды друг другу создают проблемы. Может я все-таки что-то упустил и есть какой-то реально нужный пример?
Ну правильно, в JSON есть поля
{"AAA":{...},"BBB":{...},"CCC":{...}}
Ога. А есть совсем другой JSON в котором может быть 200 разных полей. Человеческим языком описывать что в каждом допустимо - легко выливается в документ страниц на 50-100. И кто ж его читать будет, пока молотком па пальцам не заставишь?
это на сколько идиотами должны быть разрабы в командах,
Намного, намного большими чем вы сможете себе вообразить. Передать 0 и 1 или WAHR / FALSCH вместо оговоренных true/false? Как два пальца. "А мы так привыкли", "а чо? Это тоже булевские значения"
Все так и не понимаю для чего валидация нужна, кроме надуманных случаев когда команды друг другу создают проблемы.
Слышали про принцип fail fast? Как считаете, проверять входящие данные в принципе нужно?
Ну и схема она не только про валидацию. Генерировать код можно, а не писать ручками. А можно генерировать тысячами правильные запросы, чтобы протестировать на нагрузку.
почитай спецификацию XML.
-----
Зачем повторять то что уже изучено?
Потом как аттрибутов нет.
-----
Где-то оно хорошо, а часто - вай-вай...
Одна из текущих задачек.
Есть несколько (миллионов) наборов шаблонов, каждый из которых работает со своими данными.
Клиент подготавливает и присылает данные в каких-то из (ему) известных форматов.
Задачка - выбрать набор шаблонов пригодных/доступных клиенту для решения его задачи
и трансформировать полученные данные в приемлемый для использования формат.
При этом Я не хочу что-либо писать руками более 1-го раза.
Ну так что будем пользовать - ХМЛ, ЯМЛ, ЖСОН?
П.С. Что Я слегка сменил заявленную целевую область Я вполне осознаю.
это на сколько идиотами должны быть разрабы в командах
-----
Да ни на сколько.
Неужели так сложно представить ситуацию, когда одна из сторон использует регламентированный инструмент и максимум что может - выполнить экспорт данных с его помощью. При этом не имея ни малейшего представления не только об том в каком формате будет выполнен экспорт, но и не понимая что форматы могут быть разными и зависят не только от действий оператора...
Ну это не считая того, что могут быть повреждения при транспортировке/трансформации.
Все так и не понимаю для чего валидация нужна
-----
В России у тебя спрашивают паспорт при покупке билета на паровоз.
Поверь - ни один шахид нацеленный на подрыв поезда не понимает зачем нужно предъявлять паспорт при покупке билета...
Да ни на сколько.
Если есть сомнения в протоколах и форматах - надо проверять консистентность данных до начала использования. Если нет, то зачем этот огород-то? Вся эта возня - это программирование ради программирования.
Единственный еще хоть как-то притянутый за уши вариант - проверка того, что генерилось с помощью автоматического написания, если, например, AI прочитал текстовую спецификацию, и послал ответ как смог и все это - в реальном времени, хотя, ИМХО, это просто надо отладить и только потом использовать.
PS: у меня в аппаратуре 11 различных типов ембеддед процессоров, серверов и архитектур с довольно сложной топологией общаются именно JSON ом, иногда бинарным, причем так, что иногда один юнит должен послать другому через третий, и как-то никогда не возникало нужды делать такую
валидацию, но да, всегда следил, чтобы все, кто это разрабатывают, придерживались одной и той же документации и спецификации и, где надо, стояли конверторы если спецификации отличаются. Проблемы с потерями данных всегда разруливались по аналогии с CRC, в некоторых случаях с избыточными кодами с возможностью для восстановления.
надо проверять консистентность данных до начала использования.
-----
Внешний источник априори не является надежным.
Внутренний - лучше, но тоже не гарантирован.
Так что данные перед использованием надо проверять.
И мне вот интересно как ты будешь "проверять консистентность данных" которые тебе будут поставляться после окончания разработки.
Ну вот написал ты обработку. Все работает. А билли - накатил апдейт и поменял формат. Без уведомления, без новой спецификации.
Ну вкачал ты данные... много вкачал... месяц-другой вкачивал... потом вылезло что что-то где-то выглядит не так как ожидалось.
Ну как - будешь это разгребать или лучше получить отлуп сразу после апдейта?
и как-то никогда не возникало нужды
-----
Нда... упорный...
Валидация это не когда все работает.
Валидация это когда отлавливается источник проблем до того как проблемы возникнут.
Нужно тебе это или тебе это не нужно - это уже твои заморочки.
Для меня валидация, если есть возможность отвалидировать данные со стороннего источника, - благо, предупреждающее возможные проблемы.
и как-то никогда не возникало нужды делать такую валидацию
ну и что будет если какой-то новый прибор по ошибке пошлет в старый не те данные? чет не хотел бы я таким пользоваться )
надо проверять консистентность данных до начала использования
ну и какой в этом смысл, ну проверил я на клиенте, все нормально, отправляю на сервер, потом вдруг окажется что не так проверил, мягкое с теплым сравнивал, а нужно было разноцветное с квадратным. Или вообще бэкэнд обновился, а на клиенте одну функцию которая после дождика в четверг вызывается, забыли обновить, и что теперь, на сервере без проверки что-то использовать?
А билли - накатил апдейт и поменял формат.
я уже писал выше, если данные не надежны, в чем проблема их распарсить и проверить то ли пришло, или нет.
Но начерта эту проверку притягивать в синтаксис JSONа или аналогичных фоматов, ибо проверку в общем случае все равно сделать невозможно, а костыли в синтексисе только создадут рабочие места для быдлокодеров, которые с пеной у рта будут рапортовать начальству, что они все автоматически валидируют, а на поверку, все будет сыпатся не через месяц, а через год, но, еще больнее.
на столько узкая, что основной поток вакансий это веб ) уот и сравнение, по рынкам
Ты понимаешь, что даже если в вебе будет 90% вакансий, это все равно ниша? И при этом довольно узкая ниша. Посмотри даже на свою картинку, веб там - это одина из девяти областей.
PS: бэк-энд далеко не всегда связан в вебом.
Не совсем. XML сложнее парсить. Так что и преимущества формата.
Не знаю, почему XML должен быть сильно сложнее JSON'а. Но возможно у тебя больше опыта в распарсивании текста...
Ха-ха. Всех, кому приходят жалобы от клиентов, мол, открыл две ваших странички, и щё не работает. Смотрим - а хром сожрал все его 8 гигов памяти.Потому что "программизды" тоже думали "а кого волнует память" и вхренячили 500 меговый xml. А чо? По локальной сетке, на десктопе с 32 гигами всё быстро работает.
Боюсь, что 500 меговый JSON или YAML точно также поставит систему раком. Тут проблема не в формате.
Смена формата с XML на JSON на одной страничке сэкономила нам около 10 секунд времени загрузки. Яваскрипт, понимаешь ли.
Не понимаю. На чем была экономия? На парсинге? На передаче? Это ж сколько надо передавать, чтобы парсер больше 10 секунд работал? 500Мб? :)
Пора прекращать думать десктопами.
Я в веб пока что не суюсь :)
Добро пожаловать в мир будущего! JsonSchema вместо XmlSchema
Я даже пробовал это использовать. Но был послан вместе с готовой схемой с аргументом, что это нестандартизированное нечто и надо договариваться с другими командами об использовании именно этого инструмента
:)