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

> линейный рост сложности, желательно с небольшим коофициентом

Ну, в случае Lisp'а коэффициент равен 0 :) Самый сложный конфиг парсится так (уже неоднократно приводилось в данном топике): (load "config.lisp")

В случае же других языков, мерилом сложности является сложность API приложения, доступного программе-конфигу, работающей во встроенном интерпретаторе. Парсинг же простейших конфигов на SExpr'ах без сложной семантики не сложнее парсинга XML, но в этом случае вообще незачем городить эту городуху, легче использовать INI или что-то в этом роде.

> интеграция уже 2 чужеродных языков не сверхсложная задача, но и не сахар XML тут неплохое решение

В случае сложных XML-конфигов вы на базе XML строите собсвенный язык и сами пишете собственный интерпретатор этого языка.

На самом деле, я прошел через это. Как-то раз, мне пришлось делать приложение со сложными конфигами-шаблонами. Я по скудоумию выбрал C++/Python/XML. C++ для критичных к скорости участков, Python для логики и XML для шаблонов. Как я раскаивался потом, что не выбрал для всего один-единственный LISP! Причем, камнем преткновения была невозможность нормального использования нормального ЯП (Python, в данном случае) в языке, построенном на XML. А как выглядели эти конфиги! Жуть! В общем, "... и опыт, сын ошибок трудных ...".

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

> ТЕСТИРОВАНИЕ !!!

Хм... Мне тут смутно представляется порочность этого пути. Т.е., вы предлагаете пользователю чуть бОльшую функциональность на начальном этапе с плохо оттестированной основой и невозможность расширения им самим, вместо того, чтобы предложить хорошо оттестированную основу + широкие возможности расширения, но чуть меньшую функциональность из коробки. Если мне не изменяет память, практика показывает бОльшую жизнеспособность второго варианта. Не всегда возможность расширения давалась в виде мощного языка конфигов, чаще --- в виде возможности написания плагинов, но чем шире возможности расширения независимо от вендора приложения, тем выше популярность приложения. Даже если из коробки приложение проигрывает всем конкурентам, кто-то из продвинутых пользователей напишет к приложению дополнение, реализующее то, чего нет у самых продвинутых конкурентов.

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

> в вашей схеме, например guile + GoodLanguage в определенный момент может произойти взрывное увеличение сложности из-за размазанности сементики представления данных по разным частям программы

Семантика представления должна быть в guile. Хост-приложение предоставляет только некоторый API. В зависимости от уровня этого API и объема части приложения, реализованного в guile, приложение ближе к (1) или к (2).

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

Ну, в некотором роде, .procmailrc --- тоже программа, а уж .vimrc --- безусловно, хотя они и не Lisp. Это уже плавный переход к обсуждению концепции "конфиг==программа/приложение==интерпретатор".

>камнем преткновения была невозможность нормального использования нормального ЯП (Python, в данном случае) в языке, построенном на XML

ЯП построенный на XML...думаю тут всё проще - ты _не_ умеешь выбирать инструмент для решения задач. XML тут ни при чём. Ты сам себе злобный буратина...удачи в дальнейшем забивании гвоздей микроскопом :)

> Ты сам себе злобный буратина...

Я знаю. Но это было давно :) Нынче я исправляюсь и для использования XML должны быть ОЧЕНЬ веские основания, коих в свете существования Lisp, что-то не видать. Кстати, ЯП оно было не сразу, сначала это был просто шаблон, но потом требования резко изменились и пришлось сделать конфиг программой.

>Я знаю. Но это было давно :) Нынче я исправляюсь и для использования XML должны быть ОЧЕНЬ веские основания, коих в свете существования Lisp, что-то не видать

ты ударился в другую крайность, что тоже является признаком ССЗБ :)

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

полная смена ТЗ - достаточное основание для выкидывания уже сделанного и зачатия нового проекта :) То что ты попытался прикрутить к велосипеду квадратные колёса и куда-то ещё на этом уехать - тоже не говорит о профессионализме. Ах да...это было "давно" :)

ps: худею я с фанатствующих лисперов...гербалайф отдыхает

> полная смена ТЗ - достаточное основание для выкидывания уже сделанного и зачатия нового проекта

Как бы это сказать... В том проекте не было ТЗ как такового вообще :) И времени было в обрез, потому как до этого там какие-то хмыри больше года х** пинали. А смена требований возникла потому, что инфу нам выдавали порциями в месяц по ведру.

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

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

