InPlace: правильная CMS для разработчиков

Спасибо, поблевал!

А TeX, что уже не устраивает?

>> XSLT, как и всё, связанное с XML - избыточно сложная и тяжёлая технология

>К сожалению, лучше XSLT пока ещё ничего не придумали.

XQuery и STX придумали давно. Разница только в том, что STX пока не стандарт, а XQuery мало распостранён и рекомендуется почемуто только для применения в СУБД.

А вообще идея не новая и довольно распостранённая. Сам делал несколько таких конверторов.

Сейчас задумал написать конвертор своего XML описания пользовательских интерфейсов в *.ui для Qt и в HTML аналогичного вида.

Мой опыт использования систем документирования в нашей фирме:

1. Когда возник отдел документирования, новый прогрессивный его руководитель надеялся что все будут использовать docbook. Как для внутренней так и для внешней документации.

Это конечно гораздо лучше чем то что творилось раньше в основном все в word...

Но писало только два человека из всей фирмы. Нач отдела документирования и я (SW/HW архитектор).

Я пытался честно использовать docbook для внутренней документации, перевел все документы с tex, latex, lyx на этот "гребаный" docbook, научился конвертить это через tex (а не FO т.к. FO шный выход выглядит ну супер убого) в pdf, rtf, webhelp, man, html, text, ... векторные картинки по прежнему из xfig.

2. Потом открыл для себя Tiki Wiki с тех пор вся внутренняя документация а также feature tracking, workflow, etc только на нем. В отличии от docbook у нас Wiki пользуется 100% тех кто 1 раз попробовал написать в нем документацию. docbook использует только техпис. и только для внешней документации.
---------------------------------------------------------------------
Мои выводы на основании 7 летнего опыта документирования:
1. Для внешней документации к сожелению альтернативы docbook нет и не предвидится. Связано это в основном с возможностью конвертации в разные форматы, гибкого управления контентом и "простотой интеграции внешнего контента". (XML к сожелению супер не удобен в использовании в смыле что все делается ужасно медленно и со страшным гемором. Спасает лишь то что обычно требуется два три шаблона действий которые хоть и через гемор но автоматизируются)

2. Для внутренней документации Wiki (групповая работа над документами публикация) + Doxygen(Дока из исходников) + Удобная векторная графика (SVG/XFIG)

Теперь о бенчмарках:
1. Перевод всего написанного мной из tex, latex, lyx, txt в docbook занял 1 год моего времени и времени нач отдела документирования. (сюда входит автоматизация конвертации/публикации/управления документами)

2. Перевод всего написанного в Docbook на Wiki занял у меня ~5дней.
Почуствуйте разницу:
1 год и вечный гемор vs 5 дней и счастье.

Скорость написания документации в TikiWiki почти такая же как и в tex/latex/lyx. что минимум на порядок быстрее и удобнее чем docbook, не говоря уж о usability: whiteboards, 9 видов textual diffs, доступности, почти полным отсутствием проблемм при merge документации, легкой обучаемости персонала, возможность экспорта в docbook, pdf, rtf, webhelp, html, ....

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