Интеграция Debian и XML

Пропал калабуховский дом.

Людям, ругающим XML, предлагается по-быстренькому намацать парсер для файлов конфигурации XKB.:)

http://www.lua.org/
http://www.iolanguage.com/
http://www-rn.informatik.uni-bremen.de/software/elk/
http://www.gnu.org/software/guile/guile.html

Все уже намацано до нас.

Ну наконец-то линукс начнет догонять Microsoft в области поддержки новых технологий! Ура, товарищи!

Это все лирика и экзотика. Вы по-старинке, на Сях,.. И посмотрите для начала, какой там формат радостный...

> Это все лирика и экзотика. Вы по-старинке, на Сях,..

Вы посмотрели на приведенные ссылки? это все _встраиваемые_ языки. Использовать их из Си не сложнее, чем любую библиотеку по разбору xml.

> И посмотрите для начала, какой там формат радостный...

Видел, скорбил. Представил себе, как это будет выглядеть в виде xml, и заплакал.

Я знаю, что это встраиваемые языки (даже смотреть внутрь не потребовалось, как у видел ключевые слова lua etc). А как у них будет с производительностью? Да и тянуть интерпретатор только за тем, чтобы отпарсить файл - это перебор. А XML парсер все-таки полегче будет, чем цельный интерпретатор - да и пошустрее.

> Представил себе, как это будет выглядеть в виде xml, и заплакал.

А чего плакать? XML хорош тем, что его и парсить легко (ну, во всяком случае, уже хорошо отработанная вещь) - и ручками курочить. Народ годами плачется о гуевых редакторах клавиатуры. Одна из причин, почему за это никто не берется - душераздирающий формат. Был бы XML - я, может, сам бы взялся на досуге... Вон, я реестр конфигурации запихал в XML (xfree86.xml) - так теперь любой дурак (кхм:) сможет его использовать из любого языка. И сразу с локализацией, смею отметить.

> А как у них будет с производительностью?

Производительность при разборе конфигов? :) Неплохо будет - примерно как у xml.

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

Вы посмотрели на размер этих интертрепаторов? Примерно такой же, как иу парсера xml.

> А XML парсер все-таки полегче будет, чем цельный интерпретатор - да и пошустрее.

Очень сомнительно. Особенно, если интертрепатор поддерживет компиляцию в байткод.

> XML хорош тем, что его и парсить легко (ну, во всяком случае, уже хорошо отработанная вещь)

lisp/scheme - парсятся легче.

> - и ручками курочить

Это мрак. xml непригоден для редактирования руками.

>Это мрак. xml непригоден для редактирования руками.

XKB непригоден тем более.

> Неплохо будет - примерно как у xml.

Даже таки "загибистых"?

> посмотрели на размер этих интертрепаторов? Примерно такой же, как иу парсера xml

ПарсерXML.so почти всегда есть в системе. Во всяком случае, во все нынешние линухи входит как стандарт. Уже даже XFree/Xorg зависят от него. А рассчитывать на наличие lua в системе не приходится... Проблема внешних зависимостей - это важно.

> Особенно, если интертрепатор поддерживет компиляцию в байткод.

Маленький и легенький (сравнимый с libxml) интерпретатор с компиляцией в байткод и JIT-engine? Конкретно - какой из перечисленных ссылок я должен воспользоваться, чтобы найти такое..

> lisp/scheme - парсятся легче.

Очень может быть. Но мы же говорили про формат XKB в сравнении с xml? Откуда вдруг взялся lisp? Кстати, а как быть с поддержкой i18n? Все-таки intltool+gettext - достаточно мощное (и привычное переводчикам!) орудие i18n.

> Это мрак. xml непригоден для редактирования руками.

Странно. Я уже год как поддерживаю xfree86.xml.in с помощью Ивана Паскаля. И ничего не пользую, кроме vi/libxml/libxslt/intltool/gettext. XML становится непригодным при плохой структуре и больших размерах. До определенного предела он вполне обозрим и редактируем.

с XML не считаться, значит быть позади

