Как будто кто-то запрещает на лету конвертировать в другие кодировки. Но, так-то как с ходу распарсить XML с ходу по документации понять сложно. Если только гуглить. А для json'а есть хорошие Perl'овые модули и jq.

Ответ хейтера

Аргументы против XML автор и так уже привел, а вот аргументы «за» вызывают сомнения:

1) XML текстовый как раз для правок в обычном текстовом редакторе. В специализированных редакторах можно и какие-нибудь компактные TLV-шки править.

2) Язык моделей отлично делается под любой markup язык, как и валидатор по этим моделям. Другое дело, что у кое-кого в его любимой джаве встроена реализация всей этой мутотени как раз для XML. Но вот не надо тут рассказывать о преимуществе аудиокассет на компактами лишь потому что твой плеер кассетный.

3) Про курсорную/объектную работу с XML... я уже давно замечал что у джавистов все перевернуто с ног на голову, и они пишут объекты для XML, а не описывают в XML существующие объекты. Работа с большими документами должна вызывать трудности разве что на этапе их импорта/экспорта. Нафига хранить их сериализованными в рантайме!?

4) IBM пусть на своих мэйнфремах ворочает многогигабайтные XML-ины, если им так надо, а на десктопах/планшетах/мобилках за такое надо руки отрубать.

(т.е. документ управляет приложением, никакого заумного парсинга)

Марш учить матчасть. До просветления^Wобнаружения в любимом фреймворке того самого заумного парсера XML.

http://slonik-v-domene.livejournal.com/131569.html

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

7. Обязательный UTF8.

А в ini подобные можно грузить всё что угодно и слова хоть десятимегабайтной длины.

3. Вместо этого мы видим кучу всяких json, yaml, ini-подобных, тегированных, гибридных и прочих конфигов и форматов документов, которые принимаются приложением сразу с падением в случае ошибки (вместо оставления предыдущего состояния).

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

ты не указал названия удобных XML-редакторов. Это потому что их нет.

Так почему люди до сих пор не используют столь шикарный инструмент и хают его?

Потому что overbloated. Если делать human/machine readable - весьма себе вариант. Но если просто structured data passing - то тот же json выйдет сильно компактнее. И вот не надо тут про компрессию, помимо компрессии есть ещё затраты на десериализацию, а XML банально сложнее синтаксически.

Это европейский стандарт расширения розетки переменного тока menekes 40A до DC 50 кВт. Тогда провода AC выступают только для передачи данных, а заряд идет по толстой дополнительной паре. Так как японский chademo к тому времени стал де-факто стандартом, можно забить. Но вдруг VAG отчебучит...

Понимаешь, там даже can избыточен. Там банальный ttl нужен с четко описпнными хендшейками и статусами.

SOAP (слава богу помёрший)

Твои б слова да богу в уши. Как раз месяц назад прикручивал поддержку Salesforce, а там SOAP во все щели.

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

Это либо полный бред, либо совершеннейший говнокод. По хорошему, приходить должен только ОДИН тип объекта.

Следующая проблема - если ваш коллега добавляет поле, все мгновенно разваливается.

Если поле опциональное — не разваливается. Если не опциональное — то это так и так несовместимость по данным.

Protobuf — та ещё фигня, я сейчас его из проекта как раз буду выпиливать, но товарищ явно бредит.

не читаем для людей. Господа, вы хоть раз пробовали не в vi его править

нет, мы его не правим, мы его читаем

. Ну и тот же SOAP (слава богу помёрший)

Сам ты померший. Я каждый год его нахожу в новых местах. Поддержка в фреймворках/библиотеках есть, инструментарий есть. Вполне себе актуальный стандарт RPC.

7. Обязательный UTF8.

Ага, ага, смежники уже два дня не могут из ora через soap выгрузть в utf-8, все в 1251 гонят.

http://harmful.cat-v.org/software/xml/

Ну и тот же SOAP (слава богу помёрший)

сам ты помёрший :) Мы его постоянно впиливаем везде

