. Очень надеюсь, что кто-нибудь вправит мне мозги по этой части, развеет мои дремучие заблуждения и поможет наконец полюбить этот мощный и универсальный язык разметки всей душой. Это для меня очень важно, т.к. последние полгода мне никак не удается уйти от XMLя в моей основной работе, а работа с нелюбимой вещью не приносит удовольствия...Недоверие к XMLю зрело во мне давно, года с 2004-го, когда я впервые прочитал статью Джоэля Спольски насчет http://russian.joelonsoftware.com/Articles/BacktoBasics.html. И первый опыт получения контента от поставщика в виде 5-мегабайтного (всего лишь) XMLника (с последующим распарсиванием в PHP и заносом в обычную базу) подтвердили мои опасения - уж слишком часто не успевал этот XMLник загрузиться и распарситься полностью за отведенные полминуты... а еще бывало, что поставщик вообще забывал выдать файл в нужное время или выдавал его пустым, что ломало мне всю логику обновления контента... впрочем, тогда у меня было слишком мало опыта и я валил все исключительно на свои кривые ручки (скорее всего, небезосновательно).
...Ну хоть убей не могу понять, в чем великая сермяжная правда того, что в одном проекте при обмене данными, там, где по смыслу достаточно передать просто идентификатор, я вынужден отсылать многоэтажную байду на пару килобайт - лишь потому, что уже, мол, есть схема для этого типа данных, "спец. внутренний протокол" и т.п. Ну нечего больше делать этому "протоколу", кроме как гонять на сервер (!) кучу балластной разметки, чтобы там сервер поднапрягся, подумал и выцепил из этого запроса смысловую часть - один-единственный id. Зачем??? Зачем серверу человекочитаемая разметка? Да и ответу сервера так ли она нужна? Особенно с учетом того, что она занимает в несколько раз больше места, чем смысловая часть данных. Даже если пожать XML gzip-ом - все равно останется больше, чем если передавать те же данные в компактном формате, хотя бы чем-то а-ля JSON или php-шный serialize. А ведь ради этой мнимой "человекопонятности" (мнимость ее особенно заметна, когда львиная доля данных - сериализованные бинарники и все такое прочее;) намного усложняется парсинг и обработка пришедших данных на клиенте... Получается, что основная часть трафика - пересылка функционально избыточной разметки, не нужной по сути ни серверу, ни клиенту, ни пользователю...
В случае вебсервисов, наверное, аргумент про единообразие и стандартизацию более весом. Но был у меня относительно недавно случай, когда логика выборки с двух вебсервисов так и подмывала сделать один запрос наподобие SQL-ного джойна... в итоге пришлось в клиентской части городить препротивное сопоставление массивов в цикле - все оттого, что поставщики данных не предусмотрели прямой связи между (в SQL-аналогии) основной таблицей и справочником типов записей в ней, а из рамок установленных схем уже не выбраться... Не удобнее было бы, если бы механизм вебсервисов был и впрямь навроде SQL - чтобы фильтровать и компоновать данные мог сервер, выдавая уже более-менее компактный окончательный набор данных, который только стилизовать для вывода и останется? А так слишком уж, имхо, напоминает с точки зрения SQL-ных привычек ламерские поделки, где сходу выгребается в скрипт вся база, а дальше всё циклом...
Конечно, заманчиво выглядит XML для рекурсивных и древовидных структур, т.к. он сам как бы дерево. И чисто XML-ные БД для них. Вроде удобно. Только производительность зачастую такая, что использовать в активном проекте стыдно (а ведь Джоэль предупреждал...) и запросы к ней идут... как к тому же веб-сервису, с соотвтествующей избыточностью, накладными расходами на парсинг и всеми вытекающими...
Сумбурно получилось, но наболело. Завожу тему в "Рел. войнах" и нарочно делаю ее провокационно утрированной, т.к. хочу услышать в основном побольше аргументов горячих сторонников XMLя - я ведь заинтересован в том, чтоб они меня "перевербовали" и помогли/заставили этот XML полюбить...
.