LINUX.ORG.RU
ФорумTalks

Почему люди хейтят XML?

 , , , ,


1

1

Я постоянно слышу, что XML слишком раздут, неудобен и не читаем для людей. Господа, вы хоть раз пробовали не в vi его править, а в XML-редакторе с подгруженной схемой? Где узлы (из указаний схемы) сами предлагаются и на 90% генерируются при создании, остаётся только параметры вписать (которые будут немедленно валидированны по схеме).

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

1. У нас не может быть неправильного конфига (только логически неправильного, но тут уже ничего не сделаешь). В схеме можно указать указать абсолютно всё, вплодь до того, какие стринг-параметры (даже регексповые) должны быть, какие типы данные, сколько их, названия параметров, обязательные и не обязательные паметры (и зависимости их друг от друга) и т.д.
Т.е. мы изначально можем не верифицировть конфиг своим кодом при наличии корректной схемы.
2. Далее не надо писать шаблонные регенараторы конфигурации для систем автомации, можно легко заменить нужный параметр на лету (и проверить, что всё корректно). А если и писать, то гораздо легче.
3. Вместо этого мы видим кучу всяких json, yaml, ini-подобных, тегированных, гибридных и прочих конфигов и форматов документов, которые принимаются приложением сразу с падением в случае ошибки (вместо оставления предыдущего состояния).
4. XML полностью стандартизирован. XEP и ещё несколько дублирующих стандартов.
5. XML БД, XPath.
6. Про работу с большими документами, которые, якобы, занимают кучу памяти. Кто-то просто не осилил курсорную или объектную работу с XML. Например, как в XMMP. Так называемые «бесконечные документы). Мало того, например, в яве, можно очень удобно повесить на поступление данных из файла (или сокета) обработчики в зависимости от поступающих данных на которые они будут реагировать, т.е. фактически срабатывание методов будет привязано к поступающему документу (т.е. документ управляет приложением, никакого заумного парсинга). При этом сохраняются только родители, а все обработанные листы выгружаются из памяти. Работает ооочень быстро, спросите у IBM с многогигабайтными XML-доками. И не надо писать никакой логики верификации - схема автоматически сама всё проверит (и можно поставить обработку эксепшенов)
7. Обязательный UTF8.

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

Перемещено leave из development

Ты так пишешь, будто xml без схем не бывает.

Shadow ★★★★★ ()

Два чая этому господину. Меня тоже тошнит от всяких новомодных yaml конфигов. Да и валидация json тоже малоприятная вещь.

Deleted ()
Ответ на: комментарий от Shadow

Ты так пишешь, будто xml без схем не бывает.

Я ж в низу написал: «Просто не осилили?»

ktulhu6662 ()

у меня сложилось впечатление, что волна хейта XML пошла после форса семантик веба и его провала, где-то в 2007-2010-х.
а теперь это мэйнстрим и инерция.

system-root ★★★★ ()

а в XML-редакторе с

100% людей правят XML только время от времени. Т.е. ни у кого нет специализированных редакторов и каких-то там схем. А в обычном редакторе XML многословен и некрасив.

JacobTwoTwo ()

Никогда не хаял XML, чаще всего для схем использую JSON, считаю вопрос ненужным и неинтересным выбором вкуса.

Octagon ()

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

Бред какой-то, как это связано с форматом вообще?

Ну и да, обычно ни схем, ни редакторов специализированных нет

Gary ★★★★★ ()

С одной стороны его хают потому что не привыкли.

С другой стороны схема есть и для json который все-же приятнее читать и писать ;)

grim ★★★★ ()

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

Потому что его пихали куда надо и куда не надо. Модно же. Из-за этого стало модно его ругать. Ну и малолетки за модой следят строго - раз ругают «зачит юзать зашквар» и пошло поехало. Ну и тот же SOAP (слава богу помёрший) выглядит не менее ублюбски, чем конфиги на json.

vtVitus ★★★★★ ()

XEP и ещё несколько дублирующих стандартов.

