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

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

А никто никогда и не сомневался, что гномеры и прочие любители xml работают на производителей железа. У них оргазм, когда проц впустую молотит бессмысленные данные, грея воздух в серверной. А то гику там зимой сидеть холодновато :)

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

А если ты в алгоритме обработки XML ошибешься у тебя типа все правильно откроется, да?

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

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

Anode

И последнее (не менее важное):
xml НЕ МАСШТАБИРУЕМ.
проперти могут быть бесконечным стримом (строка будет влезать в память), а xml - если мы говорим о xml/xsl - не может использовать инкрементальный парсинг, или он будет заниматься перепарсиванием одного и того-же (если использовать чистый sax). Но не могу себе представить бесконечный xml стрим - всё равно (хотя со строками - это обычный случай и sed со товарищи хорошо там работает).

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

yaml проще. И кстати более diff-friendly.

2 Anode * (*) (10.04.2006 0:32:09):

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

Я о таком немного думал, когда оценивал возможность реализации формата .fb2 (FictionBook) на однокристалке с LCD и маленьким ОЗУ (килобайт 16 или около того) - сверхдешевую электронную книжку сделать, например.

Просто для всех "точек приостановки" нужно помнить контекст разбора и application-level-контекст, и тогда можно парсить вообще потоком прямо с флэшки, ничего не считывая в память надолго и отрисовывая на экран прямо на лету, без промежуточного запоминания. И ходить по документу туда-сюда, кэшируя некоторое количество точек остановки со всем контекстом и перепарсивая только то, что действительно нужно - от предыдущей имеющейся в кэше точки остановки до точки, до которой хотим добраться.

/vap

Смешались в кучу кони, люди... Почему ребята, если они такие вумные, хотя б не разделили претензии к Infoset и претензии к _самому_распространенному_ (но не единственному) синтаксису?

>Но не могу себе представить бесконечный xml стрим - всё равно

покури xmpp - и может, сможешь себе представить

>title1=Total Updates = 25
>title1.font.size=15
>title1.color=black
>title1.font.shade.depth=0
>title1.position=south

бугага


>где кстати такая важная величина для передачи информации в шумовом канале

у тебя диски битые? или tcp уже не гарантирует доставку пакетов? А может, ты предпочитаешь, чтобы система могла прочитать и обработать битый файл, невзирая на последствия?

и кстати, если вместо title1 у тебя будет какое-нить длинное слово/выражение - не будет ли оверхед поболее чем в xml?

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

корнями xml уходит гораздо глубже, чем "волна доткомов"

>Всё равно умрёт это убожище когда-нибудь

я почему-то уверен, что ты умрёшь раньше =)

>А если ты в алгоритме обработки XML ошибешься у тебя типа все правильно откроется, да?

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

>А никто никогда и не сомневался, что гномеры и прочие любители xml работают на производителей железа. У них оргазм, когда проц впустую молотит бессмысленные данные, грея воздух в серверной. А то гику там зимой сидеть холодновато :)

ананимусам очень рекомендую покурить понятия "самодокументированный формат", а так же ознакомится с dtd и xslt как минимум. А только потом выплескивать продукт своего "мышления", который они по незнанию считают "мыслью", на форум

Мужыки! Блин! В чем здесь новость? Этой теме на Вардовской вики сто лет в обед, я ее лично уже более чем полгода читаю (кстати, уже тогда она устаканилась и практически не изменяется). Таки античный баян.

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

Небольшое уточненьице. Подстраницу, выделенную из этой, в последний раз редактировали почти год назад. Значит, этой странице год или больше.

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

1 TagName1 Blah-Blah-Blah
2 TagName2 nm,n,k
2 TagName3 blnjh
1 TagName1 MyMyText

Поди хуже мэрзкого xml ;)

>Но это проблемы diff, а не xml

Нет - это проблемы формата, разрешающего такие безобразия.

