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

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

следует ли это понимать как "забей на этот МегаМультиКастыль, и не морочь себе голову?"

Вот и попробуй XSLT скормить такой xml без управляющей структуры.

Следует понимать, как "включи мозги и используй там где выгоднее".

Не, ну КДЕ-и у всех разные. Ну нету у меня ни одного зумля тама...

>я всё пытаюсь выяснить, куда ты пытаешься приткнуть зумль для "управления контентом" :)

ппц... 3-тья страница... Ты бы сходил на первую, к началу ближе, там камрады влет догнали...

> "порог вхождения" для этой штуки более высокий

ой ли, XML намного сложнее и нечитаемее чем sexpr и yaml (и JSON ещё забыл), и ведь юзают, просто он распиаерен. Насчёт sexpr конечно не уверен что он пойдёт в массы, потомучто его не пиарят, а вот YAML и JSON вполне.

>ой ли, XML намного сложнее

Нихрена. просто там "многабукав", сьало быть "фтопку".

>ппц... 3-тья страница... Ты бы сходил на первую, к началу ближе, там камрады влет догнали...

я тебя и на первой странице спрашивал. Ты не ответил

>Каким хреном вообще CMS относится к чисто веб-программерской задаче разделения контента и дизайна?

Ты лучше у гика спроси, а то он со своей ЦМС уж сто постов расстаться не может.

>я тебя и на первой странице спрашивал. Ты не ответил

я тебе и на первой странице ответил. Но ты прослушал.

Ладна, не деритесь! Не должны нормальные пацаны из-за "индусских" раскладов сраться. Не сочтите за нацпол.

Вот будет когда конфиг ядра на зумле - тогда и посмотрим...

>>ой ли, XML намного сложнее

> Нихрена. просто там "многабукав", сьало быть "фтопку".

вот я почему-то сомневаюсь, что средствами xml можно "структурировать любые неструктурированные данные". Это так?

>вот я почему-то сомневаюсь, что средствами xml можно "структурировать любые неструктурированные данные". Это так?

пример неструктурированных данных в студию

>я тебе и на первой странице ответил. Но ты прослушал.

ты так и не ответил, что тебе нужно от xml

>пример неструктурированных данных в студию

$self (данный топег). В чистом виде неструктурированный поток сознания.

>$self (данный топег). В чистом виде неструктурированный поток сознания.

замечательно структурируется по { автор, сабж, текст, дата постинга, ответы : [] }

:)

собственно KConfig'у как и его родителю QSettings глубоко пофик зумель там или ini

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

>пример неструктурированных данных в студию

лови:

"пример неструктурированных данных в студию"

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

кончно же, имелось ввиду, что, имхо - xml не годится для описания _любых_ данных...

>ты так и не ответил, что тебе нужно от xml

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

> Однако, не ошибусь, если скажу, что "порог вхождения" для этой штуки более высокий.

Порог вхождения более высокий?!? Да ну? Простые и понятные закрывающие скобки (а не повторение открывающей как в XML), нет никакого барахла вроде entities, вообще весь синтаксис очень тупой и легкозапоминающийся, запись получается заметно короче за счет меньшего количества синтаксического мусора.

Сравни:

<arith oper="+"><arg><var>x</var></arg><arg><var>y</var></arg></arith>

и та же хрень в SXML:

(arith (@ (oper "+")) (arg (var x)) (arg (var y)))

>"пример неструктурированных данных в студию

можно структурировать как один элемент (строка), как несколько(слова) и как многабукв. И дергать их по индексу. Ы?

>кончно же, имелось ввиду, что, имхо - xml не годится для описания _любых_ данных...

а кто-то говорит, что любых?

>и та же хрень в SXML:

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

Если тебе требуется интероперабельность с говнософтом, понимающим только XML, то тебе нужен XML. В ЛЮБОМ другом случае тебе не нужен XML, потому как есть множество гораздо более умных решений.

>замечательно структурируется по { автор, сабж, текст, дата постинга, ответы : [] }

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

> <arith oper="+"><arg><var>x</var></arg><arg><var>y</var></arg></arith>

Очень напоминает


<pixel>
    <red>122</red>
    <green>100</green>
    <blue>90</blue>
</pixel>

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

например? а то сходу не могу представить

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

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

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

не угадал. ;)

>Я вот не знаю ни единой ситуации, когда надо было бы видеть, какая скобка что закрывает. Когда у тебя умный текстовый редактор (то есть, emacs), он тебе это покажет в тех редких случаях, когда таки захочется посмотреть конкретно. В остальных случаях слишком конкретные закрывающие скобки будут только мешать.

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