Боюсь предположить названия дублирующих стандартов.

ashot ★★★ ()

Мои претензии следующие:

1. XML даёт оверхед по размеру документа за счёт наличия закрывающего тега;

2. Неоднозначность в оформлении - куда мне пихать параметр b объекта a, в child или в attribute. Ну я то ладно, решу, раздражает вычитывать чужие доки, чтобы посмотреть куда писать значение b;

3. Отсутствие записей вида ключ-значение. Вместо них есть суррогат в виде child, где надо бегать и искать позицию ключа, чтобы найти значение, при том, что большинство либ потоковые или в виде node-attr. Опять же, неоднозначность и по разному составляемые XML;

При этом схема документа не является неотъемлимым атрибутом XML и может быть валидирована для JSON (наверное и для yaml, то не пользуюсь им). Опять же, JSON можно точно так же читать\писать стримом. При этом человекочитаемость у XML сильно хуже чем у JSON (из-за того самого оверхеда в тегах).

А по поводу ini я могу сказать следующее - простейший ридер ini файлов с секциями занимает 15 строк на python и ~150 на C++. Поэтому он ещё используется в небольших проектах, т.к. есть header only библиотеки.

Плюс ко всему, JSON напрямую ложиться на структуры данных скриптовых ЯП, а c XML не всё так однозначно из-за упомянутых выше пунктов 2-3.

Norgat ★★★★★ ()

Почему люди хейтят XML?

Вопрос опоздал лет на 10. Как там в криокамере было?

Dimez ★★★★★ ()
Последнее исправление: Dimez (всего исправлений: 1)

Основная проблема XML в том, что он часто используется в качестве промежуточного формата для обмена или хранения данных. В программе данные представляются в виде массивов и словарей. В XML используется древовидная модель данных, которая не отображается напрямую. Приходится добавлять новую сущность: XML Schema и генерацию кода по XML Schema. В общем и целом получается гораздо сложней, чем, например, с JSON, когда структура данных напрямую ложится на формат JSON и так же читается без каких-либо промежуточных схем. Когда XML используется по своему прямому назначению: как расширяемый язык разметки, он вполне удобен.

Ну и да, чтобы эффективно использовать XML, надо много чего выучить. Многие не понимают, зачем им это делать, если можно гораздо проще.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)

1. Жирный. Куча оверхеда.

2. JSON приятнее. YAML менее приятен из-за пробелов, но тоже ничего.

3. В JSON больше всяких типов данных - и тебе список пожалуйста и объект и что угодно в общем, при этом нет сотни тонн <item></item>.

Короче И - избыточность.

XML забил на бритву Оккама и за это его судьбинушка жостко расчленила на куски и съела.

hlamotron ()
Ответ на: комментарий от Legioner

Ну и да, чтобы эффективно использовать XML, надо много чего выучить. Многие не понимают, зачем им это делать, если можно гораздо проще.

Тема сисек не раскрыта. Пиши ещё.

ktulhu6662 ()
Ответ на: комментарий от hlamotron

XML забил на бритву Оккама и за это его судьбинушка жостко расчленила на куски и съела.

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

ktulhu6662 ()

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

Мне кажется или это программист виноват, а не формат конфига?

l0stparadise ★★★★★ ()

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

lenin386 ★★★ ()
Последнее исправление: lenin386 (всего исправлений: 1)

У XML свои преимущества, у json - свои. Например, для json необязательны XML-редакторы с подгруженной схемой. А вот XML править в блокноте - то ещё удовольствие

tiinn ★★★ ()

Что за редакторы? А то я вот собираюсь взяться за перенос цветовой схемы в ST3, а там XML. Можно ли воткнуть твои схемы в тот же ST3 что бы в нём же и перенести цветовую схему?

Deleted ()

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

Valeg ★★★ ()

Согласен с доводами.

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

Часто ли ты видишь взвешенную оценку плюсов и минусов чего-либо? Люди ленивы.

lochness ()
Ответ на: комментарий от JacobTwoTwo