> худею я с фанатствующих лисперов...гербалайф отдыхает

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

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

лисп - одна из лучших вещей, которые я знаю. Но желание сделать конфиги и вообще всё на лиспе вызывает...недоумение. Это мягко говоря =)

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

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

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

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

=)

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

Ну вот, сразу "пропихнуть". И почему обязательно LISP? LISP - лишь пример ЯП, построенного на SExpr (на синтаксисе XML подобного по удобству нет), и отличный инструмент. Зачем использовать неудобные и, скорее всего, относительно недолговечные вещи только потому, что это модно?

Ты пытаешься меня убедить, что без XML сейчас шагу нельзя ступить? Так я и сам это вижу, но это не повод для меня выбирать XML для конфигов и для хранения данных. И в качестве формата обмена данными я предпочту не-XML всегда, когда это возможно, потому что кроме случаев общения с существующим софтом, использующим XML, я не вижу других надобностей в XML. В каждом конкретном случае plain text/ini/SExpr/binary удобнее, чем XML.

yeolahim писал .....
watashiwa_daredeska писал[а] .......

ну а теперь:

0 что у вас все время парсинг на уме ?
да не задача это вовсе, забудте - нет такой проблемы

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

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

хм
>> Ну, в случае Lisp'а коэффициент равен 0
коэффициент никогда не равен 0 нигде, иначе у вас сплошная нирвана,
и вирусорассадник - система сама по себе усложняется, а пользователь даже не знает
>> конфиг==программа/приложение==интерпретатор
это настолько частный случай
вот вам попался ('На самом деле, я прошел через это. Как-то раз, мне пришлось делать приложение со сложными конфигами-шаблонами.')
мне что то похожее попадалось, но правда меня не понесло в сторону усложнения xml,
только сериализованные структуры. да и язык был только один
кстати у вас возникла проблема как раз с взрывным увеличением сложности когда
семантика размазывается по разнородным языкам в проекте :)
лисп в этом случае возможно хорошее решение :)))
>> ТЕСТИРОВАНИЕ !!! и все что вы там написали
представте есть хорошо оттестированное ядро K и группы связанных фич [A1;A2;A3]
[B1;B2;B3] A1 B2 оттестированны, A2 A3 B1 B3 будут закрыты от пользователя
не всегда желательно открывать исходный код
не всегда желательно открывать внутреннее апи на ранних этапах
оно может быть в нестабильном состоянии - фича B3
>> Даже если из коробки приложение проигрывает всем конкурентам,
приложение может быть 'анонсированно' для этого не обязательно иметь много всего

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

Это не у нас, а у защитников 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.

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

>> что у вас все время парсинг на уме ?
> Это не у нас, а у защитников 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.

>> для 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

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

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

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! :)

>Кто-нибудь из противников 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 применим в относительно простых случаях, а для сложных будет геморрой не меньший, чем с остальными форматами.

> 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 - этого вполне достаточно что-бы манипулировать этим куском

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

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

> Но чисто технически, интерпретатор 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. :)

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

Типа, каждый емаксер, чтобы написать пару строчек текста, должен программировать на LISP? :) Позабавил. Увы, все остальные заняты более важными делами, чем программирование конфигов. :)

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

Emacs - это тот самый маргинальный текстовый редактор, занявший 4ое место в 2005 LinuxQuestions.org Members Choice Awards? :)

> Или уже написан универсальный потребитель информации по SOAP, ориентирующийся исключительно на "исчерпывающую информацию о семантике" в SOAP?

Microsoft Office? WSDL? :)

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

Мне жаль пользователей таких простецких интерфейсов. :)

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

> Мне жаль пользователей таких простецких интерфейсов. :)

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

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

Ага, чисто силой воображения. Тогда то же самое можно сделать и средствами CUI. :)

> она валидирует ?

Естественно.

> то есть можно точно сказать с помощью guile что то что написано - нееправильно ?

Можно, если напишешь правила, как и в DTD или XML Schema, но набор возможностей для опиания правил не идет ни в какое сравнение с XML Schema или, тем более, с убогим DTD.

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

При чем тут это? Если ты написал валидную программу, которая работает неправильно, то тебе поможет только отладчик :)

> оно валидирует ??

ini/key=value были приведены как альтернатива для относительно простых конфигов, требующих читабельности и возможности ручной правки, что не отменяет возможности лопатить их _стандартными_ утилитами Unix. И валидировать там нечего абсолютно. Если парсер встретит key без value, то, наверно, ругнется, а больше никакой валидации там не нужно, кроме валидации значений, которая привязана к семантике и DTD/Schema тут также бессильны. Нужна валидация --- guile или самописная.

