forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Atkin <>
Subject Re: [proposal] refactored markup help docs
Date Wed, 07 Aug 2002 22:57:45 GMT


> "tab" I presume? 

no, just a clump of page like the howto's, something like:-


or similar


> every element might perhaps overdo it 

yeah, i've thought similar but my reasoning is:-
- alphabetical menu listing provides better access then a document toc
- plenty of space for descriptions, examples via <source>s, proposed 
changes in next versions (as well as content model, attributes, parents) etc

must confess this is more than a little inspired by the docbook guides :-)


> feel free - even if it is hacky

firstly i did an Ant build-time approach, making typical forrest xdocs
- using multi-doc output in an xslt script, and using document() to load 
in hand written text
- this seems a total hack, not in the cocoon spirit at all

then i forced the thing into the sitemap processing, got following issues:-
- parsing full document dtdxflat file for menu & every element (is this 
cached? or is just the generator not recycled?)
- the book-cocoon & tab-cocoon dtd filenames conflict with the sitemap 
matching and i'm not up to speed with matchers to get round it
- hacked it using rough aggregation, but i'm thinking xinclude 
transformer might be better (any performance differences?)

now i'm thinking that whole point of these doctypes is that they change 
slowly and carefully - does this need to be dynamic after all?

seeing as the doctype issues are more political, i'll write them up 
after re-reading archives and raise one issue per mail, just one 
question first:-
- are any changes planned in near future (linking elements, xhtml 
refactor, etc)
- you've said main forrest aim is doctype version control, how will 
markup be changed? by in/formal vote?

when i've got something in a decent state i'll plonk it somewhere 
visible for folks to see what i'm on about

View raw message