Hmmm... makes me think of XSL's document function....
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 15, 2003 1:53 PM
> To: [EMAIL PROTECTED]
>
>
> On Tuesday, Jul 15, 2003, at 15:40 America/Guayaquil, Tony Collen wrote:
>
> > More RTing:
> >
> > Imagine having an XSL processor in the kernel:
> >
> > You could "execute" .xsl files, bypassing having to run a processor
> > manually.
> >
> > prompt$ page2html.xsl < input.xml > output.html
> >
> > Borrowing the pipeline concept from Cocoon:
> >
> > prompt$ cat input.xml | page2foo.xsl | foo2bar.xsl | bar2html.xsl >
> > output.html
> >
> > One could even invent files which are actually transformation
> > pipelines -- ones which you might not be able to directly edit (or
> > maybe be able to edit a transformation in the middle):
> >
> > prompt$ make-virtual-file-pipeline virtual.xml --generator=input.xml
> > --tranformers=page2foo.xsl;foo2html.xsl --serialize=text/xml
> >
> > Now you can just go
> >
> > prompt$ cat virtual.xml
> >
> > And get the output of the pipeline defined above, which you can then
> > link to other pipelines, etc.
> >
> > It's no wonder that this all fits in very well with what Cocoon does,
> > since Cocoon is patterned after this concept. I'm sure if I stew on
> > this concept enough I'll come up with more ideas and uses.
>
> It might be a good mental exercise, but before you do, please remember
> that UNIX has no notion of structured pipelines as Cocoon does. That
> is, you will always need a serialization/parsing stage between
> different filters, which is instrinsically poor.
>
> Also, consider that there is no type safety since all components are
> the same (unlike in cocoon where you can't have a transformer after a
> serializer).
>
> So, keep in mind the differences.
>
> --
> Stefano.
