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

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

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

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

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

Ты бы, это, для разнообразия книжку бы хоть какую-нибудь про unix бы почитал. Надо же хоть что-то знать о предмете обсуждения.

Или чукча не читатель - чукча писатель? Вопрос риторический.

>Или чукча не читатель - чукча писатель? Вопрос риторический.

чукчами себя выставили только xml-ненавистники :) Может, сами почитаете? А то о предмете дискуссии у вас какое-то смутное представление

>чукчами себя выставили только xml-ненавистники :) Может, сами почитаете? А то о предмете дискуссии у вас какое-то смутное представление

Ненависть это не более чем разновидность страха, но чего тут бояться то? Слова о стандарте де-факто для хранения и обмена данными вызывают удивление. Очень правильно написал Anode про мегабайты и такты, подписываюсь под каждым словом. Конечно проще наваять XSLT чтоб потом оно часами парсилось, чем писать нормальную реализацию обмена данными. Что тут скажешь: "Рожденный ползать летать не может."

> Конечно проще наваять XSLT чтоб потом оно часами парсилось, чем писать нормальную реализацию обмена данными

писать на каждый чих свою реализацию обмена данными - так и сдохнуть можно. XML хорошо подходит для обмена древовидными структурами (см тот же ajax или xul/xpfe). XSLT описывает логику преобразования xml. Или вы предлагаете для этого разрабатывать бинарные протоколы на каждый сервис и плющить мозг, разбирая этот протокол на js? Я молчу про конвертеры, неободимые чтобы представить данные в виде html/text/tex и проч. Их тоже придется писать на каждый чих. Собственно, я уже повторяюсь :) перечитай тред - обмен мнениями был достаточно информативным :)

>чукчами себя выставили только xml-ненавистники :) Может, сами почитаете? А то о предмете дискуссии у вас какое-то смутное представление

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

А на чём зарабатывают деньги ? Начнём с людей, которые очень нуждаются в новых технологиях - книгописатели(представил эту смесь маркетолога+копирайтэра и ещё набор качеств - не про всех конечно, но я про преуспевающих), эти писатели очень хорошо работают с людьми которые не видят перед собой конкретных целей и мечатся от одной технологии к другой - вам говорят о плюсах расширяемости, хотя даже 1% ваших проектов никогда не пострадает от этого недостатка - только энергопотребление всей нации увеличиваете.. При этом писатели, повторяя слова, о том что в информационном мире будут преуспевать люди, владеющие новыми технологиями, и вы просто выбрали для себя нишу - быть вечным студентом и делиться с остальным стадом слепых ребят новыми модными технологиями.. Корпоративный рынок, в котором сидят всякие саны и IBM, толкая всё мощнее и мощнее железо для обработки выдуманых плюсов от XML :) Ты просто щас пролетишь по кругу людей, которые зарабатывают на тебе деньги и всё .. Вперёд - осваивать новые технологии, что там ещё щас модно Ruby On Rails :)

Еслиб не быдлокодерство веб-девелоперов(которых щас к сожалению большинство), сейчас бы мы не видели свыше пол миллиона людей которые только на одном onspeed'е сидят и оплачивают, а ведь есть ещё подобные сервисы, так что клиентура с мозгами всё ещё есть :) Это же любимый ваш призыв - главное то что вообще удалось запустить продукт, а то что если я вдруг захочу работать с 10ю продуктами из серии того же тормоза, то вся прелесть многозадачности ОС куда-то потеряются )

>Я молчу про конвертеры, неободимые чтобы представить данные в виде html/text/tex и проч. Их тоже придется писать на каждый чих. Собственно, я уже повторяюсь :) перечитай тред - обмен мнениями был достаточно информативным :)

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

> А что всегда остаётся и никогда не сдвигается с места и до сих пор работает хорошо ? Подумал ? нашёл ответы ) молодец...

нашёл. лисп. он как был академическим языком так и остался. и?

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

ты путаешь причину и следствие. Не книгописатели определяют развитие технологий. Но зато они всегда готовы быстренько налабать "руководство для полных идиотов" по любой популярной технологии

>Ты просто щас пролетишь по кругу людей, которые зарабатывают на тебе деньги и всё .. Вперёд - осваивать новые технологии, что там ещё щас модно Ruby On Rails :)

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

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

