Написание документации.

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

Для написания xml куча тулсов, в том числе и прямо поддерживающих docbook типа XMLSpy, но и то в них какой-то бред - то нужно FOP доставить для генерации PDF, то русского не понимает для PDF, то xml-entities типа   xsl-конвертор заменяет на &#160. И при этом стиль для конвертации надо руками указывать - т.е. уже знать, что docbook это набор стилей. Ни разу не самоочевидно.
Есть набор консольных утилит для компиляции docbook во что попало - но и они примерно так же нещадно бредят, страшно зависят от пути куда их поставили.
Половина утилит требует Java неясных версий.
И главное - все это не собрано в единообразном виде на одной странице - стили на sourceforge, утилиты для обработки xml по инету разбросаны, книжка про docbook отдельно лежит, еще и в нескольких версиях - сразу и не поймешь, к какой версии что относится. Коммерческие утилиты с собой тащат свою версию стилей.

Как это называется? Высокий порог вхождения, крутая кривая обучения?

DocBook, продолжение банкета

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

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

Завел docbook

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

( Последовательность действий: )