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.
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 pipeline definition says it should do. Sorta like what Paul does to compile WSDL into a module.
I haven't read it yet, but Norm and Eve seem to be thinking about how the format should work. That makes the job much easier.
Re:Funny, that
barries on 2002-03-01T16:01:24
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 features, I'm considering a XMLMaker machine that would encompass/mimic most of the make-like dependancy solving functionality of "pipelines" as I understand them, and an AutoCache machine to allow the SAX events that float between SAX processors to act a lot like make(1) targets.
Re:Funny, that
ziggy on 2002-03-01T16:12:49
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.
Re:Funny, that
Matts on 2002-03-01T16:25:44
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).Re:Funny, that
barries on 2002-03-01T17:44:39
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::RecordSet for SAX, perhaps.
Re:Funny, that
barries on 2002-03-01T17:54:08
Kip points out Matt's XML::Generator::DBI module:). So ziggy, when did you say you were going to CPAN XML::Handler::DBI? ;)
