Дискуссии об осмысленности XML

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

>а бинарный формат такими свойствами по твоему обладать не может ?

Батенька предлагает делать бинарные конфиги и сравнивать их diff-ом? :)

>> может, нелюбители xml-а просто не представляют, что с помощью этого-самого зумля можно сделать? =)

>Знают.

Не знают, и все чихи в сторону XML в этом топике тому подтверждение.

>Но с помощью XML нельзя сделать ничего.

Странно, а я то думал что с XML это уже де-факто стандарт для обмена/хранения данных.

>Тебе потребуется программа на каком-либо языке, в которую будет включен парсер этого самого XML. И обработка всей логики твоего XML'я.

Пардон, вам же русским по чёрному выше написали что XML это язык разметки а не язык программирования... Какая ещё логика XML?

>Причем, это будут абсолютно оторванные друг от друга вещи --- XML и программа-обработчик. На каждый минимальный чих тебе придется дописывать программу-обработчик.В случае LISP у тебя есть _один_ _универсальный_ язык.

СТАНДАРТИЗОВАННЫЕ Парсеры для которого просто не существуют и даже жалкий W3C не пишет рекомендации :)

>Твой XML'ный конфиг будет короче и читабельнее, если перевести его в S-expr, при этом программа-обработчик написана опять же на LISP и у тебя есть возможность использовать всю мощь LISP прямо в твоем конфиге, не трогая программу-обработчик.

Это очень просто не так ли?

>Как пример --- emacs. Конфиг на LISP, при желании можно сделать с emacs'ом что угодно, либо прямо в конфиге написать парсер какого-нибудь ini-файла с опциями "for dummies".

API emacs это же как два байта переслать... :) Сам факт того что вы ковыряете конфиги говорит о том что ПО которое вы используете не обладает достаточными возможностями по настройке.

>Ни в одной программе с XML я такой гибкости не видел, а если она будет, то это будет LISP с ужасным синтаксисом XML.

И не увидите. Потому что XML в отличие от LISP это язык РАЗМЕТКИ а не язык программирования, кстати на прекрасном и мегауниверсальном LISPе вообще что-нибудь кроме динозаврика emacs написано?

> линейный рост сложности, желательно с небольшим коофициентом

Ну, в случае Lisp'а коэффициент равен 0 :) Самый сложный конфиг парсится так (уже неоднократно приводилось в данном топике): (load "config.lisp")

В случае же других языков, мерилом сложности является сложность API приложения, доступного программе-конфигу, работающей во встроенном интерпретаторе. Парсинг же простейших конфигов на SExpr'ах без сложной семантики не сложнее парсинга XML, но в этом случае вообще незачем городить эту городуху, легче использовать INI или что-то в этом роде.

> интеграция уже 2 чужеродных языков не сверхсложная задача, но и не сахар XML тут неплохое решение

В случае сложных XML-конфигов вы на базе XML строите собсвенный язык и сами пишете собственный интерпретатор этого языка.

На самом деле, я прошел через это. Как-то раз, мне пришлось делать приложение со сложными конфигами-шаблонами. Я по скудоумию выбрал C++/Python/XML. C++ для критичных к скорости участков, Python для логики и XML для шаблонов. Как я раскаивался потом, что не выбрал для всего один-единственный LISP! Причем, камнем преткновения была невозможность нормального использования нормального ЯП (Python, в данном случае) в языке, построенном на XML. А как выглядели эти конфиги! Жуть! В общем, "... и опыт, сын ошибок трудных ...".

На самом деле, интеграция какого-либо интерпретатора и реализация API для него, не сложнее использования "тупого" парсера XML и ручного написания логики языка, построенного на XML.

> ТЕСТИРОВАНИЕ !!!

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

Кроме того, строить приложение на плохо оттестированной основе опасно. Особенно, если вы попытаетесь сразу впихнуть как можно больше функционала. Дальше кривость только увеличивается --- проверено практикой.

