XML: за что его так (не) любят?

>Да что-же вы так привязались к синтаксису. Избыточен - так на то zip есть,

Имхо. Тут компрессия бессильна, ибо есть такие (напабаюс этава слова) Кастылищи(!), типа <node1 id='node2'>, шта... шта... вопщем - ахтунк это. полный. беспросветный.

А если таких пакетов 1000? 10^6? 10^9?

Его еще и парсить надо, и по дороге переписать несколько раз. Для того даже аппаратные XSLT-процессоры делают: вот на что люди готовы пойти, лишь бы Лисп не учить.

>Зато примеров sql реализаций с B-tree индексированием -- ну просто хоть жопой жри...

И что теперь в Jabber'е в сообщениях гонять SQL-дампы?

>>> Можно пример более быстрого plain-text решения с возможностью хранения древовидных категоризированных данных? >Нужно хранилище данных с нормальным индексированием - реляционные базы данных - твое все, и xml тут тебе пока врядли сильно поможет.

Ну и к чему тогда весь этот скоростной пафос?

> А если таких пакетов 1000? 10^6? 10^9?

Все-равно в случае мелких пакетов(менее 1 ip пакета) время пересылки будет на порядки больше времени парсинга и экономия на синтаксисе тебе не поможет. Основная нагрузка на проц будет создаваться кучей syscall-ов и переключений контекста.

> Все-равно в случае мелких пакетов(менее 1 ip пакета) время пересылки будет на порядки больше времени парсинга и экономия на синтаксисе тебе не поможет

Москвич? Или из какого другого государства к РФ отношения не имеющего.

Вообще 10^9 пакетов по 1000 байт - 10:9 панетов по 100 байт --- трафик нешуточной стоимости.

>И что теперь в Jabber'е в сообщениях гонять SQL-дампы?

см. выше.

> Ну и к чему тогда весь этот скоростной пафос?

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

>см. выше.

Да. Ты не поверишь, но Jabber'ом каждый день пользуюсь.

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

>Недостаток этого решения, имхо - нетривиальная реализация поддержки.

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

>в частности, к xml (но, сдется мне - в нем кастылищще на кастыле сидит, и подпорками погоняет...)

Ты - идиот? XML это 7 (семь) правил, описывающих формат хранения данных. Всё. Что ты еще пытаешься подразумевать под XML? Ты можешь сам делать с ним что хочешь. Никаких костылей. Полная свобода. В рамках 7-ми правил. Эти 7 правил гарантирую, что твой XML смогут прочесть через 140 лет и понять, что ты в нем хранил

Я любил XML очень сильно. А потом познакомился с YAML и эта любовь угасла

>И что теперь в Jabber'е в сообщениях гонять SQL-дампы?

Вот-вот. Скоро нас до этого наши двоечники и доведут

> нем кастылищще на кастыле

Если с русским языком ситуация будет усугубляться такими же темпами, то не через 140, а через 50 лет мы вообще прочесть ничего не сможем(и не только в XML).

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

ай маладец, да? Приписать оппоненту заведомо неверное высказывание, и с белском его опровергнуть! гениально! садись, пять!

> > Все-равно в случае мелких пакетов(менее 1 ip пакета) время пересылки будет на порядки больше времени парсинга и экономия на синтаксисе тебе не поможет

> Москвич? Или из какого другого государства к РФ отношения не имеющего.

> Вообще 10^9 пакетов по 1000 байт - 10:9 панетов по 100 байт --- трафик нешуточной стоимости.

Я говорил про скорость работы, а не про трафик.

Если трафика получается много - можно не использовать soap, можно сжимать данные (данные до 1Кб сжимаются примерно до 500 Байт), можно постараться кидать данные бОльшими кусками. Ясен перец у любой технологии есть предел применимости.

> Так что xml, в силу своей индус-триальной ориентированности, обречен на доминирование :)

Если уж заниматься BDSM'ом, то доминировать должен я, а не зумль. А посему в топку.

>Да. Ты не поверишь, но Jabber'ом каждый день пользуюсь.

ты не поверишь, но я - тоже. так что за мегадеревья ты там гоняешь?

> Человека? Устраивают. Но какой вменяемый программист будет писать парсер отступов

А что разработчики haskell уже перестали быть вменямыми?)

