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

>>Между кем и кем обмен данными? Между програмами? То есть XML людям показывать ни в коем разе нельзя - скрывать надо.

>Согласен, что рядовому пользователю ХМЛ (как и вообще плэйн-текст) не упёрся. Но всё-таки если рассматривать ситуацию с конфигом в ХМЛ-е - не всё так страшно. Видел много конфигов и все читабельны (покрайне мере с тз программиста).

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

> 1. а кто-то предлагал tcp/ip на зумль перевести?

Нет, кто-то говорил, что бинарность --- зло.

> 2. и что будет с tcp/ip если я немного расширю формат пакета? :)

Ничего страшного. Это стандартная практика. Пакеты TCP, знаешь ли, это тоже расширенные пакеты IP.

>Поэтому ничего удивительного, что IMы ваяют одни недоучки, которым просто делать нефиг.

ууу....как всё запущено...без санитаров не обойтись

> Давай опиши мне используемое ПО и алгоритмы для обоих сервисов. Допустим ЯП - питон.

Забей. я тут про JS спросил и то тишина в ответ...

>Мдя... ответа так и не услышал... пойду дальше быдлокодерить с использованием быдлотехнологий вместо труъ, читай абстрактных коней в вакууме...

На, смотри http://www.stylusstudio.com/videos/convert-to-xml1/convert-to-xml1.html http://www.stylusstudio.com/csv_to_xml.html http://www.stylusstudio.com/text_file_to_xml.html

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

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

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

я бы деньги на этот плавный переход не поставил - жалко ...

>> если выразить XML через SExp вот это будет просто жутко избыточным
> Неправда. См. http://www.cliki.net/HTML-from-sexpr
>> парсеры XML очень просты - вплоть до пары сотен комманд ассемблера в то время как SExp - потребует наличие интерпретатора
> Если парсить так же, как эта пара сотен команд, то парсер SExp'ов будет не длиннее. Сами по себе SExp'ы не подразумевают наличия интерпретатора, но позволяют при необходимости легко интегрироваться с мощнейшим на сегодня языком.

если SExp == SXML - то уже говорилось
что SXML == XML copyright anonymous


>> XML же также потребует наличие интерпретатора но только написанного на языке проекта и который будет интегрирован в проект
>... и будет тормознее, глючнее, намного беднее возможностями, чем LISP, язык на базе XML будет хуже интегрирован в проект, чем SExp'ы в LISP. В общем, десятое правило Гринспуна во всей красе. Да и LISP --- не только интерпретатор, но и компилятор.
>> т.е. -у XML
с масштабируемостью всё очень плохо.

мы по разному понимаем масштабируемость

ключевое слово - в LISP
а ассемблер я не зря привел - была такая задача
наполовину ассеблерный код обращался к web servisу
Вы считаете что все языки должны быть заменены лиспом ?
все ? ну если вы девушка, ладно, пусть будет так :)))

>> XML парсер легко пишется и на ассемблере
> Этот пасер также будет уметь валидацию по DTD, XML Schema, Namespaces, преобразования XSLT и пр. И всё это в 200 строк на асме! Сказочник. Скорее, тебе придется ходить каждый день 5 км в гору пешком, как Санычу :)

нет, этот парсер не делает валидацию по DTD, XML Schema, Namespaces, преобразования XSLT и пр.
он просто вытаскивает данные из XML - вполне достаточно :)

>Мдя... ответа так и не услышал... пойду дальше быдлокодерить с использованием быдлотехнологий вместо труъ, читай абстрактных коней в вакууме...

На, смотри http://www.stylusstudio.com/videos/convert-to-xml1/convert-to-xml1.html http://www.stylusstudio.com/csv_to_xml.html http://www.stylusstudio.com/text_file_to_xml.html

>йопт, а лисп, оказывается может обработать любые данные сам по себе? вот этого не знал. Думал, придется логику писать и всё такое.