чей призыв? поясни

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

по поводу регулярно: web можно считать регулярным обменом данными? Думаю, можно. Только вот данные могут быть любыми и универсальный формат для обмена любыми данными лучше чем XML ты не напишешь.

А по поводу большого объема - согласен. Так никто и не гоняет гигабайты в xml :)

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

Интересно, почему KDE активно переходит на KConfigXT, использующий XML вместо ini-файлов, а Gnome давно уже это сделал?

> А в случае написания больших текстов XML противопоказан.

А почему вся документация по KDE в docbook. Да и для остальных серьёзных проектов - также. Где же противопоказания? И где лекарство? :)

>Интересно, почему KDE активно переходит на KConfigXT, использующий XML вместо ini-файлов, а Gnome давно уже это сделал?

сам удивляюсь. Совсем недавно кдешники вопили "фу! в гноме реестр и зумль!" :)

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

>Интересно, почему KDE активно переходит на KConfigXT, использующий XML вместо ini-файлов, а Gnome давно уже это сделал?

Есть такое слово модно. Люди не хотят думать и слепо следуют моде не разбираясь в причинах устоявшихся традиций. Текст для nix-традиций это всё. Обработка текста то, на чём держатся удобства и преимущства Unix.

>> А в случае написания больших текстов XML противопоказан.

> А почему вся документация по KDE в docbook. Да и для остальных серьёзных проектов - также. Где же противопоказания? И где лекарство? :)

Мазохисты? Не разобрались в плюсах info и поэтому не поглядели в сторону более приемлимых аналогов? Откуда я знаю какая моча ударила в голову тем, кто принял такое идиотское решение?

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

Хорошо хоть маны пока ещё не решаются выкинуть - хоть что-то будет.

Ну, вот - дискуссия плавно скатилась на обсуждение сравнительных достоинств и недостатков "эмуляторов виндовса" ;)

Анекдот:
Один музыкальный критик жалуется другому:
-Ясно, что вся современная эстрада - дерьмо. Но самое ужасное даже не в том, что всё это дерьмо приходится слушать. Самое ужасное, что постепенно начинаешь разбираться в оттенках вкуса этого дерьма.

>Есть такое слово модно. Люди не хотят думать и слепо следуют моде не разбираясь в причинах устоявшихся традиций. Текст для nix-традиций это всё.

xml - это текст. Можешь сходить в аптеку.

> Мальчик, у тебя все мозги на парсинг xml'я ушли?

Я уже давно не мальчик. :)

> На осознания факта, что если используется MathML, то формулы нужны в 100% случаев сил уже не хватает?

Специально для вас могу дописать, что MathML используется гораздо реже чем XML. И, на всякий случай, предложить описать форму интерфейса не на XML.

> Голословный бред сивой кобылы.

У вас потрясающей глубины аргументация. И кто меня "мальчиком" называл? :) По сути - вы отрицаете широкое применение XML (в виде docbook) для документирования? Самому не смешно? :)

> emacs перестал поддерживать (что бы это ни значило) ЛаТеХ?

А Emacs разве популярен? http://www.linuxquestions.org/questions/forumdisplay.php?f=69

> У ЛаТеХа есть такие проблемы?

Да. И серьёзные. Конечно, гуру не понять меня. Но когда я пробую из сгенерённого kdissert *.tex получить что-либо читаемое, то вылезают проблемы - нет ucs. Ладно, поставил. Вылезают непонятные ошибки с русскими буквами. Подобные ошибки дики в наш просвещённый век. :)

> Да? Бенчмарк в студию.

Как соберётся хоть какой-то документ LaTeX без ошибок - напишу. Пока же нареканий к производительности khelpcenter, который на лету из docbook делает гипертекстовые HTML, нет.

> Да что ты говоришь. Наверное набрать $ xpdf file.pdf или $ xdvi file.dvi это очень-очень-очень большой геморой, которого лишены xml'щики.

Для этого нужна такая мелочь, как создание dvi/pdf из tex. А это, как я показывал выше - нетривиальная задача. :)

> Короче, ты срезался по всем пунктам.

Я аргументированно написал. Так что "не говори "гоп", пока жопа за забором". :)

> особенно размером в несколько мегов и пожатый зипом...

А в чём сложности? Напрягает пара секунд?

