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

и глаза и парсер сломаешь как-раз на хмл переполнив и память и каналы перекачки информации которые очень дороги. А моё представление можно построчечно класть в базу, можно буферизовать и класть пакетно, прямо по мере поступления от дата-проваидера отфильтровать сбои, мусор (запайпив проблематичниые строки на-потом, не потеряв); гибкость - до бесконечности (срочно написав свой фильтр если надо). Дерево отрисовывать тоже можно инкрементально, так как каждая строка - независима.
Аналог RDB "select top 10 *" для хмл - в студию! ( | head -n 10)

Anode

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

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

Anode

>А моё представление можно построчечно класть в базу, можно буферизовать и класть пакетно, прямо по мере поступления от дата-проваидера отфильтровать сбои, мусор (запайпив проблематичниые строки на-потом, не потеряв);

во первых, ты изобрел велосипед. Такое уже - есть реляционные БД :) А во вторых - для того чтобы преобразовать такие данные ну хотя бы в html - придется писать конвертер! Осиливаешь мысль? А чтобы в pdf - ещё один конвертер. Если ты ССЗБ - то можешь этим заняться. Врачебная комиссия не возражает :)

>Как раз все глаза я сломал именно об хмл работая с ним много лет и ругаясь каждый раз

ты в ручную зумль на валидность проверял? =) ССЗБ

вообще
что за дурацкие обсуждения
какая разница как там в тексте все выглядит
главное DOM !
в лиспе DOM есть ? нету
в топку

> Аналог RDB "select top 10 *" для хмл - в студию! ( | head -n 10)

И как десять первых в структуре дерева вы получите? Десять первых уровней? Десять первых нод? У вас уже что-то с головой! :)

Как это нету? CL-DOM - Common LISP binding for DOM. The Document Object Model (DOM) is a platform and language neutral interface from the W3C

> Как это нету? CL-DOM - Common LISP binding for DOM. The Document Object Model (DOM) is a platform and language neutral interface from the W3C

ну тогда какая разница ?
пользуйтесь DOM интерфейсами и будет вам счастье :)))

!! вот видите, нормальное лисп сообщество
признает xml и во всю им пользуется
но только лисперы лора городят отсебятину :))))

Наверное, это некошерные лисперы! Те, которые пользуются конструкциями for и т.п. ;)

>Наверное, это некошерные лисперы! Те, которые пользуются конструкциями for и т.п. ;)

таки потрудитесь обьяснить, чем конструкция (loop for I from BEGIN to END do ...) некошерна? :))

Мой опыт с lisp & Co. довольно скромен, но то, что я успел увидеть - это предпочтение, отдаваемое рекурсии (перед итерацией). Если считать хорошим вкусом программирование в функциональном стиле (что как бы естественно для lisp).

ну это смотря какой лисп, если тот что пытаются преподавать в вузах, то да, там и должно быть "предпочтение, отдаваемое рекурсии", даже о итерациях и не заикаются, итеративные по сути алгоритмы тоже через рекурсию (scheme куку:). если же на практике, то как и в любом другом ЯП в Common Lisp используют конструкцию наиболее подходящую в данный момент.

>в ру/уа-нете катастрофически мало полезных сайтов адаптированных под КПК/WAP. Почему?

ну уж всяко не от игнорирования xml'я!)) имхо. Может, просто, нецелесообразно?? (ну, там "ВАП нынче дорог - ни один дурак не пойдет!")

>Статьи поместили в XML репозиторий. При отдаче контента пользователю он прогоняется через XSLT, в зависимости от user agent. Одна XSLT отдает полновесный HTML, вторая - КПК-вариант HTML, третья - WML.

ну, допустим... Может, это действительно дает какой-то выигрыш...

>Согласен. Далеко не все задачи хорошо сюда вписываются. Поэтому я очень аккуратно выбирал пример - лента новостей :)

то есть, для всех прочих задач все равно придется использовать JSP/ASP/PHP? Тогда зачем зоопарк технологий? Даешь унификацию! ;))) Да и с т.з. организации пр-ва - эффективней (имхо) иметь 3 незвисимых проекта, чем 1, решаюший 3 непересекаюшиеся (практически) задачи.

>Что касается контента, то если в модель (то есть схему XML) заложить возможности дифференциирования контента,

см. выше - про организацию пр-ва: сперва свалить все в одну кучу, а потом думать, как разгребать... Имхо - Лучше сразу не смешивать...

вобщем, пока приемуществ не вижу.

> что у вас все время парсинг на уме ?

Это не у нас, а у защитников XML. Основной аргумент --- куча якобы стандартных парсеров. В 200 строк на асме :)