> xml сериализация уже есть

Да, это плюс, я уже писал, что я с этим согласен, но это не отменяет технических недостатков XML. Кстати, PostScript и pickle тоже уже есть.

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

<office:document-content xmlns:office="http://openoffice.org/2000/office"; xmlns:style="http://openoffice.org/2000/style"; xmlns:text="http://openoffice .org/2000/text" xmlns:table="http://openoffice.org/2000/table"; xmlns:draw="http://openoffice.org/2000/drawing"; xmlns:fo="http: //www.w3.org/1999/XSL/Format"; xmlns:xlink="http://www.w3.org/1999/xlink"; xmlns:number="http://openoffice.org/2000/datastyle"; x mlns:svg="http://www.w3.org/2000/svg"; xmlns:chart="http://openoffice.org/2000/chart"; xmlns:dr3d="http://openoffice.org/2000/dr 3d" xmlns:math="http://www.w3.org/1998/Math/MathML"; xmlns:form="http://openoffice.org/2000/form"; xmlns:script="http://openoffi ce.org/2000/script" office:class="text" office:version="1.0"><office:script/><office:font-decls> ;<style:font-decl style:name="S tarSymbol" fo:font-family="StarSymbol" style:font-charset="x-symbol"/><style:font-decl style:name="Tahoma1" fo:font-family="Ta homa, Lucidasans, &apos;Lucida Sans&apos;, &apos;Arial Unicode MS&apos;"/>

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

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

(let ((subtree-we-need (with-open-file "my.document" (extract-subtree-by-condition condition (read))))) (do-whatever-we-want-with subtree-we-need))

> ваша великая лисп панацея сработает ?

Более чем.

> приведи мне пример динамически модифициремого бинарного формата ! с хорошей эффективностью и на ширину канала и на парсинг

zip.

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

Ну, лично я его разбирал на Python через COM API Word'а. Нормально, никаких лишних промежуточных сущностей типа XML мне не понадобилось.

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

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

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

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

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

Ну, например, мой гипотетический формат ориентирован на описание каких-либо объектов совершенно разных типов. В простейшем случае, пусть это будет из близкой вам области: таблицы, иллюстрации, текст и т.п. Мне их нужно, допустим, автоматически нумеровать (с учетом некоторой структуры, например, глав), призваивать символическое имя для ссылок и подставлять номера по именам. Можно заложить логику работы "хардкодно", а можно предоставить набор некоторых инструментов, которые делают не именно это, но позволяют легко описать то, что нам надо. Ну, типа TeX, только на XML. А вам потом придется реализовывать на XSLT логику вычисления <referenceNumber name="picture1" />.

> то есть требований по сути не было. В таком случае, ИМХО что LISP, что XSLT - все до дверцы.

Ну, не совсем. Это ровно тот же случай, который я приводил как пример своего провала с XML и Python --- у нас были примеры документов, накорябанных в Excel и Word без особых правил. Нужно было выковыривать из них инфу в терминах определенной предметной области. Просто в виду слабости возможностей XSLT вы даже не помыслили о более сложных решениях, например, эвристиках, основанных на некоторых элементах оформления, на содержании, которое можно оценивать по словарям в БД и пр. Это и есть, собственно, проблема преобразования из низкоуровневых форматов в высокоуровневые, например, texinfo->HTML легко, а наоборот --- запаришься, потому что данные о высокоуровневой структуре утеряны либо их и не было никогда.

> Типа, каждый емаксер, чтобы написать пару строчек текста, должен программировать на LISP? :) Позабавил. Увы, все остальные заняты более важными делами, чем программирование конфигов. :)

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

> Emacs - это тот самый маргинальный текстовый редактор, занявший 4ое место в 2005 LinuxQuestions.org Members Choice Awards? :)

В ход пошли аргументы про дерьмо и миллионы мух?

> Microsoft Office? WSDL? :)

Пример: я создаю сервис, который выдает через SOAP отчеты по параметрам некоторых объектов. Выборки позволяется делать по произвольным наборам параметров, произвольным наборам объектов и за произвольные промежутки времени.

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

> Мне жаль пользователей таких простецких интерфейсов. :)

Батенька, я не знаю что такое "интерфейсная форма", поэтому набрал в гугле, ткнул в одну из первых ссилок и получил ЭТО. Это то, что вы имели в виду? Покажите не простецкую, которую Tcl/Tk не осилит.