> Вообще миф о читабельности xml уже порядком раздражает...

Это не миф - это суровая практика работы. KDE, Центр справки - docbook на лету превращается в красивый и удобный справочник. :)

> минимальный парсер использует объем памяти == размеру xml документа

Насколько я знаю про expat - меньше. Всё же не DOM строит. :)

> Можно посмотреть на функцию, вычисляющу квадратный корень

А зачем вычисление квадратного корня в таблице стилей? :)

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

Покажите как Lisp справится с:
1. Описанием сложных интерфейсных форм
2. Гипертекстовой документацией
3. Веб-сервисами

>> Вообще миф о читабельности xml уже порядком раздражает...

>Это не миф - это суровая практика работы. KDE, Центр справки - docbook на лету превращается в красивый и удобный справочник. :)

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

O'Reilly - да, качественные книги, но это результат отработанной troff-технологии.

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

> Что мешает использовать > \n и т.п. в первом случае ?

Ничего. Но если правила парсинга XML стандартизованы, то насчёт самопальной поделки по парсингу указанного текстового формата у меня нет никаких соображений. Если бы написали сразу подстановку, то было бы хоть немного понятнее. :)

>> Описанием сложных интерфейсных форм

Бред какой-то. layout-managers задолго до зумля существовали (tk). Кроме того зумль ортогонален layout-manager-ам, главное преимущество которых в том, что очень удобно описывать интерфейс непосредственно в программе.

> Ой - да ты его с CLIP'ом попутал! :) Вот уж чего точно не надо!

CLIP поменьше жрёт и побыстрее работает. :)

> НО - XML _не_ нужно использовать для конфигов например(чаще всего). Какая к чёрту валидация конфигов?

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

>XML приходится прятать - значит общество открытых исходников по сути добровольно от этих исходников отказывается - нонсенс.

у тебя с логикой беда. Даже не просто беда - а полный пипец. Кто от тебя что прячет? и главное - куда?

> Есть команда \include + в заголовке можно определять/переопределять любые команды и окружения. Это то?

Не уверен что полный аналог, но суть где-то та. Спасибо за ликбез по LaTeX. Для общего развития полезно будет :)

Но по сути мы разобрались только с одиним процессом authoring. Теперь следующий - trnaslation.

Есть какой-то программный продукт, к нему пишется документация. Документация пишется на нескольких языках. Сначала она пишется на одном языке, потом переводится. Немногие компании могут позволит содержать штат переводчиков, поэтому образовался такой класс организаций как LSP (LSP - Localization Service Providers), которые профессионально занимаются переводом. Существуют специализированные инструменты, для автоматизированного перевода (ПРОМТ не вспоминать).

Вкратце, процесс выглядит так: - XML документ с исходником, парсится и переводчик в своей программе видит набор text nodes из этого документа. - каждый text node переводится отдельно, таким образом формируется аналогичный по структуре документ, но на другом языке. - кроме того, соответствующие пары text nodes/предложений формируют так называемый translation memory, который потом используется при следующих переводах.

Например, с программным продуктом поставляются две книги: User Manual и Reference Guide. Они посвящены одному и тому же продукту. Вполне вероятно, что в них будут совпадать некоторые абзацы предложения.

Когда переводится документ с уже не пустой translation memory: - исходный документ так же рабивается на text nodes; - но в колонке с переводом уже стоит какое-то значение, если оно было найдено в translation memory и рядом пишется вероятность правильности этого перевода. То есть, если исходный блок слово в слово соответствует тому, что сохранен в TM, то ставится 100%.

Вариант второй: выпускается новая версия продукта например 5.0. Перед этим была 4.0, к ней писала документация и от нее осталась translation memory. Используется на ура, на переводе экономится туча времени и денег.

Если ты решил сменить LSP подрядчика, а у него другой инструмент для перевода - не беда. TM твоя собственность. Есть поддерживаемый практически всеми современными LSP tools формат XLIFF (опять же OASIS), который тебе первый подрядчик экспортировал, второй импортировал и все.

Я понимаю, что я немного гружу :), но ты, как я понял тоже достаточно занимался подготовкой документации. Просто у меня это почти специализация на протяжении последних двух лет (но я не tech writer, а developer). Отличия в масштабе и требованиях к документации.

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

