Re: [RT] Cocoon Symmetry (short :)

[Ovidiu Predescu <ov...@cup.hp.com>]

On Fri, 8 Feb 2002 12:21:38 -0500, "Vadim Gritsenko" <va...@verizon.net> wrote:

> Hi all,
> 
> Preamble: I do remember we had talks about inward flows, etc... Then
> somebody (sorry, already forgot who it was) wrote about transformer
> which writes file as a side effect... Then Kinga proposes to add
> handlers reacting on input stream/documents... And recently I have got
> an idea that it should be quite an elegant way to handle all this if
> Cocoon is designed symmetrically: whatever abstractions we have to
> handle outgoing flow, let apply to the in-flow.
> 
> First of all, we already (almost) have symmetry in pipelines: generators
> are symmetrical to serializers. Generators are able to produce XML
> content out of almost anything we can think of: physical file, HTTP
> resource, SQL database, XMLDB database, incoming request, etc.
> Unfortunately, serializers are somewhat limited comparing to the
> generators: the only out option we have is output stream. Let's expand
> this to the other sources as well. Then we can have, say, file
> serializer. Coupled with the ability of Sources to handle input streams,
> one can save XML stream into file, XMLDB, and other sources were
> protocol handler exists.

This makes a lot of sense, although what you describe is more like a
pass-through transformer, which in the process has some side-effect
actions. I'm not sure the best name for it is a serializer, but I
don't have a better one.

> Second. Now Cocoon perfectly handles aggregation, both on sitemap level
> and using aggregated transformers. But what we have opposite to the
> aggregation? Nothing. Let's add separation notion: result will be
> several SAX streams. Every stream will have a destination pipeline. This
> pipeline will be retrieved by "separator", and generator of the pipeline
> will be replaced by the "separator" which will feed SAX events into this
> pipeline. As you see, it is same mechanism aggregator employs but
> reversed. 
> 
> Third. To top all this, symmetrical component is to be developed to the
> X/C Include transformers. As "separator", it will extract parts of the
> stream and send them to the other pipelines.
> 
> At last, let's consider an example. Let it be some request from the user
> to perform modification of the XML resource stored in the file (poor
> man's CMS ;)
> 
> [snip]
> 
> <!-- main -->
> <map:match src="update">
> <map:act type="validate-user-input">
>   <map:aggregate>
>     <map:part src="get-mods" element="mods"/>
>     <map:part src="get-data" element="data"/>
>   </map:aggregate>
>   <map:transform src="apply-mods--return-data-and-result.xsl"/>
>   <map:transform src="add-index-update.xsl"/>
>   <map:transform src="add-news-page-update.xsl"/>
>   <map:separate>
>     <map:part src="put-data" element="data"/>
>     <map:part src="update-index" element="index-update"/>
>     <map:part src="update-news" element="index-update"/>
>     <map:part src="update-result" element="result"/>
>   </map:separate>
> </map:act>
> </map:match>
> 
> [snip]

I agree with Sylvain's comment that the "src" attribute of map:part
should be called instead "dest".

What is the meaning of the "element" attribute? Can I extract any
element from the document using an XPath expression (a simplified one
may work too)? E.g. I'd like to be able to extract arbitrary elements
from the SAX stream, not only top level ones.

Regards,
-- 
Ovidiu Predescu <ov...@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

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

RE: [RT] Cocoon Symmetry (short :)

[Vadim Gritsenko <va...@verizon.net>]

> From: ovidiu@orion.rgv.hp.com [mailto:ovidiu@orion.rgv.hp.com] On
Behalf Of
> Ovidiu Predescu
> 
> On Fri, 8 Feb 2002 12:21:38 -0500, "Vadim Gritsenko"
> <va...@verizon.net> wrote:
> 
> > Hi all,
> >
> > Preamble: I do remember we had talks about inward flows, etc... Then
> > somebody (sorry, already forgot who it was) wrote about transformer
> > which writes file as a side effect... Then Kinga proposes to add
> > handlers reacting on input stream/documents... And recently I have
got
> > an idea that it should be quite an elegant way to handle all this if
> > Cocoon is designed symmetrically: whatever abstractions we have to
> > handle outgoing flow, let apply to the in-flow.
> >
> > First of all, we already (almost) have symmetry in pipelines:
generators
> > are symmetrical to serializers. Generators are able to produce XML
> > content out of almost anything we can think of: physical file, HTTP
> > resource, SQL database, XMLDB database, incoming request, etc.
> > Unfortunately, serializers are somewhat limited comparing to the
> > generators: the only out option we have is output stream. Let's
expand
> > this to the other sources as well. Then we can have, say, file
> > serializer. Coupled with the ability of Sources to handle input
streams,
> > one can save XML stream into file, XMLDB, and other sources were
> > protocol handler exists.
> 
> This makes a lot of sense, although what you describe is more like a
> pass-through transformer,

I do not mean: add second out to the serializer, I do mean: let's allow
serializer work not only on output stream, but also support other
destinations (and other destination will replace output stream).


> which in the process has some side-effect
> actions. I'm not sure the best name for it is a serializer, but I
> don't have a better one.

There is a difference: serializer does not have a (SAX stream) result.
Transformer always sends back SAX stream.


> > Second. Now Cocoon perfectly handles aggregation, both on sitemap
level
> > and using aggregated transformers. But what we have opposite to the
> > aggregation? Nothing. Let's add separation notion: result will be
> > several SAX streams. Every stream will have a destination pipeline.
This
> > pipeline will be retrieved by "separator", and generator of the
pipeline
> > will be replaced by the "separator" which will feed SAX events into
this
> > pipeline. As you see, it is same mechanism aggregator employs but
> > reversed.
> >
> > Third. To top all this, symmetrical component is to be developed to
the
> > X/C Include transformers. As "separator", it will extract parts of
the
> > stream and send them to the other pipelines.
> >
> > At last, let's consider an example. Let it be some request from the
user
> > to perform modification of the XML resource stored in the file (poor
> > man's CMS ;)
> >
> > [snip]
> >
> > <!-- main -->
> > <map:match src="update">
> > <map:act type="validate-user-input">
> >   <map:aggregate>
> >     <map:part src="get-mods" element="mods"/>
> >     <map:part src="get-data" element="data"/>
> >   </map:aggregate>
> >   <map:transform src="apply-mods--return-data-and-result.xsl"/>
> >   <map:transform src="add-index-update.xsl"/>
> >   <map:transform src="add-news-page-update.xsl"/>
> >   <map:separate>
> >     <map:part src="put-data" element="data"/>
> >     <map:part src="update-index" element="index-update"/>
> >     <map:part src="update-news" element="index-update"/>
> >     <map:part src="update-result" element="result"/>
> >   </map:separate>
> > </map:act>
> > </map:match>
> >
> > [snip]
> 
> I agree with Sylvain's comment that the "src" attribute of map:part
> should be called instead "dest".

It's a minor thing :)


> What is the meaning of the "element" attribute?

Same as for <map:aggregate>: once this element is reached, all SAX
events are forwarded to the corresponding pipeline (see also Kinga's
emails: there are some commonalities with Dispatcher).


> Can I extract any
> element from the document using an XPath expression (a simplified one
> may work too)?

As I mentioned: CExclude/XExclude (trying to come up with symmetrical
name for CInclude/XInclude) transformer may do this: once match is
found, forward stream to specified pipeline.


> E.g. I'd like to be able to extract arbitrary elements
> from the SAX stream, not only top level ones.

It is same as in aggregation: at sitemap level - only on root elements
level, at transformation level - works on any arbitrary element.


Vadim



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