> не задача это вовсе, забудте - нет такой проблемы

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

> я уже говорил - xml для меня важен как метод сериализации нативных структур

Сериализовать структуры можно по разному. Вот, например, PostScript --- де-факто, метод хранения картинок, т.е. внешнего вида страниц. В него можно сериализовать, а ведь PostScript --- это полноценный ЯП. Или модуль pickle в Python, замечательный сериализатор, формат его файла, фактически, программа на стековом языке, что позволяет без проблем сериализовать циклические структуры данных. Или вот, скажем, Package-файлы APT'а --- там вообще что-то типа header'ов из RFC822 --- замечательно читается глазами и обрабатывается стандартными shell/sed/awk.

> лисп в этой области никаким боком не упал

Дело не в том, что Lisp не упал, а в том, что XML не упал.

> вообще непонимаю зачем он в этом случае .....

Ну, если писать на Lisp, то SExpr'ы --- очень простой и мощный метод. Сериализация: (print object), чтение: (read). А так, в общем, было противопоставление перегруженного синтаксиса XML простым и ясным SExpr, если вам так уж это дерево нужно.

Я тут на досуге "пораскинул мозгом" и могу предложить ответить на простой вопрос: зачем нужны атрибуты в XML? Если есть отличные средства валидации и парсинга, то их ведь можно тривиально заменить вложенными тегами. А ведь атрибуты --- это дополнительная сущность, дополнительный код в парсерах и валидаторах, дополнительные правила escape'инга и т.п. Да, и еще --- нафига нужна CDATA, если и так можно всё заескейпить?

> это настолько частный случай

Это, на самом деле, очень распространенный случай. Не нужно это только в сверхузкоспециализированных программах, типа cat/find/grep.

> кстати у вас возникла проблема как раз с взрывным увеличением сложности когда семантика размазывается по разнородным языкам в проекте :)

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

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

> A1 B2 оттестированны, A2 A3 B1 B3 будут закрыты от пользователя

Ну и замечательно. закройте их API от доступа из конфига-программы. Тем не менее, пользователи смогут полноценно использовать K, A1 и B2.

> не всегда желательно открывать внутреннее апи на ранних этапах

Если фича доступна пользователю, то это уже не внутреннее API.

Существуют более эффективные констукции, но пока не включенные в стандарт.

Например, iterate

> вот видите, нормальное лисп сообщество признает xml и во всю им пользуется

Немного не так --- "нормальное лисп сообщество признает _существование_ xml и _неизбежность_ им пользоваться". Например, что делать, если по ТЗ какой-нибудь продукт должен уметь слать уведомления на Jabber? Или выдирать инфу из OpenOffice-документов?

2Sun-ch

угу, а кроме iterate, видел еще пару вариаций на тему loop, речь то шла о "кошерности" ;).

>пока не включенные в стандарт.

а че там ваще слышно-то о стандарте CL, когда он будет пересматриваться? :(

хотелось бы стандартных ниток, сокетов и еще много чего, а то каждая реализация имеет че-то свое, зоопарк :(

> Документация в свободном софте оставляет желать лучшего, причём сильно лучшего.

Имел возможность сравнить документацию в Linux с документацией в коммерческих AIX и UTS. Так вот, вторым еще как до луны раком до первой. Я сейчас так и пишу --- man в Linux и подправляю под отсутствующие в утилитах AIX особенности.

> Одно только отсутствие примеров использования ключей в куче манов/инфо чего стоит.

Мне уже все уши прожужжали в оффлайне этим отсутствием примеров. Я не понимаю, я как-то по-другому устроен? Мне всё понятно либо без примеров, либо на примере малюсеньких программулек с открытыми исходниками, которых полно в любом дистрибутиве. Гораздо чаще я сталкиваюсь с тем, что в коммерческих системах не найти описания того, что нужно. Даже гугль не всегда спасает, потому что коммерческий продукт, коммерческая документация и пр. Вот из недавних примеров: американский коллега, лет 10 пишущий под Unix ни разу в коммерческой документации не встретил описания конструкции "$@" для ksh и считал, что универсальный способ передать все параметры скрипта as is другой программе, это $*, а мне хватило man bash лет 10 назад и свериться с man ksh, что в ksh эта конструкция есть и означает тоже самое, когда понадобился ksh.

> Может, просто, нецелесообразно?

Может авторы так думают, но я как пользователь (опять же) страдаю :)

> Даешь унификацию! ;)))

Ммминуточку. Пааамеэдленнэй. Я запысую! (С) Шурик

Я что-то потерялся, так ты за унификацию или против?

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

