Не знаю... То ли я слишком многого в этой жизни не понимаю (что, в общем-то, факт), то ли пока не видел красивого и грамотного применения XML к месту и ко времени, но почему-то у меня упорно складывается ощущение, что этот язык - какой-то массовый развод на модное слово и мощное железо . Очень надеюсь, что кто-нибудь вправит мне мозги по этой части, развеет мои дремучие заблуждения и поможет наконец полюбить этот мощный и универсальный язык разметки всей душой. Это для меня очень важно, т.к. последние полгода мне никак не удается уйти от XMLя в моей основной работе, а работа с нелюбимой вещью не приносит удовольствия...

Недоверие к XMLю зрело во мне давно, года с 2004-го, когда я впервые прочитал статью Джоэля Спольски насчет "назад к основам". И первый опыт получения контента от поставщика в виде 5-мегабайтного (всего лишь) XMLника (с последующим распарсиванием в PHP и заносом в обычную базу) подтвердили мои опасения - уж слишком часто не успевал этот XMLник загрузиться и распарситься полностью за отведенные полминуты... а еще бывало, что поставщик вообще забывал выдать файл в нужное время или выдавал его пустым, что ломало мне всю логику обновления контента... впрочем, тогда у меня было слишком мало опыта и я валил все исключительно на свои кривые ручки (скорее всего, небезосновательно).

...Ну хоть убей не могу понять, в чем великая сермяжная правда того, что в одном проекте при обмене данными, там, где по смыслу достаточно передать просто идентификатор, я вынужден отсылать многоэтажную байду на пару килобайт - лишь потому, что уже, мол, есть схема для этого типа данных, "спец. внутренний протокол" и т.п. Ну нечего больше делать этому "протоколу", кроме как гонять на сервер (!) кучу балластной разметки, чтобы там сервер поднапрягся, подумал и выцепил из этого запроса смысловую часть - один-единственный id. Зачем??? Зачем серверу человекочитаемая разметка? Да и ответу сервера так ли она нужна? Особенно с учетом того, что она занимает в несколько раз больше места, чем смысловая часть данных. Даже если пожать XML gzip-ом - все равно останется больше, чем если передавать те же данные в компактном формате, хотя бы чем-то а-ля JSON или php-шный serialize. А ведь ради этой мнимой "человекопонятности" (мнимость ее особенно заметна, когда львиная доля данных - сериализованные бинарники и все такое прочее;) намного усложняется парсинг и обработка пришедших данных на клиенте... Получается, что основная часть трафика - пересылка функционально избыточной разметки, не нужной по сути ни серверу, ни клиенту, ни пользователю...

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

Конечно, заманчиво выглядит XML для рекурсивных и древовидных структур, т.к. он сам как бы дерево. И чисто XML-ные БД для них. Вроде удобно. Только производительность зачастую такая, что использовать в активном проекте стыдно (а ведь Джоэль предупреждал...) и запросы к ней идут... как к тому же веб-сервису, с соотвтествующей избыточностью, накладными расходами на парсинг и всеми вытекающими...

Сумбурно получилось, но наболело. Завожу тему в "Рел. войнах" и нарочно делаю ее провокационно утрированной, т.к. хочу услышать в основном побольше аргументов горячих сторонников XMLя - я ведь заинтересован в том, чтоб они меня "перевербовали" и помогли/заставили этот XML полюбить... .

 хм, а ты уверен, что тормоза связаны с XML, а не с БД? ;)

Пример из жизни: универсальный формат.
Заказчик дает задание: сделать браузер по готовому контенту, при этом он может менять контент сам.
Пишу за пару минут парсер на основе готовой либы. Готово.

 Уверен про производительность? Тогда объясни, почему он работает медленно(с доводами и т.д.). На примере SAX или XmlPull парсера.

В основном с получением этих 5МБ из сокета и... а также с моими кривыми ручками. Просто, имхо, будь там не XML, а обычный CSV (избыточность меньше) - было бы не 5, а лишь порядка 2 МБ, и пихнуть их в базу тоже было бы проще...


Оно, конечно, так... но те же CSV и JSON, на мой взгляд, тоже в своих пределах достаточно универсальны. А используя

можно, по-моему, любой формат легко щелкнуть, хоть сжатый бинарный...


Лично меня вполне убеждают доводы того же Джоэля...

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

 эээ... т.е. чудесным образом данных для пихания в базу стало бы меньше? Интересно, почему я тебе не верю =)
