Recall my musings at HTML documentation system - design and planning. Although it would be much work to redo existing docs, upon starting a new project I thought I'd try the new system from the beginning.

So, I came up with a simple schema to get me started with capturing the necessary pieces of information. And here is a document that uses it.

So... now what? I want to process a body of XML documents and produce a body of HTML files that can be browsed as files (no server involved). Each document like the one shown will directly produce one or more HTML files, and contribute to at least two others (index, master contents, that kind of stuff).

I suppose I could pull out one of the Perl XML modules, load the thing in, and start writing code to do what I want. Spit out the whole docs, and remember stuff for the other docs and generate those after iterating over all input files.

But some people tout the XLS thing, and say it should basically do all this for me. Is that true, or will it fall down when I reach a certain level of complexity?

My immedate question is: what technology and approach should I take, to avoid blind alleys and excessive work?

I'd also love to see something presentable (a single readable HTML doc based on that input file) with minimal effort, so these files may be read now even before the fancy stuff is written.

Any clues?


In reply to XML documentation formatting and transformations by John M. Dlugosz

and:  <code> code here </code>