И, собственно, видя весь процесс в целом, довольно сложно представить что-либо более удобное, в сумме столь легко поддающееся: - обработке; - передаче между различными этапами workflow'а; - передаче между инструментами от различных vendor'ов (тут не последнюю роль сыграла агрессивная политика по стандартизации).

Насколько я понимаю, раз у вас две книжки состоят из пересекающихся кусков, то можно master документ сделать, состоящий только из одних include-ов, который подключают отдельные файлы. По мере перевода каждый из включаемых файлов переводится на другой язык, а master-документ остается тем-же самым. Единственный нужный для этого инструмент - файловая система и несколько каталогов :)

> Так что смысла в такой валидации особо не видно.

Ну как тебе сказать. Помнишь твой пример о том, что люди не настолько организованны чтобы проставлять ID-шки. Так вот: редактор валидирующий документ при редактировании, не даст тебе создать невалидный документ, если ты даже поломаешь что-то в vi/notepad в обход спецсредств, то XML БД не даст тебе поместить невалидный документ в репозиторий, гарантируя валидность документа на следующем шаге обработки. То есть, смысл в ней все-таки есть.

В то время как попортить текстовый (например java properties) файл и положить его в CVS я смогу без проблем. А тот кто его оттуда вытянет, весело навернется по IllegalArgumentException при попытке загрузить.

Другой дело ты прав в том, что структура может быть валидной, а данные внутри тегов corrupted. Вопрос: а уже есть silver bullet? Текстовые файлы и архивы уже защищены от повреждений? Контрольные суммы/дайджесты еще никто не отменял и для XML файлов, в общем-то. Но это уже вопрос протокола, ИМХО.

>Пример. Есть многоязычный сайт

Ну допустим есть...

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

Ты уверен что пользователю легче выбрать язык в ручную??? а програмист за что деньги получает??? За мастурбацию типа: "пишется XML конфигурация, которая задает состав и вложенность регионов. Берется SVG карта мира." ???

>Заслушаю вариант решения без SVG.

дай угодаю... из запроса HTTP взять инфу о языке юзер-агента??? ;)

зы: кстати, никто (в частности yeolahim) не объяснил - почему xml "для веба вообще сказка". Из чего делаю вывод, что место ему в сказке... ))

> xml - это не UNIX-way. Не строки.

Как раз строки.

> Основные тулзы типа grep/sed - не работают как и diff/patch.

xml_grep, xsltproc есть. Так что не надо тут баек рассказывать.

> Для редактирования надо Гуй.

Вроде взрослый человек, а такую ахинею несёте! С какого бодуна GUI нужен-то? Хоть joe используйте, хоть ed - XML можно редактировать также, как и любой другой текстовый файл.

P.S. "Чтобы не говорили тут что ниасилил: ещё в 99 году получили award за инновационную имплементацию". Ниасилил! Потому как ваши высказывания про XML просто поражают. :)

> сам удивляюсь. Совсем недавно кдешники вопили "фу! в гноме реестр и зумль!" :)

Это была историческая ошибка. Признаём и каемся. :)

> Я как-то видел результат перевода docbook в твёрдую копию. Вроде и люди знали что делали. Книжечка шла с дистрибутивом - за неё были деньги плачены. Если то что там было красивый и удобный справочник, то я папа римский.

Я не знаю о какой книге ты говоришь, но я думаю, что там за основу были взяты Walsh'евские stylesheets, в которых немного подправили стили. На самом деле там гордится действительно нечем, но там получение коммерческого look'n'feel и не было самоцелью, скорее показать возможности технологии.

O'Reilly все таки коммерческая организация, денег на книжках зарабатывают. Те кто, денег зарабатывают могут разработать и что-то поприятнее.

Ладно (да простит меня мой NDA), если у тебя будет возможность посмотри книги к Autodesk Architectural Desktop 2005 (или другие продукты 2005 года и позже), и скажи свое мнение, нормально оно выглядит или нет.

> Есть такое слово модно.

Это не мода, а чистая прагматика. Вспомните, как развивались языки программирования: asm->C, потом ООП, компоненты. Та же самая эволюция наблюдается и в форматах данных. XML - это не модно, это удобно для разработки и переносимости.

> Текст для nix-традиций это всё.

