А что, IMHO правильно написано. IMHO. no flame.

>*) Лекарство - хуже болезни. Сложность XML превышает сложность тех проблем, которые эта технология решает.

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

>*) Даже программам не просто парсить XML. С точки зрения человека XML-инструкции в тексте избыточны и совершенно не читаемые.

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

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

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

>*) Сделать вменяемый аналог diff для XML-файлов весьма проблематично.

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

ps: имхо, бред. Не нравится - не используйте. А уж осилить XML способна любая человекообразная обезьяна, осилившая клавиатуру

geek прав.

Подписываюсь под каждым словом geek'а.

"Тотальное" использование XML может нанести серьезный удар по производительности. Использование XML security в веб-сервисах, как говорили спецы, очень элегантно, красиво и надежно, но на обработку всего одного запроса уходит порядка 800 ms на очень хорошем оборудовании!

>в большинстве случаев можно обойтись обычным диффом

Я полагаю что все дело в том, что в большинстве случаев xml сохраняется одной длинной строкой. Diff тут не справляется.

Но это проблемы diff, а не xml. А так полностью согласен по всем пунктам.

> Тотальное" использование XML может нанести серьезный удар по производительности. Использование XML security в веб-сервисах, как говорили спецы, очень элегантно, красиво и надежно, но на обработку всего одного запроса уходит порядка 800 ms на очень хорошем оборудовании!

так запрос-то надо выполнить :) Бинарный запрос типа быстрее будет...

xml в сочетании с xsl(t) рулит...

Хотите чтобы над вами посмеялись? Расскажите Lisp программисту, зачем вам понадобился XML. (c) кто-то.

Вроде не гном против кде, но и тут гик отметился!

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

lisp

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

lisp

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

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

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

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

>Не нравится - не используйте.

+1

>А уж осилить XML способна любая человекообразная обезьяна, осилившая клавиатуру.

Кесареву - кесарево, а XML обезьянам!

> Даже программам не просто парсить XML

Мда, я фигею, товарищи... Да я даже на bash (!) ради спортивного интереса XML научился парсить!!!

В большинстве ты прав, правда, совать его везде, даже там, где он вреден - моветон и крайне нецелесообразно.

>Сделать вменяемый аналог diff для XML-файлов весьма проблематично.

здрвая логика подсказывает что если разодрать xml на древовидную структуру - значения каждого узла в свой файл а потом сделать обычный diff то всё будет ОК. в xml узлы упорядоченны, так что никаких проблем со сравнением быть не должно.

тут проблемы даже не алгоритмические, а кодерские. нужно просто реализовать ещё одну тулзу, чуть более сложную чем diff.

XML говно .... но лучше пока не придумали.... вернее прилумали .. но применять упорно не хотят

Что придумали? на языке типа python писать? или как?

Был на кофе одной местной. Опыт внедрения XML в мелких и средних фирмах в основном плачевный. Это не silver-bullet, как его стараются представить маркетоиды. И пихать его везде где нужно и нет - это тоже самое что все проги на PHP начать писать. ВСЕ.

robot12, домашнее задание сделал? завтра понедельник.

>lisp

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

My conjecture is that XML dialects are going to include abstractions for conditionals (if/then/else) and iterations (for/while/repeat) - or they most probably already do. So when you read in XML fragments and evaluate those constructs, you are actually writing an interpreter for a programming language. Except that you write your interpreter in a different language (say, Java or Smalltalk) than the source language (your XML dialect). And you need to take care of parsing, internal representations, namespaces, and so forth. In Lisp, you just write a bunch of macros and functions, and you're done. This new set of macros and functions is just another set of sexprs, so afterwards you can even create another level on top of them, for exampler checkers that check for the correctness of your macros, program transformations that weave in treatment of multithreading, security restrictions, and so on, whatever you need. And guess what, all these layers can be compiled into machine language by Lisp compilers, instead of being executed by dumb interpreters written in Java, or other languages that artificially distinguish between code and data. (Yes, the distinction between data and code is an artificial one, inside a computer there is no such distinction. That's where the power of computers really comes from. Lisp is the only language that gives you this power directly, without artificial boundaries, and in a very usable and easily comprehensible way. Sexprs might be harder to read than traditional languages at first, but they are relatively easy to comprehend when taking the power into account that they give you.)