На гос предприятиях еще не то впиливают. Там любят некрофильские технологии.

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

хмхм, и кто же эти, кто должны пометить и выкинуть? ты что ли? ))) В госпредприятиях Германии и США точно так же везде используется SOAP (инфа из первых рук - у меня там братан работает, зажигает на технологиях Microsoft), в том числе для новых проектов. И другие XML стандарты, например, BPMN

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

теперь, покажи мне IEEE стандарт на JSON Schema? Просто погугли что-нибудь типа «JSON Schema standard IEEE». И найдешь одну статью из IEEE Xplore (продающуюся за бабки), и пару их же докладов на конференциях, на которые участники собрали меньше косаря баксов

или замени IEEE на ISO/IEC, результат будет тот же - ничего

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

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

Работа с XML неудобна(по сравнению с JSON) и более ресурсоёмка.

кстати, по похожей причине зачастую выбирают и Java, потому что Java это не столько конкретная реализация языка, виртуальной машины, библиотек итп - это набор стандартов, демократически выбирающийся с помощью специального (тоже стандартизованного) процесса JCP (Java Community Process).

Это позволяет организациям запилить несколько вариантов реализации как самой Java (Oracle JDK, OpenJDK (что почти то же самое), Excelsior JET, Azul Zing, IBM J9, ...), так и отдельных библиотек - JPA (Hibernate, EclipseLink, OpenJPA, ...), JSF (PrimeFaces, RichFaces, ICEFaces, ...).

Last but not least, это означает что при составлении стандарта люди много думали и учитывали мнения ВСЕХ участников рынка. Для бизнеса это означает, что работать по правилам такого стандарта готово большинство подрядчиков, и этих подрядчиков можно между собой заменять без потери совместимости по протоколу и другим технологиям.

Олсо ту же технологию можно использовать для релицензирования и комбинации продуктов. Например, Oracle TopLink в качестве реализции JPA использует EclipseLink. Поэтому в разрезе JPA продукты TopLink и EclipseLink эквивалентны

перечитай сообщение выше еще раз. В любой большой организации работа с XML технологиями очень удобна. Не только в госах, в Microsoft, Apple, RedHat, Amazon, Facebook, итп - тоже используют XML. А то и чего поядреней =)

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

сразу же как твой стартам вырастет из 10 человек в 100 или 1000, и нужно будет отдавать работу подрядчикам, чтобы они закодили тебе отдельные компоненты по четко описанному ТЗ, так сразу и поймешь всё =) Подсказываю: например, в ТЗ можно указать полный XSD запроса, который должна обрабатывать система, которую будет делать подрядчик. И пусть он только попробует сделать не по XSD, или сказать что не знает что такое XSD - мигом отправится на мороз

Корпорации много чего используют.

Не надо тут ля-ля по поводу стартапа и кол-ва человек. Формат данных на то он и формат, а не неведома сущность, что его можно согласовать между двумя и более подрядчиками.

Именно поэтому в любых API, читай сервисах инфа отдается и в XML и в JSON. И на старый лад и на новый.

А ещё можно каждый байт блоба завернуть в отдельную пару тегов. Хотя для больших объёмов я это видел только в виде шуток.

вспомнил одну похожую шутку - рисунок разбить на пиксели и отобразить в виде html-таблицы. чувак вроде даже «конвертер» написал.

у меня JSON всегда использовался только для ВЕБ сервисов, использующихся в ВЕБ МОРДЫ. По одной простой причине - в браузере JSON является first class citizen. При этом никакого XML, конечно, наружу не отдается - только дебил будет тратить время на разработку одного и того же несколько раз. (Можно было бы погенерить XML предоставление из JSON или наоборот, но при этом генеренный вариант будет неудобным говном, а мы говно не предоставляем).

не знаю, про какие ты «любые API», у меня для внешних бизнесовых API всегда был в виде котнейнера SOAP/XML. За жизнь сменил несколько компаний их трех стран и разных предметных областей, везде SOAP. Еще пытались тот самый протобуф (ради сжатия в лоу-латенси сервисах), но не взлетело.