XML уже стал бинарным? Где вы такую траву берёте? :)

> Обработка текста то, на чём держатся удобства и преимущства Unix.

"Существует несколько путей сделать что-либо". Это тоже Unix-way. В данном контексте можно рассматривать и обработку XML. Ваш пассаж про "строки - это преимущество Unix" - лишь плод вашего воображения. :)

> Мазохисты? Не разобрались в плюсах info и поэтому не поглядели в сторону более приемлимых аналогов?

Кто бы говорил! Наберите info:gettext в Konqueror и после этого говорите про то, что "не разобрались". :) docbook по прагматическим соображениям оказался удобнее для переносимости и локализации. Что вы можете сказать про локализацию info? :)

> Но на волне узнавания хорошей документации не появится.

Пользователям глубоко фиолетово, что там внутри. Не фиолетово нам, локализаторам и разработчикам. :)

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

> Я как-то видел результат перевода docbook в твёрдую копию.

Что вам мешает выполнить docbook2pdf и распечатать результат? :)

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

Это говорит о квалификации техписов, а никак не о форматах, не так ли? :)

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

> XML приходится прятать - значит общество открытых исходников по сути добровольно от этих исходников отказывается - нонсенс.

Прятать в GUI и не отдавать вообще - разные вещи. При желании вы можете спокойно изменить docbook - он остаётся в системе.

> Бред какой-то. layout-managers задолго до зумля существовали (tk).

И где сейчас этот Tk? Почему его не используют - не задумывались?

> Кроме того зумль ортогонален layout-manager-ам, главное преимущество которых в том, что очень удобно описывать интерфейс непосредственно в программе.

Вот и ответ на вопрос: мешанина из разметки и кода не встретила тёплого приёма среди разработчиков. Значит, такой подход неверен. :)

Я вот сделал:
docbook2pdf /usr/local/src/gtk+-2.8.6/docs/reference/gdk/html/index.sgml
...
jade:I: maximum number of errors (200) reached; change with -E option
jade:/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl:475:2:E: too many arguments for function

"Как соберётся хоть какой-то документ LaTeX без ошибок - напишу. Пока же нареканий к производительности khelpcenter, который на лету из docbook делает гипертекстовые HTML, нет. "

С латехом оно как-то более понятно.

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

Вы немного не поняли. Локализатору нужно переводить только текст. Никакой разметки ему видеть не нужно. Пример: на базе docbook формируется .pot файл (xml2pot), который можно средствами gettext слить с существующим переводом и уже средствами po2xml преобразовать в локализованный docbook. Я, как локализатор, вижу только *.po в KBabel. Вся остальная работа идёт в автоматическом режиме.

>>И где сейчас этот Tk?
make xconfig делать не приходилось?
>>мешанина из разметки и кода
Модули не вчера придумали.

>> А почему вся документация по KDE в docbook. Да и для остальных серьёзных проектов - также. Где же противопоказания? И где лекарство? :)

> Мазохисты? Не разобрались в плюсах info и поэтому не поглядели в сторону более приемлимых аналогов? Откуда я знаю какая моча ударила в голову тем, кто принял такое идиотское решение?

В info уже можно показывать скриншоты?

> Я как-то видел результат перевода docbook в твёрдую копию. Вроде и люди знали что делали. Книжечка шла с дистрибутивом - за неё были деньги плачены. Если то что там было красивый и удобный справочник, то я папа римский.

Вы путаете DocBook/XML как исходный формат документации c результатом работы PassiveTeX. Довольно неразумно.

> Это говорит о квалификации техписов, а никак не о форматах, не так ли? :)

Ну вот, уже до моей квалификации добрались :-D А ну брысь гуглить обсуждение PassiveTeX в docs@ :-)))

> make xconfig делать не приходилось?

Нет, только make qtconfig. Видать сильно прижала Tk, раз сделали ещё одну цель сборки. :)

> Ну вот, уже до моей квалификации добрались :-D А ну брысь гуглить обсуждение PassiveTeX в docs@ :-)))

Спокойнее, Саша! Я не видел документации. Но исходя из пассажа Evgueni ("Если то что там было красивый и удобный справочник, то я папа римский.") речь идёт про

а) плохо написанную документацию
б) отвратительное оформление
в) неадекватность Evgueni

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