> в вашей схеме, например guile + GoodLanguage в определенный момент может произойти взрывное увеличение сложности из-за размазанности сементики представления данных по разным частям программы

Семантика представления должна быть в guile. Хост-приложение предоставляет только некоторый API. В зависимости от уровня этого API и объема части приложения, реализованного в guile, приложение ближе к (1) или к (2).

> боюсь что даже будучи таким хорошим емакс единственный представитель такого пути (по крайней мере из широко известных)

Ну, в некотором роде, .procmailrc --- тоже программа, а уж .vimrc --- безусловно, хотя они и не Lisp. Это уже плавный переход к обсуждению концепции "конфиг==программа/приложение==интерпретатор".

>>Никто на все вопросы не отвечает - xml в первую очередь предназначен для обмена данными. Всё - всё остальное от незнания.

>О. Золотые слова. Между кем и кем обмен данными? Между програмами? То есть XML людям показывать ни в коем разе нельзя - скрывать надо.

Нормальное приложение не должно вываливать пользователю данные во внутреннем формате, исключение составляют лишь конфиги emacs :)

>камнем преткновения была невозможность нормального использования нормального ЯП (Python, в данном случае) в языке, построенном на XML

ЯП построенный на XML...думаю тут всё проще - ты _не_ умеешь выбирать инструмент для решения задач. XML тут ни при чём. Ты сам себе злобный буратина...удачи в дальнейшем забивании гвоздей микроскопом :)

> до тебя так трудно доходит? ладно, я ещё раз повторюсь. svg умеет тот же inkscape. Этот самый inkscape позволяет редактировать svg как дерево объектов - это позволяет добиваться эффектов, которые в самом редакторе не реализованы (т.е. некоторые параметры гуйней не изменить).

Это не преимущество XML, это недостаток Inkscape.

>Представь, что у тебя есть конфиг с хреновой тучей взаимосвязанных числовых параметров. Есть потребность позволить пользователю вычислять одни параметры через другие. Сразу возникает потребность в парсинге выражений и пр. А подстановки? Если, например, в конфиге куча путей, и нужно позволить пользователю задавать некие общие части, например, префиксы и потом подставлять? Это всё уже есть в XML/ini/ХЗчто?

1)Представь что есть в этом мире задачи отличные от написания конфигов emacs
2)Теперь представь что есть в этом мире задачи отличные от написания конфигов впринципе
3)А теперь самое главное: представь, что есть программы для которых не нужно писать конфигов, они настраиваются(О ужас!) двумя щелчками мыши...

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

info в виндусовом софте. я плакаль

> Люди выбирают привычное, а не удобное - в этом и трагедия.

Это не трагедия, это отсутствие инструмента для решения задачи.

>В 60-х годах как раз пытались строить БД по иерархическому принципу. Отголосок этих попыток - нынешние файловые системы. Насколько я помню, геморроя с иерархическими базами данных огребли по самое не балуйся - из-за немасштабируемости и тормознутости оных. Потом появилась реляционная модель - и про иерархические БД все забыли.

1) Вы отстали от жизни, сейчас только ими и занимаются.
2) Ничего ужасного в иерархичности нынешних файловых систем не вижу.

>Это не преимущество XML, это недостаток Inkscape.

и преимущество xml :) вряд ли в inkscape когда-нибудь будут реализованы все опции для редактирования объектов. А дерево - оно уже есть.

>>xml в первую очередь предназначен для обмена данными

>Данными обмениваются в первую очередь для того, чтобы их потом обработать. И выбирать формат сериализации для обмена без учёта требований обработки может быть несколько неразумно. Хотя конечно, при разработке для сферического кон^Hмпютера в жидком азоте, выполняющего бесконечный цикл за 1.57 с небольшим секунды, нормально.

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

>а xml уже можно открыть в виме и подправить? :)

А для вима наверное нет ftplugin-ов для правки XML,XSL? Зайдите на www.vim.org и вбейте в поиск слосо XML, поверьте это не сложнее ковыряния в носу.

