ой ли, XML намного сложнее и нечитаемее чем sexpr и yaml (и JSON ещё забыл), и ведь юзают, просто он распиаерен. Насчёт sexpr конечно не
уверен что он пойдёт в массы, потомучто его не пиарят, а вот YAML и JSON вполне.
Не любят за то, что как всегда самое кривое из решений стало самым популярным. Существует множество альтернатив на роль универсального структурного языка, и все они удобнее и качественнее XML. Но победил XML, потому что весь народ мира - тупой ацтой.
> Однако, не ошибусь, если скажу, что "порог вхождения" для этой штуки более высокий.
Порог вхождения более высокий?!? Да ну? Простые и понятные закрывающие скобки (а не повторение открывающей как в XML), нет никакого барахла вроде entities, вообще весь синтаксис очень тупой и легкозапоминающийся, запись получается заметно короче за счет меньшего количества синтаксического мусора.
Если тебе требуется интероперабельность с говнософтом, понимающим только 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) разницы - несколько процентов.
>мне требуется простая весЧь: найти или придумать механизм, обеспечиваюший: 1. разделения целого на составные части; 2.взаимодействие между отдельными частями 3. взаимодействие целого с отдельными частями. 4. простое изменение человеком отдельных частей 5.простое изменение человеком взаимосвязей между частями. 6. ну, и по мелочам всякие вкусности, типа "разделение контента и дизайна" :) и т.п.
И это - простая весчь? Люди 40 лет это не могут сделать. Самое простое - бери в руки СУБД и пиши ограничения целостности. Это - поможет. А то твои люди понаудаляют все, до чего дотянутся
видимо - придется. Недостаток этого решения, имхо - нетривиальная реализация поддержки. Собственно. хотелось бы оптимизировать именно этот момент - отсюда и интерес, в частности, к xml (но, сдется мне - в нем кастылищще на кастыле сидит, и подпорками погоняет...)
> и пиши ограничения целостности.
ну, и писать предполагалось не непосредственно sql, а спеку, по которой бы уже и sql генерился, и [пых, к примеру] какой-нить... ну, и сам механизм обеспечения целостности - реализовать, в том числе, и вне СУБД. (по ряду причин).
>Не любят за медленный парсинг по сравнению с почти любым другим решением и сложность в чтении и редактировании человеком по сравнению с простым текстом.
Можно пример более быстрого plain-text решения с возможностью хранения древовидных категоризированных данных?
Если данные меньше одного ip пакета то какая вообще разница будет там 100 байт или 1000, и разговор об избыточности так же бессмысленен. В обоих случаях один пакет по сети пойдет.
> > Можно пример более быстрого plain-text решения с возможностью хранения древовидных категоризированных данных?
> Зато примеров sql реализаций с B-tree индексированием -- ну просто хоть жопой жри...
В данном топике тебя ни кто не отговаривал от ректального поглащения бинарных деревьев. Нужно хранилище данных с нормальным индексированием - реляционные базы данных - твое все, и xml тут тебе пока врядли сильно поможет.