Я-же говорю. Обезьянам XML - нормальным людям другие инструменты.

Это ты наверное на лабах в универе со скобочками боролся. У нормальных людей таких проблем не возникает.

>Это ты наверное на лабах в универе со скобочками боролся. У нормальных людей таких проблем не возникает.

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

XML идеально сочетается с OpenDocument
Смотрите внутри любого od? файла

>My conjecture is that XML dialects are going to include abstractions for conditionals (if/then/else) and iterations (for/while/repeat) - or they most probably already do. So when you read in XML fragments and evaluate those constructs, you are actually writing an interpreter for a programming language

бред. "XML может включать условные секции и итераторы и поэтому XML не нужен. Ведь есть lisp"

маразм фанатствующего лиспера. Т.е. пихать XML во все дыры - это зло, а вот пихать lisp во все дыры - это добро. Вот оно где, красноглазие-то :)

(:tag-start item1 item2 item3 :tag-end)

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

>Но это лишнее по-моему. У меня проблем с расстановкой скобок не возникало.

то что у тебя нет проблем - это не значит, что их не будет ни у кого :)

>Валидатор, я так понимаю, соответствие скобок проверять не должен. это делает интерпретатор лиспа

предлагаешь интерпретировать документы? жесть :)

ИМХО суть не в том, что XML плох, а в том, что зачастую его применение не оправданно. А суют его в каждую дырку сейчас, ибо это модно стало.

ИМХО применять XML нужно лишь в случае, когда это действительно оправданно - для тех же древовидных структур данных, например.
А переписав обычный plain конфиг файл в XML вы просто усложнили жизнь человеку, которому возможно придется этот файл править да и просто читать. Да, облегчили обработку этого файла МАШИНОЙ. Но мы что, для машины XML создавали, чтобы облегчить ее труд? Человек должен думать, машина - РАБОТАТЬ.

P.S. Статью еще не прочитал.

про "]" в лиспе все дружно забыли. нужно бить программу на адекватные куски - тогда проблем с миллиардом скобочек не будет

>про "]" в лиспе все дружно забыли. нужно бить программу на адекватные куски - тогда проблем с миллиардом скобочек не будет

а что, xml-документ - это программа? С какого перепугу стали xml с лиспом сравнивать?

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

Докажи.

> Хотя...ввести лисп в школьную программу - замечательная идея. И чтобы оценка шла в аттестат :)

В америке так, все живы:)

>Опыт внедрения XML в мелких и средних фирмах в основном плачевный.

А опыт внедрения diff какой? XML такой же инструмент, как и diff, или Lisp, они Lisp не пробовали "внедрять"? Идиоты. XML внедрять не нужно, нужно с его помощью решать задачи, которые без него решаются дольше|дороже

XML хофно. Нечитабелен, парсить тяжело и т.д.

Технология, возможно, и хорошая... но вот один пример...

Всем знаком fontconfig? После преобразования его конфига в XML смотреть и править стало проще?

Повторить полностью XML с помощью Sexpr можно, а наоборот только с более захламлённым ситаксисом -> Sexpы хреновее. А так Sexpr и XML одинаковы, просто Lisp проще.

<progn> <setf var="a" val=10 /> <printf var="a" /> </progn>

Пиши интепретатор -- будет программа.

> XML идеально сочетается с OpenDocument > Смотрите внутри любого od? файла

ну и нафига там xml? часто ты od? файлы вручную правишь? бинарный формат, имхо, был бы более эффективен, что пожатый xml

>Докажи.