Илди ты пихал в базу прямо XML?

 Ну начнем с того, что лексический анализ не такой уж и медлленный(а точнее я не понимаю, что в нем медленного вообще). Та же классическая State Machine(читаем 1 символ, заносим в буфер состояния, возможно меняем буфер/состояние при некоторых условиях) достаточно быстрые.

 Ааа, так сравниваем оказывается не с другими форматами, а с СУБД? Естественно СУБД быстрее работает, но ты ушел от темы(т.е. эта цитата совсем не в тему). 

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


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


Сравниваем с альтернативами при каждом конкретном применении. Как средство обмена данными - с др. форматами, как хранилище - с СУБД... Имхо, сравнение вполне корректно.

1) XML-это как определние интерфейса. Отдаёшь интерфейс разработчикам разных модулей, в конце всё работает вместе без запинки.
2) На самом деле проблемой в сетевом программинге также является передача обьектов о сети. Здесь поможет ХМЛ, как кроссплатформеная и практически неубиваемая сетевыми протоколами штука.
3) В веб-программинге преобразование XSLT рано или поздно будет основой дле отображцения страниц. Минимум трафа (только ХМЛ), красивые сложные страницы с различными отлуками (ХСЛТ+ХМЛ).

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

Вот это уже интереснее! В чем неубиваемость? Пока, по-моему как раз наоборот - одна скобочка побъется и гудбай, валидность... но я действительно пока многого не понимаю...


Вот здесь - или я извращенец, или плохие примеры видел... Ну не могу я согласиться, что передача 2к разметки ради одного id-шника (реальный пример из моего теперешнего проекта) есть минимум трафа... Все равно ведь получается, что основная масса трафа - не данные и даже не оформление, а служебная инфа...


Т.е. компромисс по принципу меньшего из зол?

Неубиваемая, потому что в ХМЛ символы ASSCI. Попробуй через ФТП в нормальной моде перекачать файл с юниксовского сервера на виндосовский. Или передать бинарный обьект кроссплатформенно, или из приложения, написанного на Ява в приложение на Си.
В любом случае ХМЛ подойдёт на ура, а с бинарниками будут траблы, начиная с Big/Little Endian и заканчивая особенностями компилятора обьектов.


Ну механизма, оптимального для всего - не бывает.


Ну мы начали разработку Vingrad CMS http://sergejzr.jino-net.ru/vcms/index.php зайди туда ради интереса и кликни правой кнопкой "просмотр исходного кода". Почувствуешь разницу  ПС: не смотри, если медленно грузит - хост медленный, зато после первой загрузки даже на нём летает(ХСЛТ лежат себе в кэше).

Лично мне XML наоборот нравится. В частности он очень часто используется для конфигурационных файлов. Они получаются весьма наглядными и легко читаются.

По поводу БД на XML, он для этого не предназначен. Отсюда и низкая производительность.

Что касается гоняния одного id в формате XML, это вполне нормально. Сегодня вам надо один id перегнать, а завтра id и код возврата, послезавтра id, код возврата и сообщение об ошибке, и т.д. XML - это все передаст.
А вот с самопальным бинарным форматом, надо будет постоянно модифицировать парсер и генератор. И как только будет достигнута достаточная сложность (вложенные структуры, необязательные элементы и т.д.) пойдет огромное количество проблем, которые в XML парсерах уже давно решены. Плюс XML формат позволяет легко парсить на разных языках.

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

JSON конечно подойдет для простейших случаев, но в целом он слишком примитивен.

sergejzr, спасибо, весомый аргумент. Насколько я понял, речь именно о тегах - данные ведь, по идее, могут быть и в UTF?


Это да, будет поудобнее ini-шек. Но конфиги, AFAIK, как раз по сети обычно не передаются...


Но бывает, что требуется...


Тоже трудно не согласиться;)


Сомневаюсь, что описание этого запроса посредством XML будет оптимальным способом его передачи... впрочем, с открывающимися мне в этом топике новыми знаниями мои сомнения уже не так глубоки . А пример был исключительно к истории моего непростого эмоционального отношения к XMLю...

Спасибо! Похоже, картина для меня начинает понемногу проясняться... 

Есть esc-последовательности, так что весь XML может быть в ASCII.


Смотря как на это посмотреть. Да объем данных можно уменьшить, если передавать их в бинарном формате, но если использовать GZIP, то тут уже выигрышь будет не так велик. А время парсинга все равно не критично, учитывая скорость сети.
Зато мы получаем данные в универсальном формате, который воспринимается многими программами, и может быть достаточно легко трансформирован с помощью XSLT.

У XML есть своя ниша применения, и в ее пределах он достаточно хорош. А когда сделают XML Binary, то еще от части недостатков удастся избавиться.

Можно ссылку? 

XML Binary, но это пока только проект. Готовых спецификаций, насколько я знаю, там нет.