>>Никто на все вопросы не отвечает - xml в первую очередь предназначен для обмена данными. Всё - всё остальное от незнания.

>+1. Можно только добавить, что он удобен, когда этих данных мало. Например, для синхронизации записной книжки/календаря между телефоном и компом. Когда речь идет про сотни мегов или, не дай бог, гиги инфы и про масштабируемость, про XML лучше сразу забыть.

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

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

>Ха-ха. Замена. Как будто до появления этого чуда, обмена данными не существовало?

Ага, в 60-х годах у кого-то получилось 2 байта переслать.

>>Если да, то сразу давай пример - есть вэб-сервисы, общающиеся по XML: A <-xml-> B Получаемые от А данные проходят валидацию по DTD и при помощи XSLT переводятся во внутренний формат (например для скармливания БД).

>О да. Вот уж что являет собой полное уёжище - это веб-сервисы.
Какая там польза от читаемости документа? Особенно, если шифрование используется?

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

>Или вот, захотелось еще один атрибут добавить - пиши новую версию сервиса.

Это как раз проблемы бинарных протоколов к коим вы привыкли. XML он на то и XML что старые кленты новых атрибутов не испугаются, а просто не будут поддерживать новую ФУНКЦИОНАЛЬНОСТ за ними стоящую. Почитайте про букву "X" в абревиатуре XML.

>Спрашивается, нафига? Так что все рассуждения гика про то, какое все мегасовместимое при использовании xml, идут лесом. Соответственно, производительность и масштабируемость никакие. И CORBA, по эффективности веб сервисы никогда не перешагнут.

Это вы завтра заказчикам рассказывать будете :)

> Не используй js, а используй lisp. (load-file "/home/ugoday/.gnuemacs.el") и всё в ажуре.

Не, ну я понимаю конечно, что у емаксеров и браузер на лиспе с интерпретатором лиспа, внедренного в html код (этакий embeddedLisp хехе), но что остальным делать?

> Не знают, и все чихи в сторону XML в этом топике тому подтверждение.

Скорее, чихи в обратную сторону подтверждают незнание приверженцами XML Lisp'а и вообще чего-либо, кроме XML/C/C#/Jaba.

> Странно, а я то думал что с XML это уже де-факто стандарт для обмена/хранения данных.

Честно говоря, не видел в реальности. Что я видел, так это хранение данных в РБД или plain text или binay файлах, а обмен я видел на CORBA, сокетах с home made протоколами или вообще через те же файлы.

> СТАНДАРТИЗОВАННЫЕ Парсеры для которого просто не существуют

http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+226-1994+(R199 9) http://www.swiss.csail.mit.edu/~jaffer/r5rs_toc.html

> Это очень просто не так ли?

Проще просто не бывает. Знаешь, как emacs свой конфиг парсит? (load user-init-file-1 t t)

> Сам факт того что вы ковыряете конфиги говорит о том что ПО которое вы используете не обладает достаточными возможностями по настройке.

Не понял. По вашему, достаточными возможностами по настройке обладает программа вообще без конфигов что ли?

> Потому что XML в отличие от LISP это язык РАЗМЕТКИ а не язык программирования

А нормальный конфиг --- это программа.

> кстати на прекрасном и мегауниверсальном LISPе вообще что-нибудь кроме динозаврика emacs написано?

http://en.wikipedia.org/wiki/Common_Lisp#Applications И это только Common Lisp.

> Ты сам себе злобный буратина...

Я знаю. Но это было давно :) Нынче я исправляюсь и для использования XML должны быть ОЧЕНЬ веские основания, коих в свете существования Lisp, что-то не видать. Кстати, ЯП оно было не сразу, сначала это был просто шаблон, но потом требования резко изменились и пришлось сделать конфиг программой.

>Если бы ты читал статью по ссылке выше, то увидел бы в самом начале линк на блог автора движка MSXML, где он как раз пишет, что XML почти Sucks.

>The whitespace between the <ul> and the <li> tags is not significant, yet the whitespace between the <pre> and <b> tags is significant.