Вроде в начале вопрос стоял, чем хорош XML для web'а. Я не сказал, что весь web нужно перевести на XML, а сначала сказал, что есть ниши, а потом предложил один из вариантов, где XML органично вписывается и где, как мне кажется, он облегчает создание и поддержку ресурса.

> эффективней (имхо) иметь 3 незвисимых проекта, чем 1, решаюший 3 непересекаюшиеся (практически) задачи.

Если они не пересекающиеся, то скорее всего да. Но в моем-то примере, данные одни и те же, просто требуют иного отображения (что скорее всего будет справедливо для любого сайта рассчитанного на различные клиентские платформы). То что не пересекаются view, еще не значит, что content manager, должен вносить информацию по одному разу для каждого user agent, форматировать его и пр?

Это же обычный MVC, модель абстагируется от view. Используем XML-приложение для представления публикаций. У нас нет [b][/b], зато есть теги, определяющие те или иные сущности (p, command, programlisting). Как эти сущности будут представлены во view, content manager'а не интересует. Его задача один раз подготовить content.

А уже дизайнер определяет какой должен быть presentation для каждого из user agents.

Теперь собственно почему XML. Уже есть более-менее распространенные стандарты для представления исходных документов (docbook, DITA), под которые есть удобные инструменты для создания content'а. Во вторых, есть достаточное количество инструментов для processing'а этих документов (качественный перевод в WML, HTML, XHTML, PDF, RTF делается гораздо проще чем из каких-нить бибикодов, или... вообще кошмар, HTML, который часто любят использовать как исходный формат для хранения информации в CMS). Еще один нюанс, может не так актуален для повседневных сайтов, больше для бизнеса, но организовать поддержку B2B обмена данными, между XML базированными системами гораздо проще.

дискусия ради дискуссии ...
оки

>> что у вас все время парсинг на уме ?
> Это не у нас, а у защитников XML. Основной аргумент --- куча якобы стандартных парсеров. В 200 строк на асме :)

суть - приведи пример парсера с структур в лисп ...
и обратно

я приводил пример парсера для того что-бы показать что парсинг не проблема
не передергивайте - это лисперы начали жаловаться на сложность парсинга xml

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

парсинг лиспа жрет эквивалентное количество времени и памяти

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

и ? говорим ради говорения ? типа последнее слово всегда за мной ?

>> лисп в этой области никаким боком не упал
> Дело не в том, что Lisp не упал, а в том, что XML не упал.

для Xml сериализаторы есть, для лиспа - вы еще не показали
так что лисп в отстающих

>> вообще непонимаю зачем он в этом случае .....
> Ну, если писать на Lisp, то SExpr'ы --- очень простой и мощный метод.

Ну, если писать с использованием Xml , то Xml сериализация --- очень простой и мощный метод.
вы просто болтаете ....

>> это настолько частный случай
> Это, на самом деле, очень распространенный случай. Не нужно это только в сверхузкоспециализированных программах, типа cat/find/grep.

хотя-бы процент программ которые работают с текстом и которые не работают с текстом
приведите пожалуста .... у меня на машине 30 % 70 ~ ... болтаете однако ....

> Проблемы были не в семантике, а чисто в синтаксисе --- Python
оптя, выясняем в конце концов что вы просто так с дуру наехали на Xml ...

>> A1 B2 оттестированны, A2 A3 B1 B3 будут закрыты от пользователя
> Ну и замечательно. закройте их API от доступа из конфига-программы. Тем не менее, пользователи смогут полноценно использовать K, A1 и B2.

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

>> не всегда желательно открывать внутреннее апи на ранних этапах
> Если фича доступна пользователю, то это уже не внутреннее API.

исключительно для Вас:
не всегда желательно открывать внутреннее апи, которое внешнее, на ранних этапах

>для Xml сериализаторы есть, для лиспа - вы еще не показали так что лисп в отстающих

http://common-lisp.net/project/cl-prevalence/

Работает как с XML protocol (через простой парсер S-XML), так и с s-expressions.

>Может авторы так думают, но я как пользователь (опять же) страдаю :)

Может тебе профинансировать разработку?;)

>Я что-то потерялся, так ты за унификацию или против?

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

>Если они не пересекающиеся, то скорее всего да. Но в моем-то примере, данные одни и те же, просто требуют иного отображения (

гмм... попробуем еще раз.. цитирую:

>Поэтому я очень аккуратно выбирал пример - лента новостей :)

получается: либо сайты состоят _только_ из "ленты новостей",)

>что скорее всего будет справедливо для любого сайта рассчитанного на различные клиентские платформы)

либо мы подгоняем задачу под решение. чтож, согласен - это тоже вариант, не редкий совсем. Однако, в этом случае пресловутое "юзабилити" лучше вообще не вспоминать..)) (помнишь? только черный цвет!)