JSON в бизнесовой части поднимал только ради взаимодействия между своими же (написанными мной для себя) микросервисами, чтобы быстрее было накорячить прототип на Спринге. Но снаружи эти микросервисы выглядели как единая неделимая сущность/подсистема, поэтому всё в порядке. Если бы кто-то моим сервером логирования попытался что-то залогировать из чужой подсистемы, случилась бы беда - хотя бы потому, что у него не было бы классов, которыми нужно работать с этим JSON.

Json/ini выглядят по-человечески, xml - как говно. Остальное меня не волнует.

У меня. У меня. У меня. Да мы поняли, что у тебя. У других по-другому.

Так ведь привел же в пример кучу корпораций, которые используют XML. Показать, что Apple использует XML? Да у них половина операционки настраивается на них - та же медиатека iTunes :)

Ну а на всякую мелочь внимания обращать не стоит, не доросли еще чтобы мнение иметь

У меня. У меня. У меня. Да мы поняли, что у тебя.

ну мне есть что показать - например, мы делали Госуслуги, и там всё на SOAP. Или мы делали электронную медицинскую карту для минздрава, и там тоже SOAP (что неудивительно хотя бы потому, что она работает с Госуслугами). Или мы делали систему управления баблом просоюзов IUPAT, и там тоже SOAP, потому что его хочет американская налоговая.

теперь покажи свои проекты

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

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

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

Компу всё равно что парсить, а человеку ini приятнее во всех отношениях.

сам ты помёрший :) Мы его постоянно впиливаем везде

соап - это ентерпрайзнутый технологический аборт :-), а такие как вы попадают в программисткое чистилище.

ну мне есть что показать

А кто давеча в фейсбуке жаловался?

<...> нужно написать супер пупер сервис, обрабатывающий превосходящие силы противника в виде непрерывно люьющихся пачек XML/SOAP.
За час. На Windows. С гуглом и источниками пакетов типа Maven Central (или что вместо него будут использовать сишники). Прямо по ходу написания ТЗ несколько раз меняется.

В целом, конечно, все понятно: делай сложно и через жопу, тогда тебя сложнее будет заменить == спокойствие и достаток в старости. Только это не техническое преимущество)

Хотя бы потому, что без стандарта нельзя написать несколько библиотек на разных языках программирования, которые поддержали бы в точности один и тот же протокол

Это и со стандартом тоже далеко не всегда получается.

1. У нас не может быть неправильного конфига (только логически неправильного, но тут уже ничего не сделаешь). В схеме можно указать указать абсолютно всё, вплодь до того, какие стринг-параметры (даже регексповые) должны быть, какие типы данные, сколько их, названия параметров, обязательные и не обязательные паметры (и зависимости их друг от друга) и т.д.

я вот недавно парсил xml на питоне, и парсер(xmltree или etree непомню) падал от того, что в одном из параметров в значении был «&», почему божественный xml не защитил меня от такого? Точнее парсер работал пол года, пока человек не просивший этот парсер не начал пихать ему амперсанд.

И можно для не тру энтерпрайз программистов еще раз, чем всеже json плох, желательно с примером.

А причём тут XML, если у вас парсер реализован не по стандарту?

Это примерно тоже самое, что жаловаться, что раньше мне присылали картинки 200x200p , а теперь прислали 200x201p, дык ещё и с прогрессивной развёрткой и с EXIF, после чего мой парсер упал.

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

И можно для не тру энтерпрайз программистов еще раз, чем всеже json плох, желательно с примером.

Уже 10 раз написали: нету четкого стандарта, схемы - уёбищные, имеет смысл только для вебни (и только потому там - в стандартной поставке). И много чего ещё. Стивджобса выше почитай.

Плюс читать JSON километровый - это жопа. XML намного понятнее.

А причём тут XML, если у вас парсер реализован не по стандарту?

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

Стивджобса выше почитай.