> ПарсерXML.so почти всегда есть в системе. Во всяком случае, во все нынешние линухи входит как стандарт. Уже даже XFree/Xorg зависят от него. А рассчитывать на наличие lua в системе не приходится... Проблема внешних зависимостей - это важно.

Не аргумент. Сегодня входят, но вчера не входили. Сегодня lua не входит - завтра входит. Все течет, все меняется.

> Маленький и легенький (сравнимый с libxml) интерпретатор с компиляцией в байткод

Да. Это - lua.

$ ll /usr/lib/libexpat.so.1.0.0

-rw-r--r-- 1 root root 126248 2004-02-29 20:02 /usr/lib/libexpat.so.1.0.0

$ ll /usr/lib/liblua50.so.5.0

-rw-r--r-- 1 root root 117988 2004-03-18 20:50 /usr/lib/liblua50.so.5.0

> и JIT-engine?

Не надо передергивать. Кто говорил про JIT?

> Очень может быть. Но мы же говорили про формат XKB в сравнении с xml? Откуда вдруг взялся lisp?

Третья и четвертая ссылки - это встраиваемые scheme. встраиваемый lisp тоже есть (тот же librep).

> Странно. Я уже год как поддерживаю xfree86.xml.in с помощью Ивана Паскаля. И ничего не пользую, кроме vi/libxml/libxslt/intltool/gettext. XML становится непригодным при плохой структуре и больших размерах. До определенного предела он вполне обозрим и редактируем.

Ну и в чем выгода использования xml при простых данных? Кроме движения в ногу со временем?

с ума сойти. Впервые на лоре вижу НОРМАЛЬНЫЙ спор без флейма.

> Сегодня lua не входит - завтра входит. Все течет, все меняется.

Я сегодня живу. Завтра будет входить - будет другой расклад карт. Мы тогда вернемся к обсуждению этого вопроса:)

> $ ll /usr/lib/libexpat.so.1.0.0

А можно (я просто не помню, а под рукой нет) libxml2 еще померять?

> Не надо передергивать. Кто говорил про JIT?

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

> Третья и четвертая ссылки - это встраиваемые scheme. встраиваемый lisp тоже есть (тот же librep).

Это понятно. Я просто говорил про форматы данных XKB/XML - не более. Внезапно тема ушла на то, чтобы конфигурировать в lisp (передаю привет emacs).

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

Выгода по отношению к чему? По отношению к name=value? Или к тому ужасу, который в XKB? Деревянность задарма (мне было нужно именно дерево). Локализация задарма (intltool). Способность работать с форматом из любых языков (покажите мне более-менее развитый современный промышленный язык без парсера XML).

Ходят легенды, что такое случалось и раньше.

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

> Я сегодня живу. Завтра будет входить - будет другой расклад карт. Мы тогда вернемся к обсуждению этого вопроса:)

Вы сами творите будущее :)

> А можно (я просто не помню, а под рукой нет) libxml2 еще померять?

$ ll /usr/lib/libxml2.so.2.6.9

-rw-r--r-- 1 root root 979696 2004-04-28 10:30 /usr/lib/libxml2.so.2.6.9

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

Так _нет_ никакого проигрыша по скорости для конфигов. Компиляция в байт-код - чистый выигрыш (парсинг исключается совсем).

> Выгода по отношению к чему? По отношению к name=value?

Хотя бы.

> Или к тому ужасу, который в XKB?

Вполне приличный конфиг. Уж всяко читаемей xml.

> Деревянность задарма (мне было нужно именно дерево).

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

> Локализация задарма (intltool).

Все проблемы решены?

> Способность работать с форматом из любых языков (покажите мне более-менее развитый современный промышленный язык без парсера XML).

lua -> C -> любой промышленный язык.

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

вообще говоря - да.

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

Нет, разумеется.

> Вы сами творите будущее :)

Вы мне льстите:)))

> 979696 2004-04-28 10:30 /usr/lib/libxml2.so.2.6.9

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

> Так _нет_ никакого проигрыша по скорости для конфигов. Компиляция в байт-код - чистый выигрыш (парсинг исключается совсем).

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

