>избыточность, скорость...этого недостаточно?

любой расширяемый протокол будет избыточным. Кстати, можешь покурить ещё и jep, описывающий заворачивание xmpp в gzip :)

>2. зачем заниматься преобразованием, если xml-это сила ?

затем же зачем html рендерится в веб-страницу, которую ты видишь.

> может вся сила к примеру в таком геморрое под названием SQL->MyProgram->XML+XSLT->Parser->HTML/WML/итд

Parser во многих случаях лишний. Кроме того - это далеко не единственный путь. И xslt могут быть разные. Сила в гибкости такого подхода

>geek, чуть не забыл, запакованый xml тоже парсится потоком ? :)

да. см. выше

Все остальные комментарии не информационны, поэтому комментируем что хоть как-то можно комментировать

>>б) xml-тексты в текстовом редакторе никогда не редактировал - docbook тебе в зубы, MathML для полного счастья на шею, кривой транслятор в pdf в спину.

>редактировал. Кстати, кроме MathML мог бы ещё и SVG упомянуть до кучи :) кстати, можешь посмотреть что благодаря xml можно делать в inkscape, и рассказать мне, как реализовать тоже самое при использовании других технологий. А именно - редактирование параметров объектов, для которых в inkscape нету возможности редактирования гуйней.

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

Я утверждаю, что по сравнению с LaTeX связка docbook+MathML никуда не годится. Этим можно пользоваться если полностью скрыть от пользователя особенности реализации большой и толстой программой (OpenOffice). XML лучше закрытых бинарных форматов - это единственная его ниша.

Аналогично формат SVG не особенно смотрится рядом с MetaPost для целей ручного редактирования исходников.

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

>>Да и почему нормальную базу не использовать? Надо же как-то компьютерные мощности утилизировать :) PostgreSQL в фоне не сильно то и мешает.

>вот это называется - передергивание. Хотя если ты на полном серьёзе считаешь, что парсить xml - это архисложная задача, сравнимая с написанием SQL-сервера, то тебе не поможет даже врач :)

Ты какой-то совсем странный. Тебя никто не заставляет писать PostgreSQL - он уже есть.

>>>генерировать на основе данных в БД xml-конфиги

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

Проблема релящионных БД в том что они очень плохо дружат с иерархическими и рекурсивными структурами такие вещи там делаются костылями типо nested sets, кроме того дружат они исключительно со статическими структурами. Если говорить применительно к примеру geekа насчёт сотни разных конфигов, то в случае когда у тебя появляется стопервый конфиг ты полезешь в БД и в лучшем случае создашь одну табличку в худшем - несколько связанных таблиц и будешь добавлять столбцы в эти таблицы каждый раз когда в новой версии программы в конфиге появится ещё 10 дополнительных параметров. Уловил суть?

P.S. Подписываюсь под каждым словом geek-а. Те кто тявкает на XML скорее всего в жизни ничего сложнее helloworld-а на лиспе не сделали.

>любой расширяемый протокол будет избыточным.

ASN.1 видел ?

>Кстати, можешь покурить ещё и jep, описывающий заворачивание xmpp в gzip :)

Итого для того чтоб получить/передать сообщение:

1. Принимаем больше байтиков на сокет, чем от нормального протокола :) (минус в скорости)

2. Распаковать большее количество байтиков, состоящих из кучи тэгов ( ещё один минус в скорости)

3. распарсить XML данные, догадайся во сколько раз это медленее ? (ещё один минус в скорости)

4. уложить данные в XML (тоже медленее - ещё минус)

5. запаковать ( - )

6. передать опять больше байтиков ( - )

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

>Сила в гибкости такого подхода

Очень интересно послушать success story в результате гибкости такого подхода :)

Вот нежилось народу с ассэмблером...

>сила - она в правде, брат. А правда в том, что любой xml-файл можно преобразовать в любой другой текстовый файл простым применением xslt :) Для бинарных и plain-text файлов нужно писать всякие конверторы. Вот и всё

А это... Правила для для этой конвертации писать не нужно?

я за долгое (относительно) время пользования текстовыми данными распределил для себя так:

ini - простые конфиги "параметр=значение" не зависимо от размера

cvs - максимум до 10 таблиц, используя DBD::CSV легко выбирать данные при помощи SELECT'a (например из /etc/passwd)

xml - относительно небольшие данные с замудренной структурой (od? я отношу именно к этой категории, если посмотрите на tex, то идеалогия похожа)

всё, что более сложно или больше - только база данных.

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