Казалось бы причём тут овип локос? На самом деле автор MSXML расписался в собственной ущербности, что и требовалось доказать(я всегда подозревал что MSXML писал какой-то урод) ИМХО любые пробелы между тегами - незначащие, а если человек пытается делать что-то типа:
<b>xml</b><b>suxx</b>
то это всего лишь означает что он должен сделать:
<b>xml rulez</b>

> А теперь самое главное: представь, что есть программы для которых не нужно писать конфигов, они настраиваются(О ужас!) двумя щелчками мыши...

И зачем там XML? Два щелчка мыши можно и в key=value запихать без проблем.

>Понятно?

Нет. Это тебе непонятно, видимо, что такое "\n".

>Вы вообще про XML читали? Похоже, нет.

Удивительное дело, но не только читал, но и довольно много работал. А вот те, кто пишет постинги, типа "А если значение атрибута содержит перевод строки?", явно уже из нового поколения, не знающего, что такое "\n".

А теперь представь что в этом config.lisp кулькакер Тузик засунул Мегавирусь. И при следующем запуске твоей мегапрограммы мегавирусь Тузика будет уже во всех .lisp файлах. Понравилось?

>Я знаю. Но это было давно :) Нынче я исправляюсь и для использования XML должны быть ОЧЕНЬ веские основания, коих в свете существования Lisp, что-то не видать

ты ударился в другую крайность, что тоже является признаком ССЗБ :)

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

полная смена ТЗ - достаточное основание для выкидывания уже сделанного и зачатия нового проекта :) То что ты попытался прикрутить к велосипеду квадратные колёса и куда-то ещё на этом уехать - тоже не говорит о профессионализме. Ах да...это было "давно" :)

ps: худею я с фанатствующих лисперов...гербалайф отдыхает

>А теперь представь что в этом config.lisp кулькакер Тузик засунул Мегавирусь

а что, у QT есть биндинги к лиспу? Я просто не интересовался никогда...А ведь всем известно, что тузик пишет вирусы только на QT :)

> вряд ли в inkscape когда-нибудь будут реализованы все опции для редактирования объектов. А дерево - оно уже есть.

Начнём с того, что Inkscape в настоящее время не поддерживает все возможности SVG (достаточно вспомнить SVG-фильтры вроде Гауссова размывания). Поэтому XML-редактор, по поводу которого чуть ли не писал кипятком автор недавней статьи в Компутерре, обычно используется для возвращения объекту статуса видимости.

Продолжим и закончим тем, что, IIRC, по соглашению между разработчиками Inkscape версия 1.0 будет полностью поддерживать спецификацию SVG Mobile.

>Батенька предлагает делать бинарные конфиги и сравнивать их diff-ом? :)

Если кто не понял речь шла о формате open document, где от xml никакого толку нет, что он бинарный будет что xml всё-равно хер прочитаешь без софта.

>Начнём с того, что Inkscape в настоящее время не поддерживает все возможности SVG

Если б он всё поддерживал - цены б ему не было :)

>Поэтому XML-редактор, по поводу которого чуть ли не писал кипятком автор недавней статьи в Компутерре, обычно используется для возвращения объекту статуса видимости.

обычно не подразумевает невозможности использовать xml-редактор по-другому. Собственно, я речь вел о том, что наличие такой возможности в inkscape прямо связано с форматом svg. Вернее даже - с древовидной структуры с жёстким форматом данных Объект->Атрибут->Значение.

По-моему, топик давно пора переименовать в "Осмысленность дискуссии об XML" :)

>По-моему, топик давно пора переименовать в "Осмысленность дискуссии об XML" :)

а по-моему - в "Бессмысленность дискуссии" :)

Лучше в "Много шума из ничего."

Главный солист - гик.

>Лучше в "Много шума из ничего."

>Главный солист - гик.

о да. Это я наверное кричал, что зумль не нужен, потому что есть лисп :)