Он не о том. Он о единости представлений данных и программы и в конфиге скажем на лиспе можно написать что-то типа (max-size (* 1024 10)). В любых других хмлях обломс выйдет. Я не против XMLя с ним все хорошо - но последнее время заметил что чем более сложная структура конфига - тем мне проще разобрать его с помощью ANTLR (убирая XML нафик) чем бегать по любым представлениям а-ля абстрактный дом или SAX-парсинга. Просто сама модель обработки xml-конфига не являющаяся трансформацией выглядит так что хочется блевать (если конечно это не тривиальный дай-мне-что-у-тебя там(xpath). А если нужна трасформация - то да XML подходит нормально.

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

Основной смысл ХМЛ - унификация. Я бы даже сказал УНИФИКАЦИЯ. Не надо каждый раз свой парсер делать, а потом его продвигать по всем софтинам с которыми ты работаешь. Я могу допустить, что есть таки задачи, в которых использование XML больше времени возьмёт, чем парсинг пары строк из конфига с помощью readline-а.

НО - как только работать с этими конфигами сторонним софтом - вуаля. Никакой автоматизации (в силу того, что сторонняя софтина о твоём мега-велосипедном формате знать не знает). После этого ты начинаешь делать описание своего формата, указывать версию формата, используемую схему документа и тд и тп... Вобщем начинаешь повторять весь путь ХМЛ-я сам. Мега-контрпродуктивно.

Внимание вопрос: нахрена человеку лишная прослойка из лиспа?

> Основной смысл ХМЛ - унификация. Я бы даже сказал УНИФИКАЦИЯ.

Данные таки первичны. Не унифицирует XML данные. Каждая программа представляет данные по своему. То есть конечно в идеале звучит так: я научился парсить свои данные - теперь все могут это сделать. Но на практике это сделать может только твоя прорамма. То есть возникает жёсткая связка прорамма-данные. То есть как ты их представляешь всё равно - унификация XML ничего не даёт.

docbook как идея был неплох. Но инструментов для работы с ним нет и не предвидится. Тот же diff, те же стандартные текстовые юниксовые утилиты вынужденно выкидываются. SVG - вот как пример положтелен, но его пропихивают куча кого. В этом отношении tcp/ip как здесь указывали куда более распространён. Это не показатель качества технологии и её унификации.

> А для парсинга своих ini-подобный конфигов ты наверно ничего не пишешь, да?

Для парсинга простейших, и в то же время мощнейших конфигов на LISP'е, я ничего не пишу окромя (load "config.lisp"). Потому что, на SExpr'ах есть мощнейший язык --- LISP. А на XML'е нет ничего, абсолютно всё, до последней запятой --- врукопашную.

> Даже при обыкновенных плэйн-текстовых конфигах таким никогда не занимался.

Представь, что у тебя есть конфиг с хреновой тучей взаимосвязанных числовых параметров. Есть потребность позволить пользователю вычислять одни параметры через другие. Сразу возникает потребность в парсинге выражений и пр. А подстановки? Если, например, в конфиге куча путей, и нужно позволить пользователю задавать некие общие части, например, префиксы и потом подставлять? Это всё уже есть в XML/ini/ХЗчто?

> Очень сложно наверно написать пару классов с парсером конфигов, да?

Очень сложно эту х-ню потом переделывать под новые условия.

> попробуй потом свой конфиг выпарси из чего-нибудь быдлокодерского (джавы, С, бэйсика...)

А нахрен они мне упали? У меня есть LISP :)

Если мне так уж понадобится возможность парсить SExpr в Java/C/BASIC/whatever, то я ограничу язык конфига, что его легко можно будет парсить на любом языке.

> Меня вообще поражает как __лисп__ подпихивают вместо ХМЛ! Вы ребята совсем идиоты?

Что, неправильно подпихиваем? Расскажи как лучше, спасибо скажем :)

> Вы вместо SQL-я тоже будете свой лисп пропихивать?