>Это же обычный MVC, модель абстагируется от view.

Я бы мог привести пример, но пока не буду...))

>Теперь собственно почему XML. Уже есть более-менее распространенные стандарты

ага! а вот это уже больше похоже на правду!

но - только похоже...( основной объем информации передается "в ворде" ("в екселе") :/

ладно, тенденция мне ясна. спасибо.

> это - инструмент. Теперь понял о чем ты. В приницпе, согласен.

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

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

Разумеется, то есть вещи которые не стоит делать через... XML. Например, еще одна составляющая порталов - форум. Тут проще поверх общей базы сообщений и движка, написать три отдельных view слоя, на на каком-то средстве общего назначения, а не тулить туда XML.

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

>> Одно только отсутствие примеров использования ключей в куче манов/инфо чего стоит.

>Мне уже все уши прожужжали в оффлайне этим отсутствием примеров. Я не понимаю, я как-то по-другому устроен?

Сравнение шло не с никсами, а "сами понимаете с чем". Это просто другая культура - и им без XML не прожить. Они в этом себя уже убедили. :-?

>> для Xml сериализаторы есть, для лиспа - вы еще не показали так что лисп в отстающих

> http://common-lisp.net/project/cl-prevalence/
> Работает как с XML protocol (через простой парсер S-XML), так и с s-expressions.

CL-PREVALENCE is an implementation of Object Prevalence for Common Lisp

лисп нужен только для того что-бы было больше лиспа :)))))))))))

>во первых, ты изобрел велосипед. Такое уже - есть реляционные БД

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

Насчёт дерева - чрезвычайно легко, так как мы знаем всех детей родителя, дерево-же считывалось из корня - можно элементарно отсеить любое количество детей грепом (они идут потом). Главное - строка компактна и есть минимальная единица которая должна быть в памяти (потом можно побить - если большая). У хмл - генетические недостатки для больших массивов (да и для малых - всего этого рахода ЦПУ можно избежать).

Ещё подумайте что делают внутри РДБ, подумайте как работают сед (и работает очень быстро и надёжно), греп или напишите _масштабируемое_ пересечение множеств сами или почитайте Рейзера - врубается мужик в проблему (можно взять хфс или жфс - если нет доверия к рейзерфс или БДБ и подобных - для Б-трее).

Больше не обещаю отвечать - извините - нет времени.

Anode

такое ощущение
что все кто против Xml
претерпели такую пертурбацию:

были ярыми поклонниками -> пихали во все щели -> обломались -> стали ярыми противниками

а те кто за
претерпели такую пертурбацию:

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

ну так - сами себе злые буратины

> дискусия ради дискуссии ...

Ok. Разберем области применения и альтернативы. Однако, еще раз напомню, что не Lisp вместо XML и не SExpr вместо XML, а "XML не нужен, потому что универсально плох везде". Для танкистов: на Lisp свет клином не сошелся!

1. Конфиги. Простейшие парсеры "XML" незначительно отличаются от простейших парсеров SExpr. Валидирующие парсеры XML --- это песня. Возьмем одну из первых ссылок, выдаваемых гуглем на "validating xml parser library", получим http://xml.apache.org/xerces-c/ --- размер жатых исходников ~10M. Вы скажете, что это очень простой парсер, который можно за полчаса на коленке сваять? При этом, этот сраный парсер не умеет ничего, кроме _тупого_ парсинга. Для сравнения, guile занимает ~3M, при этом я получаю полноценный язык и приличную библиотеку. Есть и гораздо более миниатюрные реализации.

Еще одна альтернатива XML --- ini или key=value. Гораздо более читабелен и удобен для простых небольших конфигов. http://www.codeproject.com/useritems/ini_file_parser_spirit.asp --- парсер для C++ в 7kB, сравни с 10M. http://docs.python.org/lib/module-ConfigParser.html --- модуль Python, входит в стандартную поставку.

Зачем может понадобиться XML в конфигах? Якобы для унификации, и облегчения валидации, но... Как уже говорилось, самую важную часть валидации --- валидацию собственно данных унифицированно сделать средствами XML все равно нельзя. Унификация же штука хорошая, но не такой ценой. Представь конфиг fetchmail или procmail в XML.

2. Сериализация. Ну, я уже приводил примеры сериализации в PostScript, pickle или key=value. Ни в одном из этих случаев XML не будет лучше. Если вам нужна быстрая сериализация, то накладные расходы на парсинг --- ненужный оверхед, лучше бинарный формат. Если вам нужна человеко-читаемая и -исправляемая сериализация, то теги --- ненужный оверхед, тут приводилось уже несколько гораздо более читаемых вариантов сериализации в текст.

