> 1) Any documentation generation change MUST be voted on ESPECIALLY when > it > alters the source code (xdocs).
exactly my prob with jakarta-site, this is. > * If it forces us to change our source code then -1. I don't care what > the > technology is, we had agreed a while ago to standardize on DocBook. > Anything > that is more presentation oriented than semantic oriented, I have to > veto. > > * Change the stylesheet not the source. There is a fundamental flaw in > thinking, > "Hmm, XYZ tool is so much faster, let me change my source code into a > mindnumbing > form of HTML so that I am roped into one way of representing my site > and never > allowing it to be changed." I am seriously against this. agree. > SO, if we use Anakia, change the templates to work with our source > instead of > change the source to work with anakia. Requirments for doc generation: 1 - full support for docbook source DTDs 2 - output readable in all popular browsers 3 - 99% maintainance free Wishlist for doc generation: a - error free b - fast c - smart (incremental recompile) d - useful error and debug messages Doc generation tools, with satisfied requirments and wishes between (): - our old cocoon (what berin put in and paul modified) (1,2,a,d) - our new cocoon (what nicola built) (1,2,d) - forrest (1,2,a,c,d) - maven (1,2,b,c) - anakia (3,b) - Xalan (1,2,a,b,c) - DVSL (1,2,a,b) - DocBook (1,2,3) the way I see it; we wait for either forrest or maven to satisfy #3 (ie a release) and in the meantime I'd like it best if the few error messages the new cocoon nicola put in places generates are removed, with the "old" skin put back in place. then again, I wonder whether there is any point in discussion if the outcome is ignored later on. - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