Не уловил :) Могу предложить формат/структуру БД, которая имеет расширяемое число аттрибутов. Успешно применялось в различных проектах. Достаточно иметь таблицу свойств/объектов и таблицу взаимосвязей этих свойств у объекта. И все!! Ессно SELECT выпадает как стандартный интсрумент - PL/SQL, T-SQL в зубы и вперед. но нужная гибкость достигается.

П.С. ХМЛ - зло. НЕАСИЛИЛ

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

Это так сложно?

>>>Проблема релящионных БД в том что они очень плохо дружат с иерархическими и рекурсивными структурами

Это проблема не БД, а иерархических и рекурсивных структур.

> lisp

Кому это нужно кроме обезьян с Emacs'ом? :)

> xml - относительно небольшие данные с замудренной структурой (od? я отношу именно к этой категории, если посмотрите на tex, то идеалогия похожа)

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

> xml пришёл на волне доткомов когда наивные, незнакомые с grep/sed/awk итд, дотком-открыватели брали самое последнее д.мо как наипоследюю технологию.

Они брали потому как:
- стандартно
- возможность проверки
- совместимость
- готовые парсеры

После этого ваши пассажи насчёт "rule-based нотации" - просто детсадовский лепет. :)

> 1 TagName1 Blah-Blah-Blah

А если значение атрибута содержит перевод строки? Идите, детсад уже открылся. :)

> Использовать XML в файлах конфигурации которые надо будет редактировать руками хоть изредка или для разметки текстовых файлов IMHO полная дурость.

Ага, а гномеры и кдешники - такие идиоты?! Может, вы покажите сови творения, вумный вы наш? :)

Ваша дискусиия - бред полный пожалуй. xml рулит!

Граждане! Выше уже проскакивала здравая мысль выкинуть XML и заменить питоном. Стого и понятно. Ну и будет интепритация документов. Сейчас с XML тоже самое происходит.

XML как тип машинных интсрукций давно уже есть "язык программирования". Посморите правде в глаза!

> Я утверждаю, что по сравнению с LaTeX связка docbook+MathML никуда не годится.

Только в редком случае, если нужны формулы и человек знает LaTeX. 99% документации проще написать в docbook - и редаткоры поддерживают и проблем с модулями нет и результат быстрее и без геморроя виден. Поэтому не надо преимущества 1% специалистов аппроксимировать на всех. :)

>> может вся сила к примеру в таком геморрое под названием SQL->MyProgram->XML+XSLT->Parser->HTML/WML/итд

> Parser во многих случаях лишний. Кроме того - это далеко не единственный путь. И xslt могут быть разные. Сила в гибкости такого подхода

MyProgram здесь може ни к чему. Любая вменяемая БД уже давно свои ответы в XML отдавать умеет.

> Выше уже проскакивала здравая мысль выкинуть XML и заменить питоном.

Питон - жрущий память тормозной монстр. Спасибо, не надо. :)

Что же это за вменяемая БД, да еще и любая?

>>>Питон - жрущий память тормозной монстр. Спасибо, не надо. :)

Ну, не знаю. Я как-то пробовал грузить gtk интерфейс из glade-овского xml-я и непосредственно из интерпретируемого файла. Разницы не ощутил. При том что ручками править интерпретируемый файл гораздо приятнее.

>Ты какой-то совсем странный. Тебя никто не заставляет писать PostgreSQL - он уже есть.

это ты странный. Чтобы не юзать xml-конфиги предлагаешь держать на каждой машине постгрес :)

>Когда формат прикрывается GUI-мордой - всё равно что там.

именно. xml прикрывается гуёвой мордной. Но при этом его _можно_ править руками. Заметь - не _требуется_, а _можно_.

>Я утверждаю, что по сравнению с LaTeX связка docbook+MathML никуда не годится.

тем не менее злые буратины активно юзают dockbook :)

>Аналогично формат SVG не особенно смотрится рядом с MetaPost для целей ручного редактирования исходников.

svg - он не для ручной правки. Но его _можно_ править руками. Ты похоже, никак разницу не осиливаешь между _можно_ и _нужно_.

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

ниасилил про текстовые потоки. Что ты сказать-то хотел?

>А это... Правила для для этой конвертации писать не нужно?

xslt написать проще, чем парсер/конвертер

>>XML прост. Более простой формат для хранения древовидных структур, и при этом одинаково легко читаемый и человеком и машиной трудно придумать.

>lisp

tcl

>>не более нечитаем, чем конфиг того же sendmail :)