Опять таки, унификация. А нафига? Кому нужен XML вашей программы без знания семантики? Ну, например, что полезного можно сделать с документами OpenOffice без знания семантики элементов? Выдрать текст для полнотекстового индекса? Так это можно сделать с любым text-based форматом.

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

> 1. Конфиги. Простейшие парсеры "XML" незначительно отличаются от простейших парсеров SExpr.

Как вы сделаете конфиг не в XML, чтобы он поддерживал сложные структуры, наследование, дополнительные атрибуты (для ограничений) и поддерживался стандартными средствами KDE/Gnome. Да, при этом ими можно было централизованно управлять.

> 2. Сериализация. Ну, я уже приводил примеры сериализации в PostScript, pickle или key=value.

Как насчёт гибкости и доступных стандартных средств у любого получателя. Подумайте, почему для веб-сервисов/RSS/Jabber приняли именно XML.

> Опять таки, унификация. А нафига? Кому нужен XML вашей программы без знания семантики?

SOAP позволяет средствами XML дать исчерпывающую информацию о семантике. И не нужно городить специализированный парсер для каждой конкретной ситуации.

Да, ещё!

Кто-нибудь из противников XML ответит мне наконец-то, как можно удобно описывать интерфейсные формы без XML? :)

> Обмен данными. Унификация в данном случае --- опять-таки фикция. Никому не нужна эта унификация формата-обертки без знания семантики.

Я уже писал об этом, и пример приводил.

Высказывание справедливо, когда все смогли договорится об одном формате, но времена IBM PC и CGA мониторов давно прошли. Поэтому приходится работать с различными представлениями, казалось бы, одних и тех же данных.

В данном случае применение XML в связке с XSLT дает выигрыш во времени интеграции различных систем.

Пример: для документации одна организация использует - docbook, вторая - DITA. Им необходимо организовать обмен документами.

В мире бинарных форматов: одна организация использует .doc, другая .tex. И им тоже необходимо организовать обмен документами.

Оцени стоимость решения интеграции ИС двух организаций в первом и во втором случае. Включая и ширину канала, и затраты на парсинг... Если не впечатлит, добавь еще по одной организации: в первый список с OpenDocument, во второй - с .RTF.

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

Так что, поменьше категоричности в высказываниях, и все наладится :)

З.Ы. Что касается затрат на parsing и ширину канала. То приведу другой пример. Крупные организации (банки, государственные органы, страховые компании и пр.) одной консервативной и бюрократической страны уже присматриваются к возможности заменить систему архивирования документов. Сейчас это выглядит так: все документы в TIFF формате запиминаются в хранилище, независимо от того был он сосканирован с бумаги, или просто .doc перегнали напрямую в TIFF. Хотят перейти (хотя бы там где это возможно) к XML, который потом при доступе к архиву на лету можно через XSL-FO перегнать в PDF. Учитывая, что пиковая нагрузка на систему около 100000 входящих документов формата A4 в день, и почти все они должны быть заархивированы, то экономия на хранилищах получается немаленькая.

>Как вы сделаете конфиг не в XML

napishite prostoye preobrazovaniye-functsiyu XML->dot-delimited-flat-file i vsio o chom vi tut govorite - budet spravedlivo i ne dlya xml.
No - bolee compaktno, chitayemo i obrabativayemo by Unix-tools.
Kstati, config doljen bit' prost i ne nado nasledovaniye vvodit' v config (nu davayte code uj togda pisat' i interpretirovat' - vmesto configa)

>почему для веб-сервисов/RSS/Jabber приняли именно XML

moda, poddalis' massovomu odurmanivaniyu, nedalnovidnost', otsutstviye opita, job-security neznaniye MIME, itd.

>И не нужно городить специализированный парсер для каждой конкретной ситуации.

Ne nujno odin i tot-je parser (chto spravedlivo i dlya frameworks) tolkat' vo vse projeckti, potomu chto kajdiy project doljen bit' optimizirovan po-svoyemu. xml - odinakovo razoptimizirovan i tormoznoy - dlya vseh. Stroki - i bolee universalni i effektivni.

vi (i mi) bez raboti ne ostanemsya v takom sluchaye.
Let cherez 10 ili menshe - kto-to budet vijigat' XML ottuda napalmom (toje vobschem-to budet rabota)

>Кто-нибудь из противников XML ответит мне наконец-то, как можно удобно описывать интерфейсные формы без XML? :)

Я не противник XML, но все же... Имеются в виду интерфейсные формы GUI? Если да, то сейчас будет смешно. S-expressions! :)