>а что, у QT есть биндинги к лиспу? Я просто не интересовался никогда...А ведь всем известно, что тузик пишет вирусы только на QT :)

http://members.aon.at/lispolos/

>А нормальный конфиг --- это программа.

это только твоё представление о "нормальном конфиге". Розумеешь?

>>>Это как раз проблемы бинарных протоколов к коим вы привыкли. XML он на то и XML что старые кленты новых атрибутов не испугаются, а просто не будут поддерживать новую ФУНКЦИОНАЛЬНОСТ за ними стоящую. Почитайте про букву "X" в абревиатуре XML.

Почему ж Glade-0.6.2 об этом не знает и отказывается открывать файлы сделанные в glade-2.10? И наоборот. Чтение про букву "X" не помогает.

у xml есть своя нишка. Вот пусть в ней тихо сидит и не лезет, куда не просят. А то ему "X"-то оттяпают.

> полная смена ТЗ - достаточное основание для выкидывания уже сделанного и зачатия нового проекта

Как бы это сказать... В том проекте не было ТЗ как такового вообще :) И времени было в обрез, потому как до этого там какие-то хмыри больше года х** пинали. А смена требований возникла потому, что инфу нам выдавали порциями в месяц по ведру.

> То что ты попытался прикрутить к велосипеду квадратные колёса и куда-то ещё на этом уехать - тоже не говорит о профессионализме.

Да, я знаю. Тогда я не знал Lisp'а :) На нем этот проект было бы реально поднять в тех условиях, но поезд ушел, и не по нашей вине --- мы свою задачу выполнили, может, и не лучшим образом, но достаточно для того случая.

> худею я с фанатствующих лисперов...гербалайф отдыхает

А кто-нибудь из противников удосужился хотя бы заглянуть хотя бы в OnLisp? Или удовольствовались мнением "ниасилил, многа скобачек"?

> А теперь представь что в этом config.lisp кулькакер Тузик засунул Мегавирусь.

Волков бояться --- в лес не ходить. Что ж мне теперь, и shell-скрипты в $HOME/bin не класть?

> И при следующем запуске твоей мегапрограммы мегавирусь Тузика будет уже во всех .lisp файлах.

Не во всех. Подавляющее большинство .lisp файлов недоступны на запись не-root'у. Так что, исполняемость конфига не меняет ситуацию существенно.

>А кто-нибудь из противников удосужился хотя бы заглянуть хотя бы в OnLisp? Или удовольствовались мнением "ниасилил, многа скобачек"?

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

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

ps: ничего личного. Сам иногда увлекаюсь - и знаю, как трудно выйти из состояния эйфории. Ну да ничего...время лечит. Года через два XML покажется тебе не таким уж страшным :)

>Года через два XML покажется тебе не таким уж страшным :)

Правильно он начнёт казаться просто куском окаменелости, на которую дети показывают в музее пальцем и придурошно гагочут.

=)

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

Ну вот, сразу "пропихнуть". И почему обязательно LISP? LISP - лишь пример ЯП, построенного на SExpr (на синтаксисе XML подобного по удобству нет), и отличный инструмент. Зачем использовать неудобные и, скорее всего, относительно недолговечные вещи только потому, что это модно?

Ты пытаешься меня убедить, что без XML сейчас шагу нельзя ступить? Так я и сам это вижу, но это не повод для меня выбирать XML для конфигов и для хранения данных. И в качестве формата обмена данными я предпочту не-XML всегда, когда это возможно, потому что кроме случаев общения с существующим софтом, использующим XML, я не вижу других надобностей в XML. В каждом конкретном случае plain text/ini/SExpr/binary удобнее, чем XML.

> у xml есть своя нишка. Вот пусть в ней тихо сидит и не лезет, куда не
> просят. А то ему "X"-то оттяпают.
> anonymous (*) (11.04.2006 0:55:43)

Ужасно то, что не просят, а он лезет. 30 аффторов подписались под 6 страничной статейкой про управление экспериментальным железом через X|\/|L.

