forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <>
Subject Re: doctype questions
Date Thu, 25 Jul 2002 06:46:58 GMT
Piroumian Konstantin wrote:

>>From: Ian Atkin [] 

>>many doctypes from many projects, are forrest ones considered "gospel"
>>- a couple have 'cocoon' in their name, who "own" these 
>>forrest or cocoon?
> I suspect that cocoon files were added for migration purposes and they will
> be removed when v11 DTDs are finalized.

Indeed. That's why they are isolated into a separate directory.

>>- does forrest have to keep up with other projects, or the 
>>other way round?

One of the goals of Forrest is serious DTD change management. While 
other projects consider XML grammars a bare necessity, we believe DTDs 
are part of our deliverables. We actually enjoy working on these pesky 
things - can you imagine?

So yes, we believe people should refer to Forrest for 'reference' DTDs - 
and we try to keep our DTDs as lean & mean as possible, while adding 
relevant new elements/features upon request & evaluation.

>>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
> It's more a political question. We can't force anybody to use Forrest, but
> should provide enough good reasons to convience people to use Forrest.

better yet: people are invited to come over and tell us what they 
think... 'to convenience people' is really the way it should be explained

we're not the bragging type, if that is what you want ;-)

>>- couldn't forrest come with a few markups, one of which is 
>>or "approved"
>>- shouldn't users be allowed to use what they want (mainly 
>>thinking of 
>>non-apache uses of forrest here)?

the document/howto/faqs dtd is general enough to be used in a non-Apache 
context (we do, at last) - and still concise enough so that new people 
can learn the DTD in an hour or so - compare this with other grammars 
where nobody ever learns *all* the constructs and falls back to using a 

that is what we call 'convenience': we hope to be as non-intrusive as 
possible while still providing some guidance & steering

> Users can edit the sitemaps and customize the build for their needs. But why
> they would need Forrest in that case?
>>should it be possible to use different markup mechanisms?
>>- do we have to use doctypes for validity (they are crap after all)? 

crap that works, is well understood & well supported

>>what about xml schema, relax, xpath (eg schematron)?

xsd simply doesn't work, sorry - and you don't need its complexity for 
our little document-oriented purposes

relax might be a viable option and has a simple migration path coming 
from DTDs

> Look in mail archives, there were a long discussion on this. I hope that
> someday we'll use something better thatn DTDs.
>>- 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)

That is always possible, if one provides us with the necessary hooks so 
that we can still do our own job... how do you think this could be set up?

>>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

what kind of grammars do you want us to support? I'm not so sure whether 
Forrest is a viable option for people disliking our DTDs - but I'd be 
happy to review your options.

>>does the "live" forrest have to be all dynamic or all static?
> It's static on cause there is no running servlet container on
> the host. Dynamic version is available at: .

Both are static copies - Krysalis is updated each hour, however.   Once 
I have my new server set up, I'll be setting up a real live site, too.

In terms of deployment, Forrest sites can be deployed as both static or 
dynamic content - and when we finish the remote building, you don't need 
Forrest locally anymore to do so.


Steven Noels                  
Outerthought - Open Source, Java & XML Competence Support Center            

View raw message