Poslednee:
XML ub'yot vindu i (ego otsutstviye i upor na stroki) mog bi podnyat' linux i sdelat' bolee effektivnim s bolshimi massivami dannih kotoriye ne za horizontom, no ochen' jal' chto pioneri pitayutsya i v unix-like systemah navyazat' vindoviy podhod. IMHO.

izvinite za translit

Anode

>Кто-нибудь из противников XML ответит мне наконец-то, как можно удобно описывать интерфейсные формы без XML? :)

Сначала нужно показать, чем же XML так удобен для описания "интерфейсных форм". И заодно конкретное определение "интерфейсной формы" в студию.

>интерфейсные формы без XML
kstati XML v interface'nih formax poyavilsya ochen' nedavno a posledniye - suschestvuyut gorazdo dolshe ;)
Tcl/Tk _podhod_ (ne obyazatelno tikl' ispolzovat' hotya vot ego bi i nado bilo razvivat'), JavaScript (dom) i prochiye rulyat.

> Как вы сделаете конфиг не в XML, чтобы он поддерживал сложные структуры, наследование, дополнительные атрибуты (для ограничений)

Ты читать умеешь? Use Guile. Получишь гораздо больше, чем ты описал.

> поддерживался стандартными средствами KDE/Gnome.

Угу, офигенный показатель. Как ты будешь писать конфиги, позволяющие описать новое приложение с совершенно новой функциональностью, работающее в emacs и чтобы поддерживался стандартными средствами emacs. Хотя, чего это я? Такой конфиг я могу, ведь emacs может всё :) правда выглядеть будет ужасно. Ага! Вот, конфиг для sendmail. И тоже чтоб стандартными средствами.

> SOAP позволяет средствами XML дать исчерпывающую информацию о семантике.

Нихрена. SOAP позволяет тебе описать формат сообщения, но вот что означают конкретные значения конкретных свойств и какие на них накладываются взаимные ограничения? И вообще, что с этим сообщением делать? Например, если у тебя есть сервис, раздающий котировки по SOAP, то тебе нужна софтина, которая знает, что и как делать именно с котировками, а не с новостными сообщениями. Или уже написан универсальный потребитель информации по SOAP, ориентирующийся исключительно на "исчерпывающую информацию о семантике" в SOAP?

> как можно удобно описывать интерфейсные формы

А это что? Это типа того, что тут на картинке? http://docprof.kvazar-micro.com/system/reg_doc/ Ответ --- Tcl/Tk.

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

Что за данный случай? Документация? XML тут дает выигрыш просто потому, что он уже есть. Я этого не отрицаю. Но чисто технически, интерпретатор lisp'а даст тот же, если не бОльший, выигрыш. Кстати, один из популярных инструментов для конвертации docbook во что-либо с человеческим лицом --- DSSSL, который суть Scheme, а не XSLT.

> Пример: для документации одна организация использует - docbook, вторая - DITA. Им необходимо организовать обмен документами.

> В мире бинарных форматов: одна организация использует .doc, другая .tex. И им тоже необходимо организовать обмен документами.

Не очень корректное сравнение. При попытке интеграции .doc с docbook или DITA вы получите абсолютно те же грабли и XML вас не спасет. А docbook в .tex нормально конвертится. DSSSL'ем. Из .tex в docbook сложнее, потому что у .tex более низкий уровень. Если же взять какой-нибудь texinfo, то в docbook его при желании можно отконвертить. В html, по крайней мере, он конвертится --- пакет texi2html занимает ~1.5M на перле (видимо, вместе с документацией). Если очень захотеть, можно попробовать LaTeX в docbook отконвертить, но в общем случае не получится, потому что слишком разные принципы: LaTeX --- фактически ЯП, docbook --- очень ограниченный статический формат. С таким же успехом можно построить на XML язык с семантикой ЯП и поиметь грабли с преобразованием ЯЗЫК<->docbook.

Резюме --- основные проблемы не в разнице синтаксисов, а в разнице именно семантик, которые и в XML могут быть очень разные. Я тут глянул мельком на DITA и могу сказать, что понятия, которыми оперирует DITA не на 100% пересекаются с docbook, а значит можно поиметь проблемы с конвертацией docbook->DITA или наоборот.

> Унификация формата-обертки дает возможность использовать мощный инструмент - XSLT

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

>Покажите как Lisp справится с:

>3. Веб-сервисами

SOAP 1.1 API for Allegro Common Lisp: http://www.franz.com/support/documentation/6.2/doc/soap.htm#intro-1

http://www.windley.com/archives/2005/02/amazon_web_serv_2.shtml

