On Jan 5, 2004, at 12:49 am, Roman Joost wrote:
3. I made the corresponding changes to the toolbox XML files and the stylesheets and added three new options:
a) The processor includes the titles up to section3. b) The processor chunks the documents up to section3 (Before, all the tools are displayed on one HTML page)
Do we really need section3s? Considering that it should be also possible
to have the whole documentation in one "book" this is really too deep as
we have <chapter>.<section1>.<section2>.<section3>. Additionally if you
look at the ToC as a tree you will that the weights are not naturally
spread because the depth varies a lot. Has anyone ever seen a distribution
like that? :)
As a rule of a thumb I normally tell that everything below sect2 needs a reconsideration of the structure.
5. I added some todos on my last mail (18. Dec). The todos are about not
yet written content and to add documents for the existing help ids.
Daniel pointed to a very cool book (thanks for that) with some
XInclude tricks. We've to create at least the docs for the help-ids,
as far as i know now. The only idea i have is: we can create a "big"
document with all the plugin names and information, which is of course
not yet written and include each section into the document.
The nice thing about xinclude is that one can rename ids on the go so one "not-yet-written" section can be included several times without having to be physically present several times.
6. The problem of the broken links, which are linking to glossary entries. I read a bit further in the book and found out, that <link> can only link to ids in the current document. The author points to "olinks" and creating an external database file for crossreferences between documents. I'll try this out, but it looks really scary ...
Olinks really are scary. They only make sense if you have a good way to automatically index all referenced documents which can be a lot of nasty work depending on where they reside.
What exactly is the problem with linking to glossary entries?
--
Servus,
Daniel