> Вполне приличный конфиг. Уж всяко читаемей xml.

Вы это серьезно? Значит, это зависит от того, кто читает:) А уж в более-менее приличном редакторе xml (с отображением структуры) это было бы еще читаемей.

> У вас есть файловая система. :) Для простых конфигов - вполне хватает. Кстати зачем вам нужно дерево?

Хорошо, что Вы пошутили про файлы. А то я бы испугался, что Вы серьезно:) Дерево нужно, потому что в списке доступных элементов конфигурации есть раскладки, модели, группы опций. В группах опций есть опции. В раскладках - варианты. Среди всего этого есть имена и описания. Причем описания на разных языках. Более того, у меня начинает появляться подозрение, что этим дело не ограничится, потребуются кросс-ссылки:) Раскладка в простой name=value возможна, но геморройна и потребует искусственных соглашений об именах (и/или доп. парсенья value). Поэтому было решено избежать костылей этого типа - и использовать честный, валидируемый, i18n-ый xml.

> > Локализация задарма (intltool).

> Все проблемы решены?

Вопрос не понят. intltool достаточно надежно решает свои задачи. Он удобен переводчикам. Или Вы про что-то другое спрашиваете?

> lua -> C -> любой промышленный язык.

Угу. С одной только маленькой разницей. Количество людей, способных редактировать xml (особенно с гуевыми тулзовинками) несколько больше (по моим оценкам), чем кол-во людей, способных редактировать lua.

Вот интереса ради - попробуйте взять несколько маленьких кусочков xfree86.xml и выразить на каком-то из языков, который Вам нравится. Было бы любопытно посмотреть, как Вы это видите... Если у Вас есть время, разумеется.

Ok.

>гу. С одной только маленькой разницей. Количество людей, способных >редактировать xml (особенно с гуевыми тулзовинками) несколько больше >(по моим оценкам), чем кол-во людей, способных редактировать lua.

Синтаксис lua прост до безобразия. ( Описание со всевозможными пояснениями и примерами занимает около 10 страниц ) XML значительно более объемист ( порядка на два ). Хотя бы по тому, что синтаксиса не имеет, и для корректного использования требует всяких довесков ( DTD в простейшем случае ) ибо корректность конфига все равно проверять придется. Плюс lua и т.п., кроме собственно декларирования могут определять некоторую функциональность т.к. это встраиваемые языки общего назначения, а для xml нужно еще что то типа xslt присобачить ... да ... грустная картина однако.

> Хотя бы по тому, что синтаксиса не имеет,

Как это не имеет? А что же такое well-formed xml? Мне кажется, тут скорее проблема с семантикой - ее голый XML действительно не имеет.

> DTD в простейшем случае

Да, конечно, без DTD совсем плохо. Зато сделал DTD - сразу получил семантику.

> могут определять некоторую функциональность

Однозначно. Поэтому для них есть области применения, где XML, будучи чисто декларативным, просто не годится. Но я не уверен, что для конфигурации (вещи, в общем, декларативной) эти языки не являются overkill. Кстати, распространенная практика использования всяких LDAP/ADS/NDS/... (которые, по сути, тоже просто деревья) для конфигурирования - тоже является косвенным показателем того, что конфигурация, в общем случае, хорошо описывается просто деревом.

А xml - да, если чего надо с ним делать, быстренько ваяется xslt (я сделал один простенький, чтобы убивать переводы, тождественные оригиналу). Нет проблем:)

> грустная картина однако.

Что же Вам так взгрустнулось?:)

В жопу XML - этот велосипед они просто уже заколебали изобретать. SXML рулит, всё остальное - придумки придурочных коммерсантишек.

Это ублюдский XML - новая технология? SGML-у тыщя лет в обед будет.

Какая разница? Infoset - он и в Африке ... И выбирайте выражения помягче, пожалуйста (это я про направление для XML).

