Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

darobin (1316)

darobin
  (email not shown publicly)
http://berjon.com/

Journal of darobin (1316)

Friday March 01, 2002
10:18 AM

More Pipelines, More XML

[ #3221 ]

All that great family of people interested in pipelines might be interested in this new W3C Note. It's just a Note (ie early alpha) and looks like it has a few faults, but I think it's interesting.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I just got finished flipping through Sean McGrath's XPipe slides [sourceforge.net] on the train the other day. It's a bit high in the clouds, but it does give a good overview of pipelining, rigs and such.

    It got me thinking that what we really need is an XML format for declaring pipelines, so that XML::Pipeline->create can instantiate all of the code needed to do the work, without actually writing Perl code. Alternatively, XML::Pipeline->compile could take an XML description and produce a module that does what the p

    • I've got XML::SAX::Machines emitting descriptions as XML and am planning to add the "build a machine from XML" part when I need it or at least get the time to.

      A couple of major differences between X::S::M and the XPipe stuff are that XPipe seems to be a specialized make/ant thing and that it's a lot higher level than X::S::M. X::S::M is meant to make it easy to connect and manage SAX processors, while XPipe wants to manage the overall transformation process.

      I'd like to see X::S::M grow some XPipe like

      • From the little I understand about XPipe, it extends way beyond SAX filters.

        For example, I'd expect XPipe to handle the case where data is coming in from DBI and into a SAX head conversion, passing through some filters, being converted into a DOM tree, munged and then ferried through an XSLT transform, to be re-serialized as SAX events to be filtered again and output thorough a tail conversion into another DBI connection.

        I think.

        • Nothing there SAX can't do...

          We're also looking at optimisations so that pseudo-SAX modules that have to serialise to a DOM can connect to each other directly by passing DOM trees, and bypass the SAX part (though still provide SAX for modules that don't grok DOM).
        • I'd expect XML::SAX::Machines to handle that case too :). Either way would require custom SAX generator and handler modules (Java for XPipe, Perl for X::S::M) to do the DBI queries and we have XML::Filter::XSLT handy.

          It does seems like XML::Generator::FromDBI and XML::Handler::ToDBI would be handy modules. I've written SAX modules before that store and retrieve XML as event lists (with unnecessary events omitted on store and recreated on retreival), so I know it's not too difficult. Kind of like a DBIx