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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