> Ну, лично я его разбирал на Python через COM API Word'а.

То есть, как минимум, тебе не пришлось самому парсить документ, что в купе с созданием объектной модели и сериализацией наиболее трудозатратно (о чем тут уже говорилось). Согласись, что Word API есть не всегда. Например, Corel Draw/Adobe Illustrator vs. SVG.

Ты работаешь сразу с объектной моделью. Теперь ближе к примеру, кторый я приводил, он как раз подходит.

> Я просто не в курсе, что там за формат был, в который вы конвертили.

Это был формат для localization tool. По сути это был не конвертор а фильтр. Нужно было вычленить из документа все текстовые сегменты, которые должны переводится.

На XSLT это было по сути вычленение текстовых узлов (на самом деле чуть сложнее, output тоже XML). В случае с Word'ом, необходимо было изучить объектную модель, чтобы вычленить все строковые значения.

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

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

> Это ровно тот же случай

Совсем не тот же. Я говорил о необходимости преобразования структуры, при отсутствии требований к логике этого преобразования.

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

Естественно, что из XSLT я в БД не полезу, хотя теоретически могу. Только вот кроме слабости возможностей XSLT, еще бывает "слабость возможностей бюджета". Предложение работать дальше было, и решение было, и estimate был... и ответ был, что за ненамного большие деньги (учитывая, что результат неосязаем) мы переведем весь имеющийся у нас content вручную.

Ради искусства можно было бы и помыслить, а когда денег хочется, то приходится взвешивать. Да, я циник. :)

Сорри, пропустил

> Ну, например, мой гипотетический формат ориентирован на описание каких-либо объектов совершенно разных типов. [и далее по тексту]

Я не увидел сложности в оргнизации ссылок и нумерации (xsl:number?), т.к. это есть то с чем приходится сталкиваться в документации каждый день.

Насчет hard coded алгоритмов. Я думаю, не секрет что на вход трансформации может поступать не один, а много документов (как и получаться на выходе).

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

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

Почитайте http://developer.kde.org/documentation/tutorials/kconfigxt/kconfigxt.html - там написано, насколько удобнее использовать в разработке XML, маппируемый как на логику программы, так и на построение интерфейса для настроек - программист избавлен от нудной ручной работы.

> Да, к Emacs можно писать очень навороченные конфиги, но не для того, чтобы написать пару строк текста, а для того, чтобы делать навороченные вещи

Увы, разработка навороченных вещей для текстового редактора не востребована. Проще писать отдельные специализированные приложения с общением между ними в XML, чем всё толкать в одну кучу. Один из принципов Unix-way. :)

> В ход пошли аргументы про дерьмо и миллионы мух?

Нет, просто констатация фактов. :)

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

Не знаю, я с MSOffice не работаю. Посмотрите примеры: http://spaces.msn.com/mkozloff/blog/cns!D1ED809F4FFA9136!231.entry

>> она валидирует ?
> Естественно.

даа ? какие мы - если лисп то он еще и на балалайке играет
ну-ка нука - правильное ли это лисп выражение -
(someA (someB someC someD)) ?
и каким образом лисп догадается что оно неправильное
если someC никогда не может быть аргументом someB
до того как выполнит это выражение ??? святым духом ?

>> или лисп уже научился доказывать программы ?
> При чем тут это? Если ты написал валидную программу, которая работает неправильно, то тебе поможет только отладчик :)

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

>> она читаема, и оверхед приемлимый
><office:document-content xmlns:office=
>фигенно читаемо, правда? То, что оверхед _может_ быть приемлемым

приведи сначала аналог офисного документа на лиспе ....
а потом звенди

<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">;
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid-morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">;
<q:preference>none</q:preference>
</q:lodging>
</env:Body>

нечитаемо ??????
>> приведите пример разбора для лиспа когда в неизвестное лисп дерево вставлен известный кусок
>(let ((subtree-we-need (with-open-file "my.document" (extract-subtree-by-condition condition (read))))) (do-whatever-we-want-with subtree-we-need))
>> ваша великая лисп панацея сработает ?
>Более чем.

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

>> приведи мне пример динамически модифициремого бинарного формата ! с хорошей эффективностью и на ширину канала и на парсинг
>zip.

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

> Покажите не простецкую, которую Tcl/Tk не осилит.