Ты еще скажи, что SQL нельзя выразить в синтаксисе SExpr :) Можно, но SQL парсится значительно мЕньшим числом программ, у них уже есть парсеры и слабо кого волнует, сколько ребята геморроились. Генерить же SQL можно на чем угодно и как угодно.

>XML это просто очередная попытка своять ответ на все вопросы - до сих пор панацею нигде получить не получалось, как, собственно говоря, и вечный двигатель.

>Если человек думает иначе это не значит что он идиот. Вполне может оказаться, что идиот это ты.

Ф точку. Этот ответ не предполагал быть вечным двигателем - а вполне себе растет и ширится со своей нишей которая перешла уже давно в мейнстрим. Точно так же можно прыгать по поводу жабобыдлокодеров и убогости жава как VM как языка как [нужное подставить], но факт остается фактом - это industrial ready mainstream который решает свои задачи весьма успешно. может не супероптимально - но достаточно успешно. И можно этим пользоваться. А можно дальше всю жизнь мерятся, гнать и приводить контрпримеры, где его юзать не надо/не выгодно/не эффективно вместо того чтобы юзать его там, где это надо/выгодно/эффективно.Это как с пресловутым стаканом который наполовину...

>Этот пасер также будет уметь валидацию по DTD, XML Schema, Namespaces, преобразования XSLT и пр

А S-Expr это все будет уметь?

>>Это проблема не БД, а иерархических и рекурсивных структур.

>Ну извини. Подобные существуют вне зависимости от твоего мнения о них.

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

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

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

> как в мою java программу встроить лисп интерпретатор желательно соответствующий какому нибудь стандарту

http://www.norvig.com/jscheme.html http://www.gnu.org/software/kawa/

> кроме java у меня есть c#, c++, paskal, ocaml, haskel :))) .... ужос

Есть еще guile и много других всяких, которые ориентированы на встраивание. Большинство соответствуют R4RS, самые передовые уже R5RS, наверное.

> и схему работы такой связки покажи пожалуста - интересно

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

по большому счету
мне лично xml удобен так как есть стандартные
сериализаторы/десериализаторы нативных структур в xml и обратно
сериализованный текст можно и ручками подправить ...

объем работ 5 строк кода ...
так что - совершенно не понимаю тех кто тут копья ломает :)))

>Данные таки первичны. Не унифицирует XML данные. Каждая программа представляет данные по своему. То есть конечно в идеале звучит так: я научился парсить свои данные - теперь все могут это сделать. Но на практике это сделать может только твоя прорамма. То есть возникает жёсткая связка прорамма-данные. То есть как ты их представляешь всё равно - унификация XML ничего не даёт.

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

>docbook как идея был неплох. Но инструментов для работы с ним нет и не предвидится. Тот же diff, те же стандартные текстовые юниксовые утилиты вынужденно выкидываются.

Каких конкретно инструментов? При чём тут дифф? Если я дифф натравлю на два аналогичных сендмейловских конфига, написанных двумя различными людьми - он мне что-то вменяемое выдаст?

>В этом отношении tcp/ip как здесь указывали куда более распространён. Это не показатель качества технологии и её унификации.

Гик же спрашивал - причём тут tcp/ip? Это же низкоуровневое железное ограничение, не надо мух и котлеты пихать в одну кучу.

>НО - как только работать с этими конфигами сторонним софтом - вуаля. Никакой автоматизации (в силу того, что сторонняя софтина о твоём мега-велосипедном формате знать не знает). После этого ты начинаешь делать описание своего формата, указывать версию формата, используемую схему документа и тд и тп... Вобщем начинаешь повторять весь путь ХМЛ-я сам. Мега-контрпродуктивно.

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

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

Потому что иначе нужно писать свой парсер. Обычно для XML Он существует. XML-config предоставляется визуально значительно более удобным и структурированным чем скажем ini-like (сравни например log4j конфиг plain и XML-ный: XML-ный очевидет - плайновый представялет собой мутный набор правил и почти спецязык). Что-то более сложное требует более высокого уровня программиста и сложностей в реализации.

