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] Using pipeline as sitemap components (long)
Date Sat, 23 Nov 2002 20:57:13 GMT
Gianugo Rabellino wrote:

>> This document defines this concept of "pipeline service", which, as we
>> will see, consists in using pipelines as sitemap components (generator,
>> transformer and serializer). It is separated from the blocks design
>> document since pipeline services can be used without blocks, even if
>> they will be mostly useful in that context.
>
>
>
> Interesting read, Sylvain (BTW: you should have told us that some guys 
> from your company were at Comdex :-) We met them yesterday at the 
> Cocoon BOF and I would have been most interested to meet them there... 
> anyway, kudos for the great job of putting Cocoon in such a small 
> device, definitely impressing).


Actually, I didn't even knew ApacheCon and Comdex where so close to each 
other :-/
I'm glad you liked this "Cocoon in unusual places" (see my Gent 
presentation for more on this)

> I have a some problems, though, with the whole concept. First of all I 
> hear FS bells all around, but I still have to focus more on the topic. 
> The secon problem is about extending pipeline syntax in such a radical 
> way: I think that this deserves a lot of thoughts about what might 
> come out from this change.
>
> The third and last one has to do with the specific syntax. What you 
> are labeling as a type="pipeline" attribute is actually the result of 
> a matcher (i.e. a "<map:match src="whatever">" tag). This might really 
> be confusing. But then again I can't think of a name that might really 
> make sense: using <map:transform match="whatever"> is even worse, so I 
> don't really see a solution here.


I think there is a misunderstanding here, related to the word 
"pipeline". The "src" attribute of these new components is a sitemap 
URI, just like in the "cocoon:" protocol. See my answer to Vadim for 
more about this.

> What I see here is actually expressing in an explicit way the fact 
> that when you are calling a resource via the cocoon protocol the 
> serializer is infact ignored and the two pipelines are infact somehow 
> "merged"... but I need to have more use scenarios where extending this 
> might turn out useful without falling into FS.


I easily admit that this set of new components can be considered FS in a 
single sitemap, in which the use of <map:resource> should be preferred 
to reuse sitemap snippets (but then using a different naming scheme).

> Can you shed some more light on that, with special regard to the whole 
> block concept? 


See my answer to Stefano's block version 1.1 [1] : blocks define their 
contracts by means of URIs handled by their respective sitemaps, but we 
need blocks to provide not only resources (don't like much this name to 
which I prefer "content"), but also services.

And these services, such as translating xdoc to html, producing PDF, 
etc. cannot be described simply by URIs producing content, but by URIs 
providing services such as generation, transformation and serialization.

Hence these new components.

Sylvain

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103627852716993&w=2

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }




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


Mime
View raw message