Модно ? Грантососам проще стало бабло про[жс]ерать !!!

--

Я вот после прочтения всего что тут было, начинаю осознавать полезность XML :)

Самая главная его полезность - это разделить людей к которым можно будет обращаться в случае написания качественного софта, и тех кто начинал с веб сервисов, и пытается ещё куда-то пролазить с теми же знаниями... Да и разработки их только внутрикорпоративные, где главное - это то что работает, а не как работает... А ещё и какая экономия на бывших веб-девелоперах, они же привыкли получать свои 300$/месяц ))

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

Свою нишу XML займёт достаточно успешно, да и кто против ? :D

>> Пакет xr (внешние сслыки)+ emacs+reftex - делает всё выше описанное.

>То есть, если я потом объединю надцать LaTeX документов в один, и сгенерю один PDF, внутри него эти ссылки (которые вроде как были внешними на этапе авторинга, а стали внутренними) корректно зарезолвятся?

Да. Есть специальная команда, которая позволяет указать в каких документах искать ссылки при этом эти куски при предварительной копиляции включать не обязательно.

Якори для ссылок ставятся в LaTeX с помощью \label - достаточно простой договорённости где какой префекс ставить. auctex при создании раздела/картинки/equation и т.д. ставит label автоматом.

Эта технология требует дополнительной дисциплины, зато абсолютно переносима.

>Еще один вопрос.

>use case - content references, когда вместо пустого элемента с refid, подставляется заполненный из другого документа. То есть в документе есть <topic refid="1234">, при обработке из репозитория берется топик с данной ИДшкой и подставляется в это место со всем своим содержимым.

>Используется для создания reusable components в документах. Если такой компонент меняется то, эти изменения будут доступны во всех документах которые его включают, без многократного исправления исходников.

Есть команда \include + в заголовке можно определять/переопределять любые команды и окружения. Это то?

>Ну ты даёшь. Мы хотим донести, что XML применим для _обмена_данными_. Data Interchange - это область XML. Там нужна валидация, там это всё полезно. XML создан именно для этого.

Да, к вопросу о валидации. Валидация тегов не делает самого главного - не гарантирует сохранности данных. Так что смысла в такой валидации особо не видно.

был такой рассказ (не помню чей) - в кратце:
20xx год. Выходит мужик на шум, а на помойке программисты за жрачку дерутся. Возвращается домой, берёт винтовку (как сторож на птицеферме в Ну Погоди!;) Ша-ра-х! А тут - вот беда - полицейские проезжают. Тормозят. Мужик оправдывается: по закону голодных программистов можно ведь типа отстреливать. - Да не только можно - говорит коп, но и поощряется. -Но вы же их, мать-вашу, подкармливаете!! >:-<

К чему - понятно, наверное.
Сидит кто-то и страдает - что новенького изобрести. Или ресёрч у ибм и подобных - и за пару десятков баксов или за корпоративные деньги (надо как-то занять чела между проектами - чтобы не сидел) - статья готова. Ну как статью пишет (если бы в мат.физ - 90% таких - никто бы и не цитировал бы). Выкладывает как-бы ресёрч. А тут (в IT) куча ребят из индии и/или менеджеров-теоретиков руками ничего не делавших получают погуглившись этот "ресёрч" и принимают это за современную технологию (потому что скорее там и базис как-бы подбит и ссылки есть - как положено). В нескольких проектах сделают, пошлют пропозал. Кто-то отпишет RFC (M$ и товарищи - как положено засветятся тоже - так как у них должно быть как-бы всё присутствовать - если кто захочет). После RFC - менеджеры это будут требовать уже как стандарт как-бы программера не тошнило. И кастомер вдруг хочет этого Г. тоже почему-то.
мессадж-брокер - это же как процессор должен быть - каждый байт на счету, каждая проверка символа. Потому что от этого зависит - сколько мессаг переварит сервер: 100, 1000, 10000 или больше за одно и тоже время. То-есть всегда подобных ресурсов не будет хватать. Тем более с торможением з-на Мура и удорожанием энергоресурсов.
И существовал 100 лет в обед прекрасный message формат - MIME называется, которым все пользуются. Никакого XML. Строки. Хочешь бинарники послать, разнородную инфу - всё есть и эффективно.
Да и дополнительный mail сервак запустить - что проблема что-ли? Написать свой клиент, посылать всё в MIME формате. Готовый мессадж-сервер. Хочешь - доработай. Так надо изобретать жабберы итд. Ну понятно - надо что-то делать людям.
Но почему не изучить вначале то что шлифовалось годами?