Все правильно написано, xml в сложном документе только все усложняет. Если кто имеет понятие о jsp и может его сравнить с freemarker знает о чем я.

> ---8<---
> title1=Total Updates = 25
> title1.font.size=15
> title1.color=black
> title1.font.shade.depth=0
> title1.position=south
> ---8<--- 

Тут чем больше вложенность, тем больше лишних символов получается
(title1.title2.title3.titleN.)

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

+1

>То-же (с точки зрения теории информации) - с реляционными базами, но это большой флейм и не хочется его начинать

Мне кажется, что реляционная база всё-таки обычно проще в использовании, поэтому живёт. А проще в использовании, потому что выглядит похоже на десктопные таблички а-ля Excel....

Вон, в той же Cache' реляционный интерфейс к данным натянули сверху на дерево. Кому нужна максимальная скорость - не используют это, и всего делов.

>если ты ошибешься в алгоритме обработки xml - то у тебя вообще ничего не откроется.

Не прикидывайся дурачком ;) Речь не про разбор собственно xml, а про разную обработку прочитанных данных. Если *.doc файл забить рандомным потоком - то тоже "ничего не откроется".

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

То есть как раз описанная ситуация с разницей вордовских файлов разных версий, верно? ;)

"Где разум, где логика?" (c)

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

Маска, я тебя знаю!
Ты - "Яндекс.Весна". Единственный, кто прочитал $(subj) ;)

>>>Но не могу себе представить бесконечный xml стрим - всё равно

>покури xmpp - и может, сможешь себе представить

Ещё раз попробуй прочитать протокол xmpp, только теперь не его название и то что он на xml'е.. а ещё дочитай до внутреностей.. Очень будет интересно найти где там xml стрим идёт )

p.s. до сих пор не понимаю насколько сильно надо было головой об унитаз ударится во время придумывания гениальных идей и протолкнуть так хорошо протокол для месэнджера на xml'е.

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

Мне понравились данное состояние описания сложности
<quote>What is too complex?
* Schemas (Any complete mechanism for this will be pretty complex. Provide counterexamples which are more elegant.)
* Namespaces (namespaces are hard?!?)
* DTDs (dude, DTDs are easy )
* XSLT (XSLT when well written is readable by those who can't program.)
* The myriad of half-baked XML standards. (Well, that's true, at least.)) </quote>

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

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

XML пусть живёт там, где ему место - то есть как замена закрытым бинарным форматам.

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

А те конкурсы программ одной строчкой (на с, перле, итд) - это значит проблемы языка :).

Но diff и впрямь очень неэффективен при работе со словами а не со строками. Взять любой патч - при замене 1 буквы в коде diff дает несколько строк.. Это не только к XML относится.

Кстати, большинство проблем с XML решаются написанием XSLT. Вот это-то не так уж и просто сделать как сам XML документ.

Ну все, теперь Линуксу точно конец!

>Ещё раз попробуй прочитать протокол xmpp, только теперь не его название и то что он на xml'е.. а ещё дочитай до внутреностей.. Очень будет интересно найти где там xml стрим идёт )

и чем же тебе там не stream?

>p.s. до сих пор не понимаю насколько сильно надо было головой об унитаз ударится во время придумывания гениальных идей и протолкнуть так хорошо протокол для месэнджера на xml'е.

именно благодаря xmpp клиент не перестает работать когда на сервере реализуют новые фишки. Или наоборот - отсутсвуют какие-нибудь (muc например). Любители аси хорошо знают все прелеси бинарного протокола :)

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

возьмем корпоративные сети. Задача - хранить и управлять централизованно парой тысяч компутеров. Хранить доменные/групповые/индивидуальные конфиги в БД - хорошая идея? генерировать на основе данных в БД xml-конфиги - элементарно. Распарсить xml-конфиг и засунуть его в базу при изменении на одной машине - тоже элементарная задача. В случае зоопарка форматов конифигурационных файлов, как это имеет быть сейчас - такое централизованое управление без создания парсеров и валидаторов на _каждый_ конфигурационный файл нереально. Альтернативы? Придумывать новый xml, где угловые скобочки будут заменены на обычные, как это предложили лисперы? Имхо, маразм. Маразматичнее просто трудно придумать

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