>lisp

tcl

Суть XML не в древовидных структурах. Для этого что угодно приспособить можно. Суть в первой строчке, где говорится какой DTD нужен. XML -- контейнер с биркой, по которой можно определить, что с ним можно делать и как. *.BIN -- контейнер без бирки. Вот и вся концептуальная разница. Ничто не мешает в одном единственном элементе, в base64 закодировать свои деревья в двоичном виде.

>>Преимущества linux нивелируется временем, потраченным на обучение, тренировку и исправление ошибок. Всем юзать венду!

>По существу сказать нечего, понимаю.

Лисп -- это язык 1950х годов для ламеров. Настоящие программисты используют C++ или Delphi.

>>в большинстве случаев можно обойтись обычным диффом. Видимо, более утонченный diff, способный сравнивать деревья двух файлов игнорируя переносы и отступы никому пока не понадобился

>Это наверное для пол страничных файлов обычный дифф сойдёт.

Такой diff сделать не сложно. Странно, что до сих пор его нет. (хорошо, Я НЕ ВИДЕЛ, БЕСПЛАТНОГО, мне вот применительно к html интересно)

Почитал комменты...мда...дилетанты наступают! Несколько тезисов: 1. XML - текстовый язык разметки. Но XML не является языком программирования! Он создан для решения совсем иных задач. Если Вам нужен именно язык программирования, то лучшим решением будет C++, python, lisp etc. НО никак не XML! 2. XML - прекрасно справляется со своей задачей в любых масштабах. О "плачевном" опыте использования XML в "больших" и "средних" фирмах лично я слышу впервые. Однако, я давно знаю о том, что XML используется в крупнейших корпорациях типа IBM, SUN, Microsoft, Google etc. 3.Для XML и только для него написан такой прекрасный Язык Преобразования как XSLT. Он не требует навыков программирования и специалист со знанием этого языка стоит столько же, сколько стоит обычный HTML-кодер. Можно нанимать даже студента т.к. с XSLT очень легко разобраться самому, при помощи книжки за 200 рублей. 4. Парсер для XML есть даже в некоторых мобильниках с монохромным дисплеем. Совместимость/переносимость -- абсолютная. 5. Логика разметки проста для понимания. Она достаточно прозрачна для обеспечения прекрасной удобочитаемости при условии, что читающий использует специализированный XML-reader с цветовым выделением. Но эта проблема сейчас решаема с помощью обычного браузера типа Firefox.

> Это не silver-bullet, как его стараются представить маркетоиды.

silver bullet -- это, чаще, извиняюсь за выражение, кусок говна. принимать как аксиому. не спорить.

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

А нефиг руками писать. Не актуально.

> Спрошу по простому, по-телефонистски: Ребята, а какие проблемы XML умеет решать более успешно чем ASN.1, который придумали много лет назад?

ASN -- это не модно.

поддержу гика :)

во первых, ASN не может быть использован как замена XML
представьте веб страницу закодированную ASN .....

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

в третьих, XML не избыточен, если выразить XML через SExp
вот это будет просто жутко избыточным

в четвертых, парсеры XML очень просты - вплоть до пары сотен комманд ассемблера
в то время как SExp - потребует наличие интерпретатора

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

в шестых, да XML подмножество SGML
но SGML парсеров - раз, два (насчет два - неуверен)
XML парсер легко пишется и на ассемблере

ASN - это замечательно, только это не протокол, как тут выразились.

>Очень интересно послушать success story в результате гибкости такого подхода :)

Internet Browser какой нить видел? Content-Type: text/xml, Content-Encoding: gzip?

>> Я утверждаю, что по сравнению с LaTeX связка docbook+MathML никуда не годится.

>Только в редком случае, если нужны формулы и человек знает LaTeX. 99% документации проще написать в docbook - и редаткоры поддерживают и проблем с модулями нет и результат быстрее и без геморроя виден. Поэтому не надо преимущества 1% специалистов аппроксимировать на всех. :)

Редакторам нужен просто текст. XML там вовсе не причём. А делать с помощью docbook что-то большее чем разбиение теста на section ничем не лучше чем делать это же в wordе. Нет примущества над костылями.

Если хочется получить качественную твёрдую копию, то работа с XML утыкается в отсутствие инструментария. Даже O'Reilly в процессе печатной подготовки сначало всё в troff перегоняет, там правит, а затем печатает.

То что делать на XML просто с помощью LaTeX сделать так же просто. То что делать в LaTeX сложно с помощью XML скорее опухнешь, чем сделаешь.

