|The stupid question is the question not asked|
HTML documentation system - design and planningby John M. Dlugosz (Monsignor)
|on Sep 08, 2001 at 02:05 UTC||Need Help??|
John M. Dlugosz has asked for the wisdom of the Perl Monks concerning the following question:
I have on-line documentation for a programming library, and it's showing its age. I want to update it, but I want to redesign the whole system of doing the docs.
Requirement: the entire doc set is a static group of HTML files, so it can be downloaded and browsed without a HTTP server.
However, I can have fancy stuff to generate the files from a more abstract description. That's what I'm thinking about: a Perl program to take docs that are easy to write and generate nicely formatted output and all the redundant stuff like tables of contents.
I wonder if POD gives me enough control? For each function, I want to list certain standard information such as the signatures, header file, and maybe others. Then my prose and code examples. It needs cross-references to other functions or parts of the documentation body.
Some portions though have other information I want formatted with the "formal" part, and that can vary. So... does each file need its own ability to customize the generated HTML in addition to starting from a central (and uniform) specification?
I might want to include a table or other HTML features, so a general escape mechanism is needed.
I want to use a simple markup that's not as hard to type as HTML.
Each specification file would generate one HTML file for all the functions described neatly formatted, another HTML file for the index, and contribute a line to a class index.
I'm wondering if people would want this body of info as XML, also. So maybe it should generate XML and have the browser format it?
Any suggestions, or pointers in the right direction? I don't want a mess, or a development effort that dwarfs the library being documented!