forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Atkin <ianat...@blueyonder.co.uk>
Subject Re: doctype questions
Date Thu, 25 Jul 2002 16:47:58 GMT
comments inline:-

Steven Noels wrote:

> Piroumian Konstantin wrote:
>
>>> From: Ian Atkin [mailto:ianatkin@blueyonder.co.uk] 
>>
>
>>> 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. 


so part of forrest is to ship with a tightly constrained markup, and to 
encourage user projects to use it - ok

question still remains that if someone doesn't like/know this markup can 
they still use forrest? looks like answer is no

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

again by only supporting one markup (document v11 et al) you are 
coercing, not persuading in the end

if someone wants to use forrest they *have* to use forrest doctypes, if 
someone wants to use different doctype (docbook or not) they can't use 
forrest

>
>
>>> - 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)?
>>
>
> 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 subset
>
> that is what we call 'convenience': we hope to be as non-intrusive as 
> possible while still providing some guidance & steering 

i'm having more of a go at these doctypes being the *only* ones, rather 
than the doctypes themselves (you'll get my opinions/suggestions once 
i've played with them a little)

i realise that many here like them, i'm not trying to change that

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

realise grief with xml schema, PSVI and so on - but what do you mean, 
"doesn't work"?

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

know very little about it, i've got work to do here then :-)

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

don't really know, not sure i like the idea either - just that i 
maintained a codebase that had this approach thought it might apply, 
probably doesn't

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

again we've got the *only one* markup problem. is that all there is to 
forrest then, a doctype and some xslt scripts? i don't think so, but i 
can't really fathom this almost rabid view of any non-document v11 markups

 it must be better for forrest to be able to process the docs people do 
write, rather coerce everyone into one 'approved' markup or convert 
their markups into it, however good the forrest folks believe it to be

for such a political framework as forrest will inevitably be, the spirit 
of compromise seems markedly absent

>
>
>>> does the "live" forrest have to be all dynamic or all static?
>>
>>
>>
>> It's static on xml.apache.org cause there is no running servlet 
>> container on
>> the host. Dynamic version is available at: http://krysalis.org .
>
>
> 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. 

yep, seen the commits - very handy

>
>
> HTH, 

it has

>
>
> </Steven>




Mime
View raw message