PS: сначала хотел написать про питон, но подумал что это будет сильно спортный вопрос)))

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

Обсуждать XML-ВООБЩЕ("XML: за что его так (не) любят?") совершенно бессмысленно.

Imho ты не до конца описал свою задачу:

> мне требуется простая весЧь: найти или придумать механизм, обеспечиваюший: 1. разделения целого на составные части; 2.взаимодействие между отдельными частями 3. взаимодействие целого с отдельными частями. 4. простое изменение человеком отдельных частей 5.простое изменение человеком взаимосвязей между частями. 6. ну, и по мелочам всякие вкусности, типа "разделение контента и дизайна" :) и т.п.

О чем я тебя и спросил:

> Можно подробнее, что такое "целое", что такое "часть". Да и фраза "управление контентом" звучит не совсем определенно, особенно в сочетании с gvim. Пока как-то совсем туманно.

Ответа пока не видел (если есть - прошу прощения).

Прошу уточнить, где именно ты хочешь применяь xml. Imho именно это и стоит обсуждать.

>Детский сад, мля. Назови мне тривиальный язык программирования.

Детский сад, мля. Причем тут язык программирования?

> Что ты еще пытаешься подразумевать под XML?

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

> Ты можешь сам делать с ним что хочешь.

пасиб. что б я без тебя делал?

>Никаких костылей. Полная свобода. В рамках 7-ми правил.

и только до тех пор, пока дерево, легким движением руки, не превратится в тык^W граф...

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

>Эти 7 правил гарантирую, что твой XML смогут прочесть через 140 лет

не исключено....

> и понять, что ты в нем хранил

не факт.

>А что разработчики haskell уже перестали быть вменямыми?)

А что, каждый вменяемый программист - разработчик haskell? Есть масса вменяемых программистов, которые даже деньги за это получают, профессионалы, и о хаскеле даже не слышали. И от этого они не становятся хуже.

Неумно это, писать парсер отступов когда есть S-выражения, JSON, XML да что угодно, ГОТОВОЕ. И вменяемый будет пользоваться готовым.

>>Эти 7 правил гарантирую, что твой XML смогут прочесть через 140 лет

>не исключено....

>> и понять, что ты в нем хранил

>не факт.

Если ты вменяем, смогут. А попробуй достань сейчас какой-нибудь файл 10 летней давности, созданный в советском редакторе Word&Deed, "Слово и дело" и попробуй вытащи из него данные, желательно за полчаса-час. Убьеш день, а кому это надо? А мне приходится с такими вещами дело иметь. И таких кривых бинарных форматов легион. У каждого умника свой

>>Недостаток этого решения, имхо - нетривиальная реализация поддержки.

>Детский сад, мля. Причем тут язык программирования?

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

>>Никаких костылей. Полная свобода. В рамках 7-ми правил.

>и только до тех пор, пока дерево, легким движением руки, не превратится в тык^W граф...

А как графы умудряются в реляционных БД хранить? Как-то умудряются же. И вообще, кто тебе сказал, что граф именно в XML лучше всего хранить?

Я тебе уже сказал, тебе нужна как минимум СУБД. Бери PostgreSQL, а с XML познакомишься в процессе

> А что, каждый вменяемый программист - разработчик haskell?

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

> Неумно это, писать парсер отступов когда есть S-выражения, JSON, XML да что угодно, ГОТОВОЕ. И вменяемый будет пользоваться готовым.

Ну дык! есть готовый YAML - с отступами. http://www.yaml.org/start.html

>ты не поверишь, но я - тоже. так что за мегадеревья ты там гоняешь?

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

А что до _просто_ древовидной информации - ну так XMPP спецификацию тебе в руки.

>О чем я тебя и спросил: проглядел

> Можно подробнее, что такое "целое", что такое "часть".

имхо, совершенно очевидно, что "целое" - это целое, а "часть" - часть целого.

>Да и фраза "управление контентом" звучит не совсем определенно, особенно в сочетании с gvim. Пока как-то совсем туманно.

Данная фраза использовалась исключительно в контексте преобразования xml2html. (вот гик и прицепился со своей ЦМС :) )

>прошу уточнить, где именно ты хочешь применяь xml.

можно считать (но зацикливаться на этом применении не стоит), что один из вариантов - именно www.

