Sylvain Wallez wrote:
> >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.
Ok.
> <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.
Cool.
> <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.
All right.
> 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>.
Ok, great.
> I wish we could join in front of a whiteboard, this would be much easier :)
Ah, no kidding :)
> 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*.
Yes, this is correct.
> And the context
> of the two matchers above (assembled in a sitemap) *is different* from
> the context of each matcher considered separately.
:-? I don't get it...
> 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.
:-???
sorry, probably I'm stupid and slow, but I still don't get it: when it
finds a serializer the sitemap stops. I really don't see the problem
(but since I didn't implement all this stuff, you are seeing something
I'm not)
> 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.
I keep on not getting it: what is the difference between an explicit
information and an implicit one? The information on *what* to include
and what to overload is taken from the context and the context *is*
specified by where you place the <import> statement.
I'm sorry, but I really can't see your point.
> 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 ?
No, not really :/
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