Даже отвечать влом, идите лесом.

>в конце концов получится не лучше чем XML

Параметры сравнения важны. Такая схема вероятно позволяет не влезая глубоко в приложение использовать _подходящий_ для данной задачи формат передачи. К примеру тому же xmpp-серверу не нужно парсить весь пакет - ему нужны только "адресаты". А зась - xml не пущает. И если для "im" это не сильно критично, то для какого-нибудь гипотетического сервер-серверого приложения со сложной структурой/большим обьёмом данных именно xml заставит не использовать xmpp по причине ограниченности cpu.

Универсальность и гибкость, говорите...

>> и схему работы такой связки покажи пожалуста - интересно

> Схема работы сильно зависит от задач. Если хост-приложение у тебя не имеет развитого API в подключенном интерпретаторе, то больших бонусов ты не получишь. А вот делать развитое API --- это и есть минус того решения, что само приложение написано не на LISP.

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

>>>Статьи, в которых описывается, как всё плохо, научного интереса не представляют. Интерес представляются статьи, где описывается, что именно нужно сделать, чтобы было лучше. Желательно, пошагово.

Первое и второе начало термодинамики научного интереса не представляют. Интерес представляет статьи, где пошагово описывается построение вечного двигателя первого и второго рода.

>человек должен легко редактировать текст в _текстовом_ редакторе с элементами MathML.

Приведите! Приведите меня к нему. Я хочу видеть этого человека! Не, действительно интересно посмотреть на чувака, которому будет удобно редактировать MathML в текстовом редакторе.

> Насколько я помню, геморроя с иерархическими базами данных огребли по самое не балуйся

Правильно. Однако только если рассматривать это как попытку построить _универсальную_ СУБД. Кто-то не помню в SU.SOFTW кажется высказал тезис, что если проект пишется более полугода то вполне разумно посмотреть в сторону разработки своего собственного специализированного хранилища данных. Никто не предлагает писать универсальную БД на иерархическом принципе. Однако это не значит что иерархии надо разварачивать в предка-потомка с целью развернуть это в псевдореляционную модель. Вполне может быть что геморой в обработке таких данных превышает сложности разработки спецхранилища.

>К примеру тому же xmpp-серверу не нужно парсить весь пакет - ему нужны только "адресаты". А зась - xml не пущает.

Мил человек, про SAX ничего не слышал?

>И если для "im" это не сильно критично, то для какого-нибудь гипотетического сервер-серверого приложения со сложной структурой/большим обьёмом данных именно xml заставит не использовать xmpp по причине ограниченности cpu.

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

>> в конце концов получится не лучше чем XML
> Параметры сравнения важны. ...

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

>То есть конечно в идеале звучит так: я научился парсить свои данные - теперь все могут это сделать. Но на практике это сделать может только твоя прорамма. То есть возникает жёсткая связка прорамма-данные. То есть как ты их представляешь всё равно - унификация XML ничего не даёт.

Какой-то бред. Веб-сервисы знаешь как работают? Прога твоего соседа отдает тебе <Person><Name>Bill</Name><Surname>Gates</Surname>& lt;/Person> и что? Если тебе нужны другие данные, ты попросишь его отдавать то, что тебе надо, а если ты запросил имя-фамилию, то ты легко сможешь выцепить их из этого <Person><Name>Bill</Name><Surname>Gates</Surname>& lt;/Person> формата

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

Должно быть наоборот. Мотивация писать приложение на LISP --- это всего лишь выбор мощнейшего из имеющихся инструментов. А конфиги, лишь бесплатное приложение. Emacs --- это пример, что пользователи могут захотеть сделать с твоим приложением то, о чем ты даже не задумывался. И они будут иметь возможность это сделать.

> На, смотри http://www.stylusstudio.com/videos/convert-to-xml1/convert-to-xml1.html

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

>xml в первую очередь предназначен для обмена данными