Excel при наличии схемы правит отлично. При отсутствии - адский ад.

Shadow ★★★★★ ()

Парсер INI - 20 строчек почти на любом языке. Парсер XML с валидацией и прочими схемами - ...

mv ★★★★★ ()

Я хейчу xml, когда вижу, как SOAP используется для передачи и хранения бинарных блобов. Да и вообще SOAP много где не нужен. Кстати, когда я пытался запустить проищводство зарядных станций для электромобилей, встретил прекрасное. В большинстве стандартов обмен данными идет по CAN, гальванически развязанной. Курильщики из Франции протолкнули такое: отдельно от силовых кабелей по стандарту передачи данных по электросетям устанавливается tcp/ip соединение. Автомобиль поднимает свой http, зарядка поднимает свой http. И вот get'ами они друг у друга берут xml файлы, где лежит то, что обычно по CAN гончют. Как такое не хейтить?!

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 2)
Ответ на: комментарий от lochness

Часто ли ты видишь взвешенную оценку плюсов и минусов чего-либо? Люди ленивы.

И, судя по треду, ещё тупы и не образованы. Не знают, как правильно XML-поток обрабатывать, чтобы памяти не жрало, не знают про схемы и XML-редакторы, не знают про энтерпрайз, не знают, что в M-to-M XML почти всегда жмётся, если он слоновьих размеров или поток.
Эх... :( Где же найти более достойное сообщество? Кстати, не хочешь ко мне в личку добавиться (контакты в профайле)

ktulhu6662 ()
Ответ на: комментарий от Shadow

Я хейчу xml, когда вижу, как SOAP используется для передачи и хранения бинарных блобов.

Ну иногда в XML можно бинарные блобы в base64 вставлять. Но это крайний случай, когда надо расширить уже имеющуюся систему (например, прикладывать файлы к ЭЦП-подписываемому XML-документу и передавать ТОЛЬКО его).
А вообще это жопа.
Добавляйся ко мне в контакты, они в профиле.

Как такое не хейтить?!

А чего тебе не нравится? Стандартизированно, уровни разделены, физический уровень защищен от электропроблем, канальный - индустриальный, IP/TCP/HTTP предоставляют классический стек и простую совместимость и мультивендрость. Я бы только https с клиентской аутинтификацией добавил бы, чтобы гарантировать безопасность. А тебе что не нравится?

ktulhu6662 ()
Ответ на: комментарий от Gary

Бред какой-то, как это связано с форматом вообще?

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

ktulhu6662 ()

XML слишком раздут

Он объемнее того же json.

неудобен и не читаем для людей.

Так он и не должен быть читаем для людей.

Вместо этого мы видим кучу всяких json, yaml, ini-подобных

Это что-то плохое?

тегированных

А xml он какой?

с падением в случае ошибки

Оно не для людей, там не должно быть ошибок бай дезигн.

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

Используют же. Навскидку точно не вспомню, «Парус», вроде хранит конфиг в xml. «СправкиБК+» сохраняют декларации в нем же.

kravzo ★★ ()
Последнее исправление: kravzo (всего исправлений: 1)

о, до толксов уже дорос. не за горами и бан.

registrant ★★★★★ ()

JSON нативный во многих языках. Его просто элементарно парсить. Yaml - удобен для написания тех спецами, где один yaml файл не содержит более 1000 строк.

JSON для конфигов используют уже все продвинутые компании типа Mojang. XML - прошлый век, очень многословен и ставить плагины для XML синтаксиса/структуры - никому не вперлось, если есть другие альтернативы.

Когда вижу xml для конфигов - аж челюсть сводит, настолько он неприятен.

menangen ★★★★★ ()
Ответ на: комментарий от JacobTwoTwo

100% людей правят XML только время от времени. Т.е. ни у кого нет специализированных редакторов и каких-то там схем. А в обычном редакторе XML многословен и некрасив.

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

stevejobs ★★★☆☆ ()

Ты еще про пространства имен забыл (без этого я с json ом вешаюсь).

dmxrand ()
Ответ на: комментарий от ktulhu6662

XML - не просто формат, это набор стандартов, методов и бест-практисов. А все эти говностандарты от лишней запятой или таба падают.

Каким редактором править XML?

ult ()
Ответ на: комментарий от Norgat

1. XML даёт оверхед по размеру документа за счёт наличия закрывающего тега;

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

2. Неоднозначность в оформлении - куда мне пихать параметр b объекта a, в child или в attribute.

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

где надо бегать и искать позицию ключа

так в любом формате надо бегать, если парсер потоковый? На то он и поток, что читает с линейной сложностью. Не?

При этом человекочитаемость у XML сильно хуже чем у JSON (из-за того самого оверхеда в тегах).

если JSON из трех строчек а если из трех тысяч строчек - то всё наоборот :)

