cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] reconsidering pipeline semantics
Date Sun, 07 Jul 2002 21:34:18 GMT
Stefano Mazzocchi wrote:

>Sylvain Wallez wrote:
>  
>
<snip/>

>>Isn't the regular URI-matching enough that you need an additional naming
>>scheme ?
>>    
>>
>
>No, probably not, but in that case, we need another pipeline state.
>
> - [no attribute] -> similar to java 'public'
> - internal-only="true" -> similar to java 'private'
> - ?? -> similar to java 'protected'
>
>where the pipeline is accessible from the inside and from other blocks,
>but not exposed to the public URI space.
>
>Unfortunately, this requires a different attribute, something like
>
> <pipeline exposure="(public|internal|block)">
>  
>

Interesting thought. Let's keep it for when we will discuss the 
security-related topics of block.

<snip/>

>For example, we could have done:
>
> <map:generate type="aggregate">
>
>instead of
> 
> <map:aggregate ...>
>
>but than we would have left the user the ability to 'remove'
>functionality from the sitemap.
>
>This is why I prefer to encode proper sitemap functionality in its
>semantics, even if, implementation-wise, it would be equivalent to reuse
>the existing component infrastructure.
>
>Do you see my point?
>  
>

Yes, and I agree : visible semantic is better than a magical 
implementation of another one.

<snip/>

>Admittedly, this very random thinking, but at least it will trigger
>something in your synapses (hopefully :)
>  
>

Yes ! But what it triggered isn't exactly what you may have been waiting 
for : I'm pretty sure now we both have the same understanding of this 
pipeline inheritance and overloading stuff, but each of us re-used 
existing but different terms with their associated meanings, leading to 
this confusion.

However, you still did not catch what I want to explain. Let's give it 
another try with your new <import>, which has no previous history, 
unlike <call> or <transform>.

I wish we could join in front of a whiteboard, this would be much easier :)

What I (desperately ;) try to show you is that <import> without 
explicitly saying what is to be imported from the target pipeline is 
sometimes ambiguous in a _real_ sitemap, containing several matchers 
building several different pipelines.

Let's consider a skin pipeline that renders an xdoc as an html page. 
This pipeline requires a "doc" parameter which should be passed by the 
caller (let's not argue about argument passing, as this is yet another 
problem!) :
<pipeline name="doc2html">
  <generate src="{doc}.xml"/>
  <transform src="doc2html.xsl"/>
  <serialize type="html"/>
</pipeline>

Now let's consider the typical doc generation statements :
<match pattern="*.html">
  <import name="doc2html">
    <parameter name="doc" value="{1}"/>
  </import>
</match>

No problem here : we import the full "doc2html" pipeline.

Now, let's consider the case of the FAQ which has a special DTD :
<match pattern="faq.html">
  <generate src="faq.xml"/>
  <transform src="faq2doc.xsl"/>
  <import name="doc2html">
    <parameter name="doc" value="dummy"/>
  </import>
</match>

We generate our FAQ, transform it into an xdoc and import the 
transformation and serialization of doc2html. The "doc" parameter, used 
by the generator, is actually useless and could even have been avoided.

Now let's assemble all this in a sitemap : the internal "doc2html" and 
the externally visible pipeline, with "faq.html" matcher first, since it 
is more specific than "*.html" :
<sitemap>
  <pipeline name="doc2html">
    <generate src="{doc}.xml"/>
    <transform src="doc2html.xsl"/>
    <serialize type="html"/>
  </pipeline>

  <pipeline>
    <match pattern="faq.html">
      <generate src="faq.xml"/>
      <transform src="faq2doc.xsl"/>
      <import name="doc2html">
        <parameter name="doc" value="dummy"/>
      </import>
    </match>

    <match pattern="*.html">
      <import name="doc2html">
        <parameter name="doc" value="{1}"/>
      </import>
    </match>
  </pipeline>

</sitemap>

And here comes the ambiguity that I desperately try to show you : in the 
current sitemap syntax, <serialize> marks the end of the pipeline 
construction, and consequently the end of the processing of sitemap 
statements.

<import>, on the contrary, can be considered as a generator, a 
transformer or a serializer *depending on the context*. And the context 
of the two matchers above (assembled in a sitemap) *is different* from 
the context of each matcher considered separately.

So when we end the <match> for "faq.html", how can we know if pipeline 
construction is finished (with the serializer of "doc2html") or if it 
should continue with the following statements ? The answer is : we 
cannot know.

And worse, if we continue evaluating statements, the second match 
("*.html") matches, and we encounter another <import>. What happens here 
? Since the pipeline being built already has a generator, will we append 
(a second time) the transformer part of "doc2html" ?

That's why I say a more explicit semantic is required. The calling 
pipeline *must* explicitly say what is to be included and what is to be 
overloaded in the called pipeline. Consider the same sitemap with just 
an additional "what" attribute to <import> :

<sitemap>
  <pipeline name="doc2html">
    <generate src="{doc}.xml"/>
    <transform src="doc2html.xsl"/>
    <serialize type="html"/>
  </pipeline>

  <pipeline>
    <match pattern="faq.html">
      <generate src="faq.xml"/>
      <transform src="faq2doc.xsl"/>
      <import name="doc2html" what="transform, serialize">
        <parameter name="doc" value="dummy"/>
      </import>
    </match>

    <match pattern="*.html">
      <import name="doc2html" what="all">
        <parameter name="doc" value="{1}"/>
      </import>
    </match>
  </pipeline>
</sitemap>

I don't pretend this notation is nice, but it carries the required 
information : this simple attribute has removed all ambiguities, and we 
are able to know exactly what will happen.

Has this triggered something in your synapses ?

;-)

Sylvain

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message