В batch-процессинге данных - лучше о xml не заикаться. Типичный пример для датацентров: идет еженощно стрим данных - не один час, окно ограничено. И эти часы и так увеличиваются, так как данных провайдер посылает каждый день всё больше, и так надо апгрейдится всё время.
И каждый разделитель важен так как их много. Если бы даже xml и не кушал CPU (что он в основном и делает) - оверхед не то что в 2 раза - на 10% важен. И grep/sed/awk/shell рулят и для анализа в том числе. И тот же diff - для сравнения баз (когда они в строках).

Короче, ниша у xml - одна, вернее 2: замена .doc-подобных и сообщения (IPC) но только когда скорость не важна и мессаги - типа сигнальных (не high-performance message-broker и не стрим - так, изредка).

О xml могу говорить много. В основном матом (когда используется не в выше приведённых 2х случаях). Чтобы не говорили тут что ниасилил: ещё в 99 году получили award за инновационную имплементацию включая xml брокера от самой известной телеком-компании. А также создания грамматики для рисования любых пдф с векторной графикой помощнее батика ещё в 2000 - для проприетарного продукта из разделённых стиля и данных.

>>>Никто на все вопросы не отвечает - xml в первую очередь предназначен для обмена данными. Всё - всё остальное от незнания.

>>О. Золотые слова. Между кем и кем обмен данными? Между програмами? То есть XML людям показывать ни в коем разе нельзя - скрывать надо.

>Нормальное приложение не должно вываливать пользователю данные во внутреннем формате, исключение составляют лишь конфиги emacs :)

Странные представления о нормальных приложениях в unix-мире. Тридцать лет опыта на помойку? Не будет ли потом бардака?

О да, можно сказать о валидации. Кто на продакшене её держит с таким оверхедом? Никто. А на этапе устаканивания протокола - можно и стандартом пользоваться.


Забыл самое главное.
xml - это не UNIX-way. Не строки. Основные тулзы типа grep/sed - не работают как и diff/patch. Для редактирования надо Гуй.
Короче - как винда и жава - чуждое Юних-вею.

Много можно чего сказать про рулёз java-script dom'a, подход javascript как поведения приходящего рядом с данными (AI frames подход на самом деле), ущербности if/while конструкций в JSTL и if в ANT итд итп, но хочется спать, так как б.кодерством скоро опять заниматься, аж вспоминать не хочется :(

прошу не начинать флейм по-поводу высказывания насчёт xml-винды-жавы. Я всё понимаю и всему свои ниши. Под Юних-веем имею в виду почти святые принципы (строки, plain-текст, анализ конвеерами - ну понятно что xml не вписывается и ломает многие удобства не говоря уже расходе электроэнергии. Если используется не в своей нише).

По поводу электроэнергии. Кажется Кларк обещал - универсальную денежную единицу в скором будущем - киловатт-час, так что тоже имхо не последнее Ж)

>xml - это не UNIX-way. Не строки. Основные тулзы типа grep/sed - не работают как и diff/patch. Для редактирования надо Гуй.

ты или сильно заблуждаешься или нагло врёшь. grep/sed/diff/patch работают, хоть и с ограничениями. Или с однострочным lisp или они будут работать лучше?

>но хочется спать, так как б.кодерством скоро опять заниматься, аж вспоминать не хочется :(

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

ps: ты понятия не имеешь что такое юниксвей