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 12:35:25 GMT
Steven Noels wrote:

> Sylvain Wallez wrote:
>> Steven Noels wrote
>>> 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="docbook2document.xsl"/>
>>>   </map:match>
>>>   <map:call resource="skinit">
>>>     <map:parameter name="type" value="document2html"/>
>>>   </map:call>
>>> </map:match>
>> 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.
> Thanks Sylvain.
> While a reference to a grammar is effectively hidden *inside* a 
> document/SAX stream (on the LexicalHandler or ContentHandler level, 
> depending whether it is a DTD reference or an XSD SchemaLocation 
> attribute) - I interprete those as merily metadata to the document.
> I gather the proposed solution to this is suboptimal due to 
> DOM-dependency? Why consider an Action to be more appropriate for this 
> than a Matcher? 

Quoting my own post, which was about selectors and not matchers :
About separating the sensor and the valve by transmitting the 
information outside the pipeline, I consider it as introducing a 
"pipe-aware action". The main difference with a selector is that an 
action doesn't necessarily change the pipe flow, and can do anything it 
wants with the environment, including setting values used later by a 
selector. So in this sense, this fits the need and is more versatile.

Also, since a pipe-aware action would have only one input and one ouput, 
it would be easier to implement than a selector that has several 
outputs, meaning we can have more easily some smart-buffering 
implementations like mentioned above.

A matcher is less limited in its possible results than a selector (it 
can return sitemap variables), and the environmental data it has access 
to is not far from the one available to an action.

So the choice betwen action and matcher is a semantic matter : a matcher 
is supposed to perform a test, but not to change the system status. An 
action can also perform tests (hence behaving like a matcher), but can 
also modify the system status.

In your particular case, a matcher would be enough, but some use cases 
will require an action.

Note also that "modifying the system status" doesn't mean modifying the 
data flowing in the pipeline : this is the role of transformers.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

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

View raw message