cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: grammar-based pipeline configuration [Re: doctype questions]
Date Fri, 26 Jul 2002 10:25:26 GMT
Steven Noels wrote:

> Ian Atkin wrote:
> > Steven Noels wrote:
>>> 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
> I have been thinking about this since Cocoon1 time... the SoC enforced 
> using Cocoon2 meant that you didn't directly referred from a document 
> to its accompagnying stylesheet, but used a sitemap instead.
> Now this is very good practice etc... but this also means the grammar 
> against which your documents validate, is only used during document 
> creation, and cannot be used for confugation during generation/rendition.
> Imagine we want to support several document types (grammars, DTDs, 
> XSDs, you name it) with Forrest. A practical example of this is the 
> work Diana did once during some transition test from doc-v10 to 
> doc-v11. Another example might be supporting DocBook with Forrest. You 
> have a scenario where the routing of documents across the Cocoon 
> pipeline need to be done based on the type/class of the document, and 
> cannot be inferred from the environment (request/context/etc)
> We would have a situation like this:
> <map:match pattern="*.html">
>   <map:generate src="*.xml">
>   <map:match public-id="-//APACHE//DTD FAQ V1.1//EN" 
> type="doctypematcher">
>     <map:transform src="faq2document.xsl"/>
>   </map:match>
>   <map:match public-id="-//OASIS//DTD DocBook V3.1//EN" 
> type="doctypematcher">
>     <map:transform src="faq2document.xsl"/>
>   </map:match>
>   <map:call resource="skinit">
>     <map:parameter name="type" value="document2html"/>
>   </map:call>
> </map:match>
> This brings us to the wonderful world of Martin Fowler's Two Step View 
> Pattern (, setting the 
> interface (logical page) of Forrest to an XML document that complies 
> to the document-v11 dtd, but giving the authors a choice of authoring 
> formats (doc-v11 being one of them, too).
> In terms of implementation, this could be a pipeline configuration 
> component, a Matcher of Selector. It would require to 'parse' the XML 
> document upto a level it can detect its grammar (for DTDs the doctype 
> statement, for Schemas the xsi:SchemaLocation attribute, etc), 
> sufficiently cached etc...
> What do you think of this approach? What do Cocooners think of it?

This is a really good use case for "pipe-aware" selectors and matchers 
which were proposed some time a go. Stefano gave a (temporary ?) -1 to 
them because he wanted some time to understand the architectural 
implications of such things.

This led to a RT at to 
which I answered with "pipe-aware actions" at

But all this led nowhere as there were many other subjects of interest 
at that time (mainly flow and form handling).

IMO, it's time to tackle this problem seriously, as there are many use 
cases where pipeline construction is driven by what comes out from its 
beginning : your DTDs above, SOAP requests, XForm validations, etc.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message