(text (bold "SOMETEXT" (italic "SOMETEXT" (underline "SOMETEXT")))

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

><progn> <setf var="a" val=10 /> <printf var="a" /> </progn>

>Пиши интепретатор -- будет программа.

нафуя?

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

самое интересное в том что и человеку и машине удобней работать с обычными ini файлами чем с xml

>бинарный формат, имхо, был бы более эффективен, что пожатый xml

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

>самое интересное в том что и человеку и машине удобней работать с обычными ini файлами чем с xml

в ini-файлы дерево не запихнешь :)

кстати, xml-ненавистникам предлагаю отказаться от веба. html же так похож на xml! а xhtml вообще не отличишь. :)

> в ini-файлы дерево не запихнешь

При желании можно и запихнуть:

[top]
root = foo

[root:foo]
bla = ...

Только читабельность страдает...

Кстати вот вам diff для XML: http://alioth.debian.org/projects/ssddiff/

в майкрософте запихали, .reg - дерево в ini файле

Ну да, оба - урезанный SGML. Просто Тим Бернс-Ли www.w3.org/People/Berners-Lee/ сделал кривой порт HTML, а Тим Брей исправил его косяки и сделал правильный порт XML

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

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

это вещи предназначенные для разных целей
хотя если утверждать что xml предназначен для обмена данными
то ASN будет просто ... эффективнее

в общем - все сводится к задаче

сева, ты ?

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

Вообще-то тут даже предлагать не надо :) Все давно так и делают. Думаешь, что происходит с .emacs, когда он загружается?

geek, как это "трудно придумать"? S-выражения придумали куда раньше чем XML, а они по всем параметрам проще и удобнее.

Рулит CDuce. А XSLT сосёт.

С поддержкой DTD, Schema, Relaxed schema, неймспейсов и прочей подобной мудени? Ну ну. Лжешь.

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

А чё, разработчики xml стремилмсь к sendmail.cf как к идеалу? Ну, тогда понятно всё. Как по мне, так для обычного слабодревовидного конфига ничего лучше, чем ini, просто не бывает.

> ps: имхо, бред. Не нравится - не используйте. А уж осилить XML способна любая человекообразная обезьяна, осилившая клавиатуру

А вот и вопрос - если ли смысл его осиливать-то? В большинстве случаев он просто не нужен. Но его усердно пихают повсюду. Патамушта модно, пилять.

Есть лучше представления:
---8<---
title1=Total Updates = 25
title1.font.size=15
title1.color=black
title1.font.shade.depth=0
title1.position=south
---8<---
где кстати такая важная величина для передачи информации в шумовом канале (а канал свегда шумный тем более когда говорим о хранении и/или конфигах) как mutual information (сорри за англ.терм) гораздо выше а энтропия ниже чем у XML.
Удалим блок соседних байтов из вышеприведённого блока (скажем - 10 байт). Потеряем максимум - 2 строки (пару пропертей).
То-же самое напишем на ублюдочном XML который разрабатывался как языко-независимая _структура_ (т.е. почти бинарный формат) - потеряем информацию о вложенности/иерархию. А оверхед скобок - вообще превышает оверхед дублирующей/полезной информации случая строк.
В этом смысле любая rule-based нотация гораздо лучше структурной.
(поэтому пролог больше люблю чем лисп).
Пример хорошего rule-based конфига - ipchains. Или CSS (а не xsl, по поводу чего можно долго ругаться - не охота начинать, а это большой топик)

xml пришёл на волне доткомов когда наивные, незнакомые с grep/sed/awk итд, дотком-открыватели брали самое последнее д.мо как наипоследюю технологию. А потом уже поздно - всюду стандарт (стандартизаторам тоже кушать хочется, просиживая штаны в комитетах).

Всё равно умрёт это убожище когда-нибудь (оставшись максимум - как _структура_ передачи в IPC) - потому что ущербен, попомните мои слова.


Anode