Альтернативы plain text с разделителем в виде пробелов или набор пар "перменная - значение" - парсить ещё проще, а для восприятия при редактирование вообще элементарно.

Для изменения конфигурации одной машины вытряхивать весь конфиг из БД (коли уж мы его туда за каким-то лешим запихали) смешно - достаточно этой одной машины.

XML это конечно технично, модно, красиво, но глупо.

>Альтернативы plain text с разделителем в виде пробелов или набор пар "перменная - значение" - парсить ещё проще, а для восприятия при редактирование вообще элементарно.

у того же bind конфиги не укладываются в такую схему. У апача тоже. Чё делать-то? Придумывать новый XML, но без раздражажающих тегов? Подозреваю, что в итоге получится чудовище, ничем не лучшее чем уже существующий xml :) А валидатор на каждый тип конфигов кто писать будет? Пушкин? В случае использования xml проверка конфигов на корректность выполняется элементарно.

>Для изменения конфигурации одной машины вытряхивать весь конфиг из БД (коли уж мы его туда за каким-то лешим запихали) смешно - достаточно этой одной машины.

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

>XML это конечно технично, модно, красиво, но глупо.

аргументов о "глупости" xml я так и не увидел :) Подумай ещё

> и чем же тебе там не stream?

Тем что пока не пришёл весь этот стрим, его нельзя начать обрабатывать..(или я ошибаюсь ?).. а может там идёт чтение первых значений, пока весь этот ХМЛьный шлак сливается, чтоб получить лэйтэнси поменьше ? :)

> именно благодаря xmpp клиент не перестает работать когда на сервере реализуют новые фишки. Или наоборот - отсутсвуют какие-нибудь (muc например). Любители аси хорошо знают все прелеси бинарного протокола :)

А в бинарном протоколе это нельзя сделать ? )))

Что там у нас в аське.. уже не помню этат оскар.. в FLAP'ы обёрнуты кто-то там на S :) которые состоят из type/subtype/tlv .. И неужели нельзя игнорировать там новые возможности, которые идут в tlv ? :) или целиком некоторые типы пакетов )

Или я непонимаю чего-то ? ) Ато XML-то я давно невзлюбил, но видать эта некая великая сила, без которой щас никто не может обойтись ))

>Альтернативы? 

(load "config.lisp")

Вот оно и прочиталось и распарсилось.

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

<eq>
<sum>
<value>2</value>
<value>2</value>
</sum>
4
</eq>

Очень читабельно. Спасибо. По любому глаза поломаешь и обязательно ошибёшься.

Да и толку от этого формата нету никакого. В простых случаях рулят ini файлы, а в сложных зумль просасывет с причмоком. Попробуй для начала переписать .emacs на xml. А мы посмеёмся. 

>Тем что пока не пришёл весь этот стрим, его нельзя начать обрабатывать..(или я ошибаюсь ?).

ошибаешься. Обрабатывается же :)

>А в бинарном протоколе это нельзя сделать ? )))

можно наверное. Только вот работать нормально с таким протоколом сможет только один клиент - тот, который напишут авторы "протокола"

>Что там у нас в аське.. уже не помню этат оскар.. в FLAP'ы обёрнуты кто-то там на S :) которые состоят из type/subtype/tlv .. И неужели нельзя игнорировать там новые возможности, которые идут в tlv ? :) или целиком некоторые типы пакетов )

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

>Или я непонимаю чего-то ? )

думаю, что не понимаешь :)

>Ато XML-то я давно невзлюбил

"патамучта ниасилил"? =)

