forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Atkin <>
Subject doctype questions
Date Wed, 24 Jul 2002 16:49:03 GMT
  no docbook/document flame war please, i've scanned some of the 
archived threads and am just trying to fathom what's going on

i've got an idea forming but i need some answers before it's 

many doctypes from many projects, are forrest ones considered "gospel"
- a couple have 'cocoon' in their name, who "own" these forrest or cocoon?
- does forrest have to keep up with other projects, or the other way round?

should user's of forrest be forced into using <document> et al?
- if users are to have no other option than what forrest provides, i'd 
want a damn good reason if I was them
- couldn't forrest come with a few markups, one of which is "prefered" 
or "approved"
- shouldn't users be allowed to use what they want (mainly thinking of 
non-apache uses of forrest here)?

should it be possible to use different markup mechanisms?
- do we have to use doctypes for validity (they are crap after all)? 
what about xml schema, relax, xpath (eg schematron)?
- is there any benefit in splitting "author-time" validity from "build 
time" validity, as in documenters use what they like when they write, 
but forrest uses it's "prefered" mechanisms when it runs (dynamic or static)

should different documents within a project/site be allowed to use 
different doctypes or should they all use the same one?
- would make contrib of authors with different preferences much easier
- processing would leap in complexity, but that may be a cheap price 
considering a happy family as a result

does forrest sitemap have to be monolithic?
- i know about cocoon's sub-sitemap feature, want to know if there's 
good reason not to use it
- the mapping of xml file to xslt script occurs here
- can do stuff without affecting existing sitemap but it will be an ugly 

does the "live" forrest have to be all dynamic or all static?
- mainly thinking of pure docbook generation, which may always be too 
much for java-based xslt (i've recently started using xsltproc due to 
the speed grief of large docs)

View raw message