Цитата с этой ссылки: "I've written programs that use XML in Java, Perl, Python, XSLT, and now Scheme. Scheme has been the easiest. I think the reason is that with s-expressions, XML is essentially a native data type in Scheme. That's an incredibly powerful idea. Your milage, of course, may vary. If Lisp isn't your thing, you'll have to wait for something else."

И вообще, как-то разговор некорректно идет. "XML vs LISP" --- это некорректно. XML --- всего-лишь Markup Language, поэтому корректно говорить "XML vs. S-expressions" и "XML+XSLT+.... vs LISP". Так в жизни получилось, что S-expressions являются моделью *данных и программ* в Лиспе. Так что у лиспера все это уже является родным.

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

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

> XML не нужен, потому что универсально плох везде

Lisp не нужен, потому что универсально плох везде

>Валидирующие парсеры XML --- это песня.
>Для сравнения, guile занимает ~3M,

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

>ще одна альтернатива XML --- ini или key=value. Гораздо более читабелен и удобен для простых небольших конфигов. http://www.codeproject.com/useritems/ini_file_parser_spirit.asp --- парсер для C++ в 7kB, сравни с 10M. http://docs.python.org/lib/module-ConfigParser.html --- модуль Python, входит в стандартную поставку.

да не гони, твою ....
оно валидирует ??
привести пример парсера xml на с++ меньше 7k ?
модули парсинга xml также входят в стандартную поставку python

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

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

> 2. Сериализация. Ну, я уже приводил примеры сериализации в PostScript, pickle или key=value. Ни в одном из этих случаев XML не будет лучше. Если вам нужна быстрая сериализация, то накладные расходы на парсинг --- ненужный оверхед, лучше бинарный формат. Если вам нужна человеко-читаемая и -исправляемая сериализация, то теги --- ненужный оверхед, тут приводилось уже несколько гораздо более читаемых вариантов сериализации в текст.

сколько повторят - xml сериализация уже есть
и она читаема, и оверхед приемлимый
и кода написано - 3 строчки - только 3 !!!
- зачем мне городить лишний огород предлагаемый вами ?

> Опять таки, унификация. А нафига? Кому нужен XML вашей программы без знания семантики? Ну, например, что полезного можно сделать с документами OpenOffice без знания семантики элементов? Выдрать текст для полнотекстового индекса? Так это можно сделать с любым text-based форматом.

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

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

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

> И вообще, как-то разговор некорректно идет. "XML vs LISP" --- это некорректно. XML --- всего-лишь Markup Language, поэтому корректно говорить "XML vs. S-expressions" и "XML+XSLT+.... vs LISP". Так в жизни получилось, что S-expressions являются моделью *данных и программ* в Лиспе. Так что у лиспера все это уже является родным.

и ? в лиспе уже научились отделять данные от их представления и преобразования ?

> Но чисто технически, интерпретатор lisp'а даст тот же, если не бОльший, выигрыш. Кстати, один из популярных инструментов для конвертации docbook во что-либо с человеческим лицом --- DSSSL

Да, я в курсе, но я говорю, не о переводе исходного формата, в формат с человеческим лицом. А о переходе между двумя исходными форматами.

> Не очень корректное сравнение. При попытке интеграции .doc с docbook или DITA вы получите абсолютно те же грабли и XML вас не спасет.

Согласен, но тем не менее шаги в эту сторону делаются. Пишется что-то вроде (за точность синтаксиса не ручаюсь):

var document = new ActiveXObject("Word.Document");

document.open("blah.doc");

document.save("blah.xml", FORMAT_XML);

И потом этот XML в DITA. И это будет быстрее (не пишу "гораздо быстрее" потому что формат там еще тот, а подписаться под OpenDocument мелкомягким масть не позволяет) в разработке, чем хоть на лиспе, хоть на чем угодно ты попытаешься разобрать бинарный формат Word'a.

Да, пока что, не все гладко, далеко не все инструменты поддерживают XML, но к этому по тихоньку идет. Идет колоссальная ломка, организациями преодолевается немыслимое споротивление рядовых сотрудников, ради банальной экономии средств. Я имел/имею возможность наблюдать перевод процесса подготовки документации на XML технологии в Adobe, Autodesk, General Motors и пр. (можно сказать в некоторых случаях имею к этому прямое отношение).

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

Пример. Документация готовится в TeX, переводится на другие языки в продукте A, который имеет конверторы из TeX в свой внутренний формат и назад. Тут на рынок выходит продукт B, который имеет существенные преимущества перед A, что уменьшит время перевода в 2-3 раза. Но он не поддерживает TeX. Тебе как автору, нет дела до проблем переводчиков, но организация деньги считает. Принимается решение переходить, надо писать конвертор из TeX в vendor-specific формат, сколько бы это не стоило, так как при уменьшении времени на перевод в два раза все равно окупится. Вопрос как раз в этой цене.