Данными обмениваются в первую очередь для того, чтобы их потом обработать. И выбирать формат сериализации для обмена без учёта требований обработки может быть несколько неразумно. Хотя конечно, при разработке для сферического кон^Hмпютера в жидком азоте, выполняющего бесконечный цикл за 1.57 с небольшим секунды, нормально.

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

+100! Та же фигня. Почему я должен парсить в голове то, что за меня должна делать машина.

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

>про скобочки смотри выше.

Поздравляю тебя geek, ты балбес. Причём полный. У ......... зула нет в этом никаких преимуществ. Например найди ошибку в

<sum> a b <sum> a c d <minus> a e </minus> f </sum>

Ну как? Получилось?

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

Во всех щелях лисп лучше xml'ля.

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

Конечно.

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

Лисп меня абсолютно устраивает. В отличие от пионерских поделок, удел которых --- простенький key=value

тоже всё пишем всё на лиспе (прогу-конфиги-документацию..) или ты с чем-то менее бородатым?

> <sum> a b <sum> a c d <minus> a e </minus> f </sum>

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

> Например найди ошибку в

><sum> a b <sum> a c d <minus> a e </minus> f </sum>

ты невнимательно читаешь. Если это будет в ячейке таблицы - то валидатор xml все равно ругнётся на то место, где ты закрываешь ячейку, не закрыв тег <sum>. А твой любимый лисп ругнется только на конец документа. Разницу чуешь?

>Данными обмениваются в первую очередь для того, чтобы их потом обработать. И выбирать формат сериализации для обмена без учёта требований обработки может быть несколько неразумно. Хотя конечно, при разработке для сферического кон^Hмпютера в жидком азоте, выполняющего бесконечный цикл за 1.57 с небольшим секунды, нормально.

Сферический конь в вакууме был взят как общий случай, возможно (повторяю - возможно) - в твоём случае накладные расходы для парсинга ХМЛ-я превышают плюсы унификации софта. Я всё чаще и чаще встречаюсь с тем, что плюсов на порядок больше.

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

А в лиспе это можно было сделать ещё тогда, когда создатели xml в пелёнки ссали.

>А в лиспе это можно было сделать ещё тогда, когда создатели xml в пелёнки ссали.

создатели xml как-то удачно зассали не только свои пелёнки, но и пелёнки всех окружающих. Куда ни плюнь - везде зумль. :)

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

Конфиги в xml --- зло для человека их правящего (ему за вредность должны молоко давать. И на пенсию в 35 лет, как у лётчиков).

А ежели их человек руками править не будут, то они и в бд себе спокойно полежат.

> Мотивация писать приложение на LISP --- это всего лишь выбор мощнейшего из имеющихся инструментов.

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

--- спорить на тему как быстро все делается на лиспе не будем !!!!!!!! :))))

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

емакс, для меня, пример странной операционной системы с вообще-то неплохим, хм, но странноватым текстовым редактором :)

> И они будут иметь возможность это сделать.

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

>А в лиспе это можно было сделать ещё тогда, когда создатели xml в пелёнки ссали.

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

>Конфиги в xml --- зло для человека их правящего (ему за вредность должны молоко давать. И на пенсию в 35 лет, как у лётчиков).

>А ежели их человек руками править не будут, то они и в бд себе спокойно полежат

до тебя все никак не дойдет мысль, что править конфиги руками - это не требование, а возможность? Как ты будешь править руками БД, если эта самая БД навернётся? Ы?

Сюда http://www.stylusstudio.com/text_file_to_xml.html смотрел?

>>>cоздатели xml как-то удачно зассали не только свои пелёнки, но и пелёнки всех окружающих. Куда ни плюнь - везде зумль. :)

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

>Как ты будешь править руками БД, если эта самая БД навернётся?

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

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

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

> Сюда http://www.stylusstudio.com/text_file_to_xml.html смотрел?

Ты издеваешься чтоли? Или чукча не читатель, чукча писатель? Разницу в этих схемах видишь?

server -> txt -> converter -> xml -> handler

server -> xml -> hanler

ы?