Я не знаю нынешних возможностей Tk, но попробуйте сделать вот это: http://img215.imageshack.us/img215/2262/skullscreenshot12el.png

За десять минут сделал в Qt designer. :)

>привести пример парсера xml на с++ меньше 7k ?

Не приведёшь ты нифига. Одна только таблица спецзакорючек на две трети этого объёма потянет. Про таблицу Unicode-символов вообще молчу.

Недопарсеры недо-XML - это же не то, о чём идёт речь, правда?

>Гибкость и отсутствие проблем с версионностью.

1. Гибкость.

- Ну да. Даже гибче отрисовки из примитивов ;)

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

- А вот допустим нужно мне, чтобы количество контролов измнялось в зависимости от чего-то, что я на этой же форме ввожу в текстовое поле. Это мне прикажете на каждый чих городить обработчики, работающие c DOM формы? ЭТО - гибко?

2. Отсуствие проблем с версионностью

- Хм... Есть версия 1.0 платформы X, содержащая 5 стандартных виджетов. В версии 1.1 платформы X появляется ещё один стандартный виджет, итого 6. Есть xml-файл, описывающий форму для версии 1.1 платформы. Мы пытаемся запустить это на версии 1.0. Результат? Это получится нормальный, юзабельный интерфейс?

- Пример Firefox показывает, что xml _никак_ не помогает от проблем с версионностью. И помочь тут может только устаканивание платформы (читай отсутствие "проблем с версионностью" по умолчанию). Действительно, нельзя использовать то, чего нет (или то, что работает не так как ожидается).

3. Тормоза

Про тормоза ничего не было в вашем сообщении, но я таки напишу снова. Применение схемы с xml-layout приводит к тормозному GUI. Потому что закэшировать layout мы не можем (исчезнет даже та "гибкость", которую даёт xml-layout) - а парсить и переделывать DOM на каждое движение мышки на три пикселя.... Это не просто оверхед - это за гранью добра и зла.

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

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

>> привести пример парсера xml на с++ меньше 7k ?
> Не приведёшь ты нифига. Одна только таблица спецзакорючек на две трети этого объёма потянет. Про таблицу Unicode-символов вообще молчу.

> Недопарсеры недо-XML - это же не то, о чём идёт речь, правда?

речь идет о парсере xml эквивалентном парсеру ini
эквивалентный парсер xml - строит только дерево
для первого шага парсинга и работы с недо-ini подобным недо-xml
вполне достаточно
и даже если транслировать спецзакорючки - оставшегося объема - достсточно
а Unicode тут совсем не причем, -единственное наверное
сможет парсить только ascii или utf16

> Одна только таблица спецзакорючек на две трети этого объёма потянет.

Я наверное невнимательно читал спецификацию XML, или забыл что-то (все-таки 7 лет прошло уже). Но я не припомню термина "спецзакорючка".

> Про таблицу Unicode-символов вообще молчу.

А зря, хотелось бы услышать. Какое это имеет отношение к размеру парсера.

Пару уточнений.

> эквивалентный парсер xml - строит только дерево

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

> транслировать спецзакорючки

Может ты хоть объяснишь что это такое? :)

> сможет парсить только ascii или utf16

Не "сможет только", а "обязан поддерживать" "utf-8" и "utf-16".

> Ну да. Даже гибче отрисовки из примитивов ;)

Да. Можно манипулировать наборами базовых виджетов в необходимой компоновке. :)

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

custom widget никто не отменял.

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

Легко. Там же в форме прописываются сигналы и слоты, в том числе и видимость виджетов. Особо запущенные случаи можно реализовать в коде приложения или custom widget.

> Есть xml-файл, описывающий форму для версии 1.1 платформы. Мы пытаемся запустить это на версии 1.0. Результат?

Покажутся все старые виджеты. Новые будут проигнорированы. Обеспечивается обратная совместимость без перепрограммирования.

> Пример Firefox показывает, что xml _никак_ не помогает от проблем с версионностью.

Это проблемы Firefox, не находите?

> Применение схемы с xml-layout приводит к тормозному GUI.

Почему у меня приложения Qt/KDE работают шустрее, чем Tk?

> а парсить и переделывать DOM на каждое движение мышки на три пикселя....

Вы только под Windows пишите и с менеджерами компоновки никогда не связывались? Тогда понятно. :)

> Мне нужно размещать примитивы, но так чтобы они при движении пытались по возможности "прилипнуть" к сетке.

См. менеджеры компоновки. Похоже, вы это пропустили. :)