Приведу один пример из практики, есть один формат для localization tool. Писался конвертор для перевода в него из MS Word и DITA. Время разработки: соответственно полтора месяца (причем баги находим до сих пор, уже три месяца прошло) и три дня.

> основные проблемы не в разнице синтаксисов, а в разнице именно семантик

Да это как бы и не проблемы, это реальность. И на самом деле это не столь большая проблема. В случае если чего-то не хватает в DITA, я ее легко могу расширить. Я-то и docbook могу расширить :), но чтобы не терять совместимости с внешними инструментами можно использовать mapping (чем-то пожертвовать, например procedure/step будут мапиться на ol/li), хотя из нашего опыта чаще расширяют стандарты (потому DITA так резво и прижилась, что в ней расширение стандартизировано).

> что понятия, которыми оперирует DITA не на 100% пересекаются с docbook Я тебе больше скажу, понятия которыми оперируют authoring tools настолько отличаются от понятий translation tools, что DITA и docbook близнецы-браться ("Кто может отличить китайца от китайца?" (С) "Такси"). От этого трансформация XML с помощью XSLT не становится сложнее, чем бинарных форматов, с помощью чего-то еще.

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

Хмм, я не знаю, что ты понимаешь под сложной логикой преобразования. Естественно, XSLT не справится с не XML документом на входе, на нем сложно генерировать не XML/HTML вывод (хотя JS исходнички очень ничего получались :)), нам приходится использовать XSLT extensions (но это чаще performance issues), XPath выражения иногда поражают воображение (как оказалось, их тоже можно профилировать/оптимизировать по скорости работы). Но тем не менее я бы сказал, что простым случаем является любой когда входящий и исходящий форматы имеют DTD и специфицирована логика преобразования. Все.

Проблемы у нас были два раза (результаты 50/50):

- структуризация не структурированного документа. Просто XML, без DTD (дали 2 десятка файлов с примерами), попросили перевести в DITA. Намаялись (эвристическими методами полуструктура была выявлена, XPath выражения на два экрана в ширину и пр.), но результаты были признаны удовлетворительными.

- перевод HTML в DITA (HTML + tidy = XML + XSLT = DITA), результаты были признаны неудовлетворительными. Тут случай когда заказчик не смог объяснять логику преобразования (читай, описать подходящий mapping), то есть требований по сути не было. В таком случае, ИМХО что LISP, что XSLT - все до дверцы.

Больше статистики по "сложной логике преобразований" нет.

> napishite prostoye preobrazovaniye-functsiyu XML->dot-delimited-flat-file

А зачем мне городить огород и писать свой парсер? Мне что, время девать некуда?

> moda, poddalis' massovomu odurmanivaniyu, nedalnovidnost', otsutstviye opita, job-security neznaniye MIME, itd.

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

> Ne nujno odin i tot-je parser (chto spravedlivo i dlya frameworks) tolkat' vo vse projeckti, potomu chto kajdiy project doljen bit' optimizirovan po-svoyemu.

Наличие оверхеда при обработке XML с лихвой компенсируется гибкостью, переносимостью (см. выше) и скоростью разработки. Конечно, если у вас биллинговая система - то применение XML _внутри её_ - неправильно (хотя результат она может выдавать в XML). Но это - редкие исключения гомогенных приложений.

> Let cherez 10 ili menshe - kto-to budet vijigat' XML ottuda napalmom (toje vobschem-to budet rabota)

Скорее всего, вас на милю для написания современных приложений не допустят. Ни коммерческих, ни OpenSource. :)

> Имеются в виду интерфейсные формы GUI? Если да, то сейчас будет смешно. S-expressions! :)

Примеры можно? Десятка три приложений наберётся? :)

> Сначала нужно показать, чем же XML так удобен для описания "интерфейсных форм".

Гибкость и отсутствие проблем с версионностью. Плюс, как бонус, наличие готовых дизайнеров. К примеру, у меня в EAS формы описываются на диалекте XML. Зачем мне писать свой дизайнер, если я могу что использовать Qt designer или Glade и транслировать формы оттуда автоматом?

> И заодно конкретное определение "интерфейсной формы" в студию.

Описание виджетов, их свойств, способа расположения и реакций на события в рамках приложений GUI. Устроит?

> Tcl/Tk _podhod_ (ne obyazatelno tikl' ispolzovat' hotya vot ego bi i nado bilo razvivat'), JavaScript (dom) i prochiye rulyat.

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