Использовать XML весело - надо много чего написать и сделать. Ну и что что уже аналоги есть и колёса в отличии от наших там круглые, а не квадратные. Зато действие - гораздо интереснее чем результат. Как надо делать обработку текста мы изучать не хотим - хотим придумать своё. Возможно, это и случится лет эдак через двадцать - а пока эта технология голая.

>Это проблема не БД, а иерархических и рекурсивных структур.

Ну извини. Подобные существуют вне зависимости от твоего мнения о них.

Если бы еще все клоуны, которые присылают нам прайсы в формате XML поддерживались всех стандартов - мы бы не писали супер сложные парсеры, которые выслеживают эти ошибки и пытаются "выцепить" информацию из формата XML - то тогда я б сказал что XML - это хороший формат передачи данных .. - а так это нереально - Tab-delimiter текст наше все :)))

XML слишком сложен для всяких мелких фирм, даже компьютерных ...

>>Очень интересно послушать success story в результате гибкости такого подхода :) > Internet Browser какой нить видел? Content-Type: text/xml, Content-Encoding: gzip?

...и вот когда они начали применять text/xml и передавать его в браузер, количество времени, затрачиваемое их сотрудниками на обработку поступающей информации снизилось на 50% и доходы выросли на 30%, а всё благодаря встроеному в браузер отображению xml'я ))))) Особенно гибкость xml'я тут проявляется со всех сторон, неговоря уже о том что я ещё ниразу не встречал людей, читающих xml бразуером..

Потрясающая история получилась ? :) Хотя я бы мог щас предположить другие ситуации, когда http сервер передаёт куски xml'я в какой-нибудь специальный продукт )) только не браузеру всё же.. Но пока мне лень за тебя думать и воспринимаю всё так как ты написал ...

XML - это текстовая информация для машинной обработки. Т.е. дэ-факто набор инструкций.

Согласен - очень удобен. Но для мостров с неграниченными ( спецы + вычислителные мощности) ресурсами типа майкрософта и гуглятины.

ЗЫ

То что используется в команиях начиная со среднеих и заканчивая маленькими - это не есть XML о котором идет спор. Это __XML-подобный__ протокол/набор данных/согласаванный формат и т.д. Я утверждаю, что по полной кактушке в мелких и средних фирмах XML не используют. Баста.

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

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

Ты такой умный, слуший-да! А по-любому Билл Гейтс умнее тебя, или ты будешь спорить? Нет? И правильно. И поскольку он умнее тебя, то мы будем верить ему, а не твоему ошибочному мнению. А он сказал вот что http://xmlhack.ru/archives/2006/03/000146.html

Вышла новая OPERA

Дайт ссылку на доку или вводное описалово, аля getting started

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

может. только об бинарный формат ты точно глаза сломаешь.

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

А кто-то разве разрабатывал его для "хранения больших структур"? То, что ублюдки недоучившиеся программисты начали тянуть его куда попало не говорит о том, что XML плох и не пригоден ни для чего. Его и разрабатывали для небольших древовидных структур, в частности, хранения книг и прочих а-ля документов. А не БД_в_одном_большом_зумль_файле

>А он сказал вот что: "И вообще, вы знаете, это три моих любимых слова — «открытый», “XML” и «разработчик», и все они — в одной организации."

Неее, у него драйвер клавиатуры не правильно сработал(венда-ж). Там должны быть 3 слова: деньги, деньги, деньги.

> А по-любому Билл Гейтс умнее тебя, или ты будешь спорить? Нет? И правильно. И поскольку он умнее тебя, то мы будем верить ему, а не твоему ошибочному мнению

Именно поэтому ты никогда не будешь на месте Билла Гейтса :) И на тебе можно будет зарабатывать, раскидывая разный ширпортреб, через два года говорить что мы ошиблись - и на самом деле успех скрывается здесь, а ты заплатишь ещё 100$ потомучто это сказал твой умный Бог :) Он как раз поэтому и умный(точнее с хорошими знаниями в области продаж), что продаёт тебе всё подряд ))

А может кто-нибудь снизойдет до приземленных проблем обычного быдлокодера и расскажет как парсить бинарный или плайн текст пакеты приходящие от сервера например мммм.... используя JS?

>может. только об бинарный формат ты точно глаза сломаешь.

Неправильно логическую цепочку достраиваешь :) А надо это продолжить просто как то, что этот плюс в XML'е выдуманый и ничем не отличается от других форматов..