Че его читать, я не столько против XML, сколько не пойму чем json хуже прям везде, в любом примере.

имеет смысл только для вебни

так может ты и слышишь об нечитабельности XML от 90% людей, потомучто им особых извращений не надо?

что в одном из параметров в значении был «&», почему божественный xml не защитил меня от такого?

<value>&</value> не валидный xml это покажет любой xml редактор. эксепшен при парсе в лоб получили правильно. это можно обойти, если написать свой sax парсер. «божественный xml» предоставил тебе все средства для того чтоб особзнать, легко найти, побороть эту (да и не только эту) проблему, но, понятно, только если наличествуют мозги.

сколько не пойму чем json хуже прям везде

биполярный взгляд на мир очень распространён, если ты хейтишь XML — значит ты «за» %protocolname% и наоборот, говоришь о преимуществах XML — значит %protocolname% «хуже прям везде»
у некоторых, такое биполярное мышление пациентов откровенно вызывает ассоциации со школьниками. по мне, так заслуженно вызывает.

неудобен и не читаем для людей
а в XML-редакторе

Нахрена, только тогда его было делать текстовым?

PNG неудобен и не читаем для людей
а вы пробовали его править в графическом редакторе?

Нахрена, только тогда его было делать текстовым?

Вероятно, чувак ты никогда не слышал про проблемы расширяемости бинарных форматов, endianess, версий форматов и интеграций между ПО. Плюс формат должен был предусматривать простую отладку и передачу данных между РАЗНЫХ приложений (вообще разных компаний), а также использование как потока и для конфигов. И с валидацией. И всё ок. Тем, кому не нравится, есть кучу вариантов (поддерживаемых той же явой) бинарных протоколов сериализации объектов.

Эту инфу невозможно проверить. Я тоже могу накнопать чего угодно и выдать за истину.

Эту инфу невозможно проверить, если ты забанен в гугле, лол.

Например, все российские государственные конторы *обязаны* общаться между собой через Систему Межведомственного Электронного Взаимодействия (СМЭВ). Включая полицию и другие компетентные органы, медицину, и так далее. СМЭВ работает на SOAP. Если лень читать руководство (то еще удовольствие), можно найти SOAP на первой же странице, описывающей как залогиниться в СМЭВ.

Нетрудно понять, что однажды адаптировав 1 протокол, никто уже другие протоколы и не пробовал использовать :) Это уже проверить сложнее, но можно просто довериться логике. А можно снова погуглить, например по поводу Медицины. По запросу «иэмк soap» разу видим что Электронная Медицинская Карта (ИЭМК) работает на SOAP. То есть soap выставляется не только как внутренний бизнесовый протокол внутри сервера, но и как протокол для внешних клиентов

и еще немного гугла «мвд soap» отсылает на в Консультант Плюс, который указывает на soap-эндпоинты МВД

короче, можно долго продолжать, но с помощью гугла ты сам осознаешь масштабы внедрения. Масштабы - вся Россия. Каждая чертова госконтора. в которую ты завтра зайдешь утром за чем-нибудь (например, Почта России или ЖЭК) - все они работают на соапе

Все твои сообщения можно заскринить, распечатать и показывать тем, кто спрашивает «что такое субъективное восприятие ?». Плевать что там используют гос. конторы и как они обязаны общаться между собой.

Масштабы - вся Россия

<sarkasm>Ого, вся Россия! Ничего себе. Это даже больше, чем весь мир.</sarkasm>

разговаривал со своим знакомым из гугла. Цитирую:

слава Богу soap сдохла

Я имел в виду, кто эти «французские курильщики», которые такое устроили?

Так почему люди до сих пор не используют столь шикарный инструмент и хают его? Просто не осилили?

просто дебилы. не осилить xml невозможно.

вы хоть раз пробовали не в vi его править

Я его в vim правлю. Никаких проблем не наблюдаю.

Почему в разговоре xml это почти всегда конфиг?
Около миллиарда редактируют xml в удобных редакторах и вполне довольны.