Проще, чем S-выражения, ничего не придумаешь. XML - по уродски избыточный. Его придумали мерикановские безграмотные чиновники, которые Лиспа в глаза не видели. И в жопу всякие там интерпретаторы - парсер S-выражений на Си пишется в 5 строчек. XML придумали падонки!

Ты спроси у убогих, которые на Jave пишут, какие у них жопы с версиями "обязательно установленного в системе" парсера XML. После такого точно ни с каким XML связываться не захочется - по крайней мере в Jave.

>Как это не имеет? А что же такое well-formed xml? Мне кажется, тут >скорее проблема с семантикой - ее голый XML действительно не имеет.

А это кусок синтаксиса - типа как скобки в С/С++/Жаба ...

>Зато сделал DTD - сразу получил семантику.

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

>Что же Вам так взгрустнулось?:)

Да уж больно громоздкая штука этот xml.( работающая связка - это xml+dtd+xsl ибо голый xml не пляшет ) Я бы предпочел lua или что нибудь подобное ...

Да есть и другие реализации для Infoset (включая двоичные). Дело же не в этом. А вот что XML придумали чиновники - это что-то новенькое. Можно поподробнее? Или (извините, такое ощущение сладывается) Вам просто покричать хочется?

Я - один из этих "убогих". Мне очень редко встречаются ситуации (да, бывают - но действительно очень редко), когда меня интересует, какой именно парсер у меня в системе. Стандартизация JAXP+DOM+SAX делает эту "деталь" почти прозрачной.

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

Респект :)

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

Для меня DTD несет в себе смысл. И параллельно уточняет синтаксис. Если layout может включать variants - это семантика или синтаксис?

> xml+dtd+xsl ибо голый xml не пляшет

Ну, уж xsl-то точно опционален. Да, без dtd коряво жить, это правда.

> Я бы предпочел lua или что нибудь подобное ...

Это я понял. Кто же Вам не дает? Разве что начальство, начитавшись брошюрок:) Я немного пользовал встраиваемые языки (конкретно jscheme). Да, для некоторых вещей они просто необходимы. Но конфигурацию мне удобнее задавать чисто декларативным языком.

Синтаксис XML состоит из 7-ми правил, марш их учить на http://www.w3.org/TR/REC-xml, клоун!

Не XML, конечно, а его жирного предка SGML. Типичное чинушье творение...

Просто уж больно много жабьего софта, требующего КОНКРЕТНУЮ версию того же xalan, не желающего никак работать с другой версией. Когда они в одном CLASSPATH, то можно вешаться.

>>парсер S-выражений на Си пишется в 5 строчек.
Можно по подробней ? Что за S-выражения такие ? Очень интересно !

Прочитай что-нибудь про ЛИСП, узнаешь.

А причем тут xml ?

Ну, все-таки XML != SGML. И идея-то в начале была хорошая...:) И идея с Инфосетом - тоже очень правильная (ИМХО).

> требующего КОНКРЕТНУЮ версию того же xalan, не желающего никак работать с другой версией. Когда они в одном CLASSPATH, то можно вешаться.

Ну, во-первых, с парсерами тоже так бывает (хотя и очень редко). Во-вторых, CLASSPATH - "это наше все":) За ним надо следить, не замусоривать, холить и лелеять:)

При том, что XML Infoset можно при желании уложить в lisp-like синтакс - получится SXML. Или в другой синтакс. Но ведь это неважно...

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

Дело не в том, что это можно сделать. Важнее, что это НУЖНО было сделать. Но вместо этого был придуман совершенно ублюдочный и перегруженный синтаксис - за что и гореть в аду всем разработчикам XML.

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

Ну, ад - дело темное. А народу после HTML и после SGML без угловых скобочек было бы плохо, наверное. А я вообще стараюсь абстрагироваться от этих мелочей. Главное - это дерево:)

Look at YAML much better then XML, evel SXML

А чо такое XKB ?

XKB - расширение X Window. Его непростые файлы конфигурации взяты в этом контексте для примера заковыристого не-XML формата.

Дык блин - был бы XML действительно "родной" для Джавы технологией - не было бы никаких разных версий - парсер был бы в системной библиотеке. :(