Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Tue, 26 Nov 2002 14:55:10 +0100
To: cocoon-dev@xml.apache.org, haul@informatik.tu-darmstadt.de
Subject: Re: [RT] Using pipeline as sitemap components (long)
Message-ID: <20021126135510.GC1110@bremen.dvs1.informatik.tu-darmstadt.de>
Reply-To: haul@informatik.tu-darmstadt.de
References: <3DDCAFEA.5050900@anyware-tech.com>
 <20021122104347.GB5273@tokyo.dvs1.informatik.tu-darmstadt.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021122104347.GB5273@tokyo.dvs1.informatik.tu-darmstadt.de>
User-Agent: Mutt/1.4i
Organization: Databases and Distributed Systems Group,
 Darmstadt University of Technology
From: Christian Haul <haul@dvs1.informatik.tu-darmstadt.de>

On 22.Nov.2002 -- 11:43 AM, Christian Haul wrote:
> On 21.Nov.2002 -- 11:05 AM, Sylvain Wallez wrote:
> > 
> > Q: I want do define a pipeline that will be used only as a 
> > transformation service. Why must I write a <map:generate> and a 
> > <map:serialize> in its definition ?
> > 
> > A: Because the sitemap, as a pipeline building language, must be able to 
> > determine the start of a pipeline and its end, even if not all its 
> > components are used. Like opening and closing braces in Java, the 
> > generator begins the pipeline definition and the serializer ends it.
> 
> We have the notion of pipelines in the sitemap. Today they are only
> used to get different error handlers. Maybe we should rethink this and
> use the map:pipeline as boundaries.
> 
> Another idea would be to place those pipelines acting as generator,
> transformer, serializer in the same part as we do with other
> components of that kind. Problem would be that they would need to use
> other components just introduced there.
> 
> A last thought: would it be necessary to have those pipelines match a
> pattern or would it be sufficiant to have them names?

Looks like my reply was too concise to be understandable. 
OK, next try:

Sylvain explained, that 

A) a generator is a component   that produces SAX events

B) a transformer is a component that consumes SAX events
                                 and produces SAX events

C) a serializer is a component  that consumes SAX events
                                 and produces a binary stream 

Now, I'd like to add

D) a reader is a component that      produces a binary stream

A "pipeline" could be any of these (according to the suggestion).   

To be more precise: Currently, a pipeline is only D). In conjunction
with the cocoon: protocol, we can have A) as well. A resource is a C)
while we can actually use it as B) as well because of a "bug" in 2.1
This comparison is a bit unfair as a resource for example is only
visible in the current sitemap.

But a pipeline is more: it is also a contract for the external URI
space.


Now, if we step back a little and look at the heart of things, why
would a pipeline need to be referenced by anything else than its name,
and why is a pipeline acting as a transformer placed anywhere else
than the map:transformers section?


This is probably a bit too radical and faces implementation
problems. OTOH, what about e.g.

<map:pipeline type="transformer" name="super_skin">
  <!-- ... -->
</map:pipeline>

in the "traditional" map:pipelines section. This could be turned into
a plain Avalon component filling the "transformer" role using the
short hand "super_skin".


Wait -- now, what about the external URI space? That would of course
need the present notation of pipeline. Without a type attribute, that
is. To use one of the new transformers, nothing chances:

<map:pipeline>
  <map:match pattern="*">
    <map:generate type="file" src="{1}.xml"/>
    <map:transform type="super_skin"/>
    <map:serialize type="xhtml"/>
  </map:match>
</map:pipeline>


I imagine that this could be done with only some tweaking of the
current implementation.


It would however, change the way we currently use the
map:pipelines/map:pipeline section in the sitemap. But there seems to
be little use of it anyways.


So, what about blocks? Blocks would need to provide a way to let other
block access components declared within. Interestingly enough, this
gets easier as we have to deal with fewer different concepts that need
to be visible outside: components, classes, URIs


Oh yes, textual replacement wouldn't do for this.


Does this relate to XSL named templates? No, I don't think it is
related in any way.


So, what do you think?


	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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