> 1. В правильном XML из 100 кб файла 50-60 кб. мусора (то есть вполне можно сохранить файл той же информационной ценности, не в бинарном формате)

zip при передаче/хранении всех уравняет =)

> 2. Данные при выводе из XML можно обработать 1 раз в минуту, ну 10 раз в минуту (нагрузка). Но не по 10 раз в секунду. Рано или поздно приходится делать КЭШ в формате идентичнов выводимому (это любителям использовать XSLT+XML для сайтостроительства)

Используя xslt часть этой нагрузки можно перенести на пользователя. Насчет конкретных цифр - зависит от реализации.

> 3. Пресловутая ручная правка. Редакторы XML безусловно рулят. Но это похоже на решение проблемы, которую можно было и не создавать.

Руками правится весьма нормально, а если данных много - то текстовый редактор всеравно в пролете, use xslt.

>Если тебе требуется интероперабельность с говнософтом, понимающим только XML, то тебе нужен XML. В ЛЮБОМ другом случае тебе не нужен XML, потому как есть множество гораздо более умных решений.

сказал - как отрезал :)

надеюсь, "интероперабельность с говнософтом" мне не понадобится и впредь.

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

ps: вот ведь как бывает, анонимус - а вещи говорит - поумнее некоторых зареганых.

>а кто-то говорит, что любых?

Говорят! В том-то и дело, что говорят, да не просто говорят, а прямо-таки вживляют непосредственно в моск! (это наверное, такая особая приправа к пище гигантского кальмара...)

>Говорят! В том-то и дело, что говорят, да не просто говорят, а прямо-таки вживляют непосредственно в моск! (это наверное, такая особая приправа к пище гигантского кальмара...)

где?

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

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

> сказал - как отрезал :)

Ага, а то, что пузыри пошли - не парит.

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

Слюшай, тора гой, я с деревьями всех форм и размеров всю жизнь работаю, а до сих пор такой необходимости не было, даже при отладке протоколов сериализации (синхронизация иерархических БД). Что же за rocket science ты занимаешься, что тебе нужно закрывающие теги видеть?

> Потому как иногда надо видеть где закрывается элемент.

А отступы тебя не устраивают?

Да что-же вы так привязались к синтаксису. Избыточен - так на то zip есть, iirc его основные парсеры нормально понимают. Сравни, например, odt(зипованный xml + картинки и т.д.) и зипованный doc(сгенеренный из того-же odt) разницы - несколько процентов.

Публика скандирует: "wbxml! wbxml!"

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

И это - простая весчь? Люди 40 лет это не могут сделать. Самое простое - бери в руки СУБД и пиши ограничения целостности. Это - поможет. А то твои люди понаудаляют все, до чего дотянутся

>Сравни:

> <arith oper="+"><arg><var>x</var></arg><arg><var>y</var></arg></arith>

> и та же хрень в SXML:

> (arith (@ (oper "+")) (arg (var x)) (arg (var y)))

адназначна, второй вариант - более читабельный.

Спасибо публике, буду знать такой вариант. =)

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

Через SOAP ты пакеты тоже будешь поверх zip гонять, да?

ЗЫ: спецификация SOAP включает в себя SXML как один из носителей протокола.

Afaik http позволяет сжимать трафик gzip-ом.

>И это - простая весчь?

нет? а что это меняет? куда деваться-то? :)

>Самое простое - бери в руки СУБД

видимо - придется. Недостаток этого решения, имхо - нетривиальная реализация поддержки. Собственно. хотелось бы оптимизировать именно этот момент - отсюда и интерес, в частности, к xml (но, сдется мне - в нем кастылищще на кастыле сидит, и подпорками погоняет...)

> и пиши ограничения целостности.

ну, и писать предполагалось не непосредственно sql, а спеку, по которой бы уже и sql генерился, и [пых, к примеру] какой-нить... ну, и сам механизм обеспечения целостности - реализовать, в том числе, и вне СУБД. (по ряду причин).

Ага, как же, посжимаешь пакеты по меньше килобайта каждый.

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

Можно пример более быстрого plain-text решения с возможностью хранения древовидных категоризированных данных?

Ну не сжимай, я не заставляю. =)

Если данные меньше одного ip пакета то какая вообще разница будет там 100 байт или 1000, и разговор об избыточности так же бессмысленен. В обоих случаях один пакет по сети пойдет.

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

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

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

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

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

>А отступы тебя не устраивают?

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

PS Чует моя упячка, что grinn (*) (29.06.2007 11:30:35) двигала простая мысль: зажечь флейм на ЛОРе. И это ему удалось