Речь идёт об оформлении. Первые два релиза документации, выпущенные в связке docbook/xslt/passivetex/pdftex (если не путаю последнее название) выглядели страшненько - стили преобразования были не отточены, бумага тоже не очень. Как только добили стили и повыкидывали большинство скриншотов, всё стало нормально. По какой технологии документация сейчас собирается, я не очень хорошо себе представляю. Во всяком случае, книжку к предпоследнему Мастеру в руки было брать приятно :)

>(ПРОМТ не вспоминать).

А его кто-то помнит?

> Вкратце, процесс выглядит так: - XML документ с исходником, парсится и переводчик в своей программе видит набор text nodes из этого документа. - каждый text node переводится отдельно, таким образом формируется аналогичный по структуре документ, но на другом языке. - кроме того, соответствующие пары text nodes/предложений формируют так называемый translation memory, который потом используется при следующих переводах.

Я не вижу чему это протеворечит в LaTeX. Можно сделать так, чтобы текст выводился параллельно, например так:

\usepackage{parallel} ... \begin{Parallel}{<left-width>}{<right-width} \ParallelLText{left-text} \ParallelRText{right-text} \ParallelPar ... \end{Parallel}

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

>Например, с программным продуктом поставляются две книги: User Manual и Reference Guide. Они посвящены одному и тому же продукту. Вполне вероятно, что в них будут совпадать некоторые абзацы предложения.

Есть команда \include, есть Cut/Paste - это же текст.

> Вариант второй: выпускается новая версия продукта например 5.0. Перед этим была 4.0, к ней писала документация и от нее осталась translation memory. Используется на ура, на переводе экономится туча времени и денег.

Не понимаю? cvs/subversion? Это как код - можно вести разные ветки/сливать и тому подобное.

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

emacs + Путеводитель по пакетам LaTeX (переведён на многие языки в том числе и на русский) - годится для интегрированного решения? :) Если не хочется выдумывать, то есть масса рецептов на CTAN (примерно то же что CPAN, но для LaTeX). Уж интегрирования некуда - бери и используй. Или предполагается, что в продукте абсолютно всё предусмотрено и пользователю ничего больше сверх имеющихся возможностей не захочется? Это скорее фантастика.

> А в чём сложности? Напрягает пара секунд?

Оппа, я один это вижу? ;-)

>> Я как-то видел результат перевода docbook в твёрдую копию.

>Что вам мешает выполнить docbook2pdf и распечатать результат? :)

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

>> XML приходится прятать - значит общество открытых исходников по сути добровольно от этих исходников отказывается - нонсенс.

>Прятать в GUI и не отдавать вообще - разные вещи. При желании вы можете спокойно изменить docbook - он остаётся в системе.

То есть вещь в себе - как суслик, которого не видно но он есть. Только не понятно нафига он нужен.

> дай угодаю... из запроса HTTP взять инфу о языке юзер-агента??? ;)

Ну "угодал". Если я нахожусь в интернет-кафе во Франции, я от этого не начинаю читать по-французки. Не надо пробовать втыкать автоматизацию, там где это пока что нереально. Много ты коммерческих сайтов видел, которые предлагают язык, в зависимости от locale client-side'а?

Google? До тех пор пока ты ему не скажешь, что тебе нужен другой locale? Честно говоря, меня такое поведение напрягает, но это ИМХО.

А в основном, куда не посмотришь. Везде или список, или карта...

> За мастурбацию типа:

Ну не знаю, мне за это заплатили, а как ты это называешь это твое личное дело.

> пишется XML конфигурация

Конфигурацию пишет пользователь, а не я, ему для этого web GUI скоро будет дан.

> почему xml "для веба вообще сказка"

Я не web developer, но комбинация XML via XSLT -> HTML или WML в зависимости от user agent, в принципе, мне нравится. Одна модель, и разные views.

Даже когда-то баловался. Прижилось ли в коммерческом варианте не в курсе.

Я не говорю что это панацея, и так должны строится все web приложения, но есть места когда это весьма полезно.

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

>>Видать сильно прижала Tk, раз сделали ещё одну цель сборки.

Нет. Сильно фанатики "эмуляторов виндовс" достали. Потому в 2.6.x и сделали еще пару целей (никто не уйдет обидеженным), чтобы отвязаться.