важно, что подсветку тэгов, фолдинг блоков, переход по ссылкам по ctrl+клик и так далее - всем этим занимается IDE

у меня просто километры кода, написанного на XML (всякий спринг и так далее), и рядом есть всякое говно того же толка написанное рубистами. Так вот, когда код на YAML на руби превышает несколько страниц, мне плохеет серьезно. Исключение, наверное, Ansible - но это потому что админы не умеют пистаь на местном ямле сложный код

stevejobs ★★★☆☆ ()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от system-root

волна хейта XML пошла после форса семантик веба и его провала, где-то в 2007-2010-х

Раньше. Где-то в 2002..2004 гг. XML уже вовсю хаяли.

KRoN73 ★★★★★ ()
Ответ на: комментарий от system-root

А чтонибудь опенсорсное есть? А то иногда надо, а искать лень...

dmxrand ()
Ответ на: комментарий от Norgat

Мои претензии следующие

У меня к XML одна серьёзная претензия. Без схемы невозможно отличить одиночное значение от одиночного элемента массива. И когда тебе приходит XML-файл, часто кроме него больше ничего нет. И такая неоднозначность способна серьёзно обломать работу с будущими файлами...

Отсюда же претензия поменьше — не существует простых xml_decode() на манер json_decode().

KRoN73 ★★★★★ ()
Ответ на: комментарий от ktulhu6662

То-то, он в яве используется, любой бизнес-логике, электронных документах и конфигах энтерпрайзного софта.

Это всё legacy. На новых платформах XML начали избегать лет 15 назад и чураться лет 10 назад :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от ult

Мне хватает того, что есть в Эклипсе и Идее, но можно например заюзать Oxygen (https://www.oxygenxml.com). (таблетки не проси, сам найдешь)

stevejobs ★★★☆☆ ()
Ответ на: комментарий от stevejobs

простой может быть не больше 30 секунд в год по SLA

Снимайте фильм «успеть за 30 секунд»

Xwo ()

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

Gargamel ()

Вот ведь какая штука. Без спец. редактора XML говнище, поскольку его нельзя ни читать, не редактировать. А со спец. редактором XML говнище, поскольку тогда можно использовать многие другие форматы, и любой из них будет лучше XML во всём. Начиная с того же protobuf:

Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:

  • are simpler
  • are 3 to 10 times smaller
  • are 20 to 100 times faster
  • are less ambiguous
  • generate data access classes that are easier to use programmatically

и заканчивая всякими ASN.1.

slovazap ★★★★★ ()
Ответ на: комментарий от Shadow

Кстати, когда я пытался запустить проищводство зарядных станций для электромобилей, встретил прекрасное. В большинстве стандартов обмен данными идет по CAN, гальванически развязанной. Курильщики из Франции протолкнули такое: отдельно от силовых кабелей по стандарту передачи данных по электросетям устанавливается tcp/ip соединение. Автомобиль поднимает свой http, зарядка поднимает свой http. И вот get'ами они друг у друга берут xml файлы, где лежит то, что обычно по CAN гончют. Как такое не хейтить?!

Кто так сделал?

Я хейчу xml, когда вижу, как SOAP используется для передачи и хранения бинарных блобов.

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

question4 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.