>Попробуй для начала переписать .emacs на xml.

Мне лично хватило увидеть то, как выглядит решение квадратного уравнения на MathML. Причём в ТЗ при создании этого уродца было прописано, что человек должен легко редактировать текст в _текстовом_ редакторе с элементами MathML.

>Вот оно и прочиталось и распарсилось.

про скобочки смотри выше. И про пихание лиспа во все щели - тоже см. выше.

>Очень читабельно.

дада. А ещё нелюбители xml приводят такой пример

<pixel>
<red>255</red>
<green>255</green>
<blue>255</blue>
</pixel>

конечно, это прямо свидетельствует об ущербности xml

>Попробуй для начала переписать .emacs на xml.

А зачем? лисп тебя в чём-то не устраивает?

>ошибаешься. Обрабатывается же :)

Постоянным перепарсиванием одного пакета ?

>можно наверное. Только вот работать нормально с таким протоколом сможет только один клиент - тот, который напишут авторы "протокола"

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

XMPP открытый протокол, что мешало делать бинарный ?

>"патамучта ниасилил"? =)

да, когда начинал осиливать, мой слабый разум подвергался таким мучениям из-за того что не мог понять "так в чём же сила, XML?"

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

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

>Постоянным перепарсиванием одного пакета ?

не угадал. Кури дальше

>XMPP открытый протокол, что мешало делать бинарный ?

ни что не мешало. А чем плох тот xmpp, который мы имеем?

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

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

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

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

>Зачем переформатировать данные из реляционного вида в иерархический?

Если это можно сделать - то они обязательно это сделают, и скажут что это большой плюс :) Потом рядом пробежит масса чудиков, которые собирают эти положительные стороны и начнут всё делать в XML'е..

>>XML это конечно технично, модно, красиво, но глупо.

>аргументов о "глупости" xml я так и не увидел :) Подумай ещё

Это означает что ты (далее следуют варианты)

а) реально с этой технологией не связывался, а если и связывался, то только на простых примерах, которые можно реализовать как угодно.

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

в) болеешь заразой под названием "всё знаю в теории" - жизнь обычно немного другая.

г) слепой

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

>>Сети иногда падают :)

Для BDB или SQLlite требуется сеть?

>Для BDB или SQLlite требуется сеть?

:))))

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

>>>Сети иногда падают :)

>Для BDB или SQLlite требуется сеть?

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

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

Про BDB, SQLite и vim ничего не знаю, но PostgreSQL можно в emacs поправить - развлекался как-то. Но IMHO нет особой необходимости.

>а) реально с этой технологией не связывался, а если и связывался, то только на простых примерах, которые можно реализовать как угодно.

связывался :)

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

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

>в) болеешь заразой под названием "всё знаю в теории" - жизнь обычно немного другая.

а ты, судя по всему - один из ниасиливших. А раз "ниасилил", то это не ты тупой, а технология кривая. Так?

>г) слепой

:)))

>Итого читай ссылку, которая предоставлена в новости. Для этого надо знать английский, естественно. Там гораздо всё более подробно рассмотренно. XML не особо-то и меняется - ведь тогда пропадёт эффект узнавания (ба - да я это где-то видел), так что все тамошние аргументы в силе

читал. не согласен с автором. Ещё вопросы?

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

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

>ни что не мешало. А чем плох тот xmpp, который мы имеем?

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

>любой xml-файл можно преобразовать в любой другой текстовый файл простым применением xslt

1. кто будет хранить тонны данных в xml, чтоб заниматься их преобразованием ? Или хранить данные в xml - это удобно ? ))

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

3. А может вся сила к примеру в таком геморрое под названием SQL->MyProgram->XML+XSLT->Parser->HTML/WML/итд ? Кто-то этот долгий путь находит удобным ? ))) Опять же получается большая избыточность, и выдуманое удобство.. Но зато как часто встречается щас эта схема ..

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