>А попробуй достань сейчас какой-нибудь файл 10 летней давности, созданный в советском редакторе Word&Deed,

естественно, о двоичных форматах речи не идет

>Если ты вменяем, смогут.

ну да, ну да... насколько я понимаю - xml не единственный инструмент. поэтому - хотелось бы использовать оптимальный. или вообще оказаться от идеи "всеобщей разметки".

>>Недостаток этого решения, имхо - нетривиальная реализация поддержки.

>При том, что назови мне задачи в программировании с тривиальной реализацией.

Нет-нет-нет! Речь ни в коем случае не идет о профанации! Только о том, чтобы при проектировании системы учесть все "узкие места" и постараться не набросать дополнительных граблей! А решение загнать текст (часть текста) в СУБД - это, в известном смысле - все же грабли, имхо.

>В программировании вообще тривиального ничего нет. Иначе vsl бы давно свою Metamachine сделал бы и ты бы пошел на дворника переучиваться

А вот хрена там! :) пульки-то нет! ;)

Готовым надо пользоваться, когда нужна интероперабельность, или когда готовое имеет приемлимое качество. Своё надо делать, когда важна производительность. Вот и вся разница.

Но с отступами - оно как-то действительно глупо. Очень неэффективно. Так уж лучше использовать вообще стековый (безскобочный) вариант.

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

да ты че? натурально? или таки шутить изволишь? Тогда вынужден повториться:

к чему был весь этот "скоростной" пафос, коли ничего кроме "_просто_ древовидной информации - ну так XMPP спецификацию тебе в руки" тебе, в общем-то, и не требовалось? или сегодня это самый модный способ слить?

> При том, что назови мне задачи в программировании с тривиальной реализацией. В программировании вообще тривиального ничего нет.

В программировании всё тривиально. Только для работы с этой тривиальностью пока что самый дешевый инструмент - мозг человека-обезьянки. Для брутфорсовых методов автоматического вывода решений, увы, шибко дорогие и жирные компьютеры пока требуются. Но это меняется, за последние годы много полезных новых алгоритмов для constraint solving было придумано.

> и ты бы пошел на дворника переучиваться

Хрен. Когда программирование окончательно автоматизируют, я переучусь на специалиста предметной области, и буду решать те же задачи, только быстрее и проще, так как меньше надо будет быдлокодерить. В дворники даже 1Совцы не уйдут.

>А как графы умудряются в реляционных БД хранить? Как-то умудряются же.

нуу... тут-то как раз все проще: отсутствует вариант запихивания таблицы в таблицу :)

>И вообще, кто тебе сказал, что граф именно в XML лучше всего хранить?

да и я, в общем-то, о том же...

>Я тебе уже сказал, тебе нужна как минимум СУБД. Бери PostgreSQL,

субд решает многое. это да.

> а с XML познакомишься в процессе

что зачит "в процессе"? O_O методом проб и ошибок, что ли? спасибо, я пешком постою.

> А что разработчики haskell уже перестали быть вменямыми?)

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

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

В крови анонимусов?

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

Способен. Зависит от задач. Для реализации веб-проектов вполне подойдёт.

> > а с XML познакомишься в процессе > что зачит "в процессе"? O_O методом проб и ошибок, что ли? спасибо, я пешком постою.

"В процессе" - значит тогда, когда возникнет необходимость подружить свой продукт со сторонними разработками. Например, реализовать обмен данными с каким-нибудь orsn.rambler.ru или Яндекс.Маркет. Да взять хотя бы те же Google Sitemap.

> Для реализации веб-проектов вполне подойдёт.

А для документооборота? ;)

Выше - даже анонимус подтвердил мои опасения о малопригодности xml для хранения графов. (точнее - хранить-то можно, но тогда теряются все преимущества)

Так что - уже - "не вполне"...

>>нечитаемо. Часто надо видеть - какой закрывающий тег(скопка) к кому относится

>А, понял. В твоём любимом языке и IF закрывается как ENDIF, и DO как CONTINUE. Я угодал?

Детка, ты хоть раз видел исходники С\С++ ? Ты никогда не задумывался, почему к закрывающим скобкам там часто дописывают "\\ if" или "\\ for" ? А ведь в любом приличном редакторе есть подсветка парных скобок.. ;)