xml

> и как вы думаете это правильно пихать xml во все щели,

Нет.

> это просто дань моде

Это блажь.

> или это действительно удобно?

Удобства сомнительны.

а что бы вы предложили в данном случае на замену xml?

xml не так уж и плох для _передачи_ данных

> xml не так уж и плох для _передачи_ данных

Ты уверен???

Правильное определение - xml не так уж плох для обмена данными между системами, для _передачи_ он крайне плох и неэффективен!

>xml не так уж и плох для _передачи_ данных

а для хранения?

например OO и KOffice

почти это я и имел в виду ;)

тут двояко можно на дело смотреть: одна аппликуха создала, другая открыла - вот тебе и обмен данными; а то, что ОО-файлы у тебя на харде мёртвым грузом лежат - ничего не значит: не рационально для хранения разрабатывать принципиально новый, специализированный формат ;)

>xml не так уж и плох для _передачи_ данных

Чего не скажешь про прием и обработку оных;-)

> а для хранения?

так же плох, как и для передачи ;)

>Чего не скажешь про прием и обработку оных;-)

и что сложного в парсинге xml?

по-моему легче легкого.

DonkeyHot, во-во, а некоторым ещё и делать и отправлять их приходится...

>> а для хранения?
>
>так же плох, как и для передачи ;)

и чем же он плох?

если сжать его чем-нибудь то вся служебная информация будет занимать
такой же объем как и любом другом формате.

> и что сложного в парсинге xml?

> по-моему легче легкого.

Да ты что, одним разбором вообще-то дело не заканчивается, если ты не в курсе.

>Да ты что, одним разбором вообще-то дело не заканчивается, если ты не в курсе.

просвети меня что же кроме разбора надо делать

> если сжать его чем-нибудь то вся служебная информация будет занимать такой же объем как и любом другом формате.

Вот тебе пример офигенного зюмеля, сжимай на здоровье:

<Document> <title type="none"/> <header type="absent"/> <paragraph> <word> <letter>F</letter> <letter>S</letter> <letter>C</letter> <letter>K</letter> </word> <delimeter type="space"/> <word type="strong"> <letter>F</letter> <letter>S</letter> <letter>C</letter> <letter>K</letter> </word> <delimeter type="dot"/> </paragraph> <footer type="absent"/> </Document>

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

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

и что сложного?

man gzip

и тем более пример сознательно усложнен

а какой более оптимальный, чем использование xml, путь вы видите?

> и что сложного?

Ничего, где будет пресловутая выгода от сжатия?

> man gzip

Это шутка?

Я тогда посоветую это: http://www.gzip.org/zlib/rfc-deflate.html

> и тем более пример сознательно усложнен

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

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

а что такое зюмель, просветите меня темного?

а насчет словарей,
для чего соглашение для транскрипции,
все сделать в unicode вот и все.

но там есть такие свойства слов как время(для глаголов), род и т.д.

что хорошо бы выделить чтобы будущим OpenSource программам переводчикам
было легче работать.

Синтаксис XML чрезмерно усложнён. S-выражения проще и мощнее.

Lisp

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

> а что такое зюмель, просветите меня темного?

XML в русской транслитерации.

> а насчет словарей, для чего соглашение для транскрипции, все сделать в unicode вот и все.

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

> но там есть такие свойства слов как время(для глаголов), род и т.д.

Ууу, куда вы замахнулись, к сожаление количество этих свойств сильно варьируется от языка к языку...

> что хорошо бы выделить чтобы будущим OpenSource программам переводчикам было легче работать.

Вот это уже совершенно лишние, лучше всё же привести в порядок то что уже есть.

Именно, что одно и то же, но S-выражения парсить легче, на них не только XML Infoset можно выразить, но и куда как более общие (низкоуровневые) структуры, для них уже есть готовый мощнейший язык обработки, который сам так же имеет синтаксис, основанный на S-выражениях. И всё это было задолго до XML. Спрашивается - на хера быдло изобрело для себя этот убогонький XML?

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

и при чем здесь тормоза grep и словари в xml?

и unicode является наиболее лучшей альтернативей чем неизвестная никому
кроме пары человек формат транскрипции.

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

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

и что за язык?

Использовать XML для больших словарей --- излишество. Они и так в виде ASCII с пробелами кучу места занимает.

Lisp, конечно же.

http://ssax.sf.net/

> и при чем здесь тормоза grep и словари в xml?

Хых, ну я хочу по-быстрому найти слово в словаре, самый быстрый способ, имхо, grep ;)

> и unicode является наиболее лучшей альтернативей чем неизвестная никому кроме пары человек формат транскрипции.

Это что за разговоры, типа, если на ЛОРе вывесят ссылку на спецификацию мы просто поленимся её почитать? Нда, куда мир катится... ничему не хотят учится, а никому ненужные велосипеды изобретать - рады ;)))

>Lisp, конечно же.

интерпретатор lisp займет намного больше места и ресурсов чем
парсер xml, а удобства принесет не так много.

Ты глупости говоришь (очевидно, по безграмотности).

Lisp тебе заменит и XSLT как минимум.

>Хых, ну я хочу по-быстрому найти слово в словаре, самый быстрый способ, имхо, grep ;)

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

во-вторых

как с помощью grep из xml вытащить перевод слова я что-то не догоняю

>Это что за разговоры, типа, если на ЛОРе вывесят ссылку на спецификацию мы >просто поленимся её почитать?

вы представьте весь словарь в unicode, нафига транскрипцию
записавать не в нем?

>а никому ненужные велосипеды изобретать - рады ;)))

вы о чем?

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

> во-вторых

> как с помощью grep из xml вытащить перевод слова я что-то не догоняю

Я тоже не догоняю причём тут зюмель и его недостатки, когда я вам про обычный текст говорю? ;)

> вы представьте весь словарь в unicode, нафига транскрипцию записавать не в нем?

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

>>а никому ненужные велосипеды изобретать - рады ;)))

>вы о чем?

о предложении ещё наплодить словарей ;)

>Lisp тебе заменит и XSLT как минимум.

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

я реализовал это с помощью 300 строк на C,

туда входил и парсер и валидатор.

возможно ли тоже самое сделать для lisp?

>о предложении ещё наплодить словарей ;)

не, насколько я понял идея не плодить словари,
а собрать все доступные словари в одном месте и чтобы они имели один формат.

xml очень удобен imho. 
Другое дело, что в некоторых обастях он излишен. Намеренно преувеличенный пример:

<movie01>
   <frame1>
      <pixels>
         <c x=1 y=1>
            <red=FF\><green=A2\><blue=12\><alpha=2\>
....

IMHO XML хорош для ОБМЕНА информацией ... а не для хранения .. не надо сравнивать XML (формат) и Lisp (язык)

Сравниваются XSL, XPath, XQuery, и т.п. с Lisp, и XML с S-выражениями.

Не путай разницы. ;)

> размер со скоростью являлись существенными

У бинарных форматов и размер меньше и скорость выше.

> я реализовал это с помощью 300 строк на C

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