norman.walsh.name: Comments on /2004/06/20/sxpipe http://norman.walsh.name/2004/06/20/sxpipe/comments.atom 2004-09-09T21:48:37Z Comment 0001 on /2004/06/20/sxpipe http://norman.walsh.name/2004/06/20/sxpipe#comment0001 2004-07-15T09:02:57Z 2004-07-15T09:02:57Z Frédéric Glorieux 49a41ff43f4aef7d179499ec41cc004fd9ffff19

Cocoon user from a long time, I'm completely agree with the pipe approach. I discover that with them, so that I thought it was their idea. I never notice [http://www.w3.org/TR/xml-pipeline/] before. So, it's Norman Walsh behind pipelines ?

You said : "I don’t have pointers to the sources yet. I expect that will resolve itself fairly quickly". Is it now resolved ? I would be glad to try my "sitemaps" under a lighter logic.

 Comment 0002 on /2004/06/20/sxpipe http://norman.walsh.name/2004/06/20/sxpipe#comment0002 2004-07-15T10:21:06Z 2004-07-15T10:21:06Z Robin Berjon c77b04531cc63dd8a41b45e320c224e4ede8d6f8

This is an interesting approach because of its simplicity, I don't think that a first pass at this problem should be much more complex than that (but a few little things may be added).

If you keep the <choose> feature, you might want to make it closer to SVG's <switch>. The basic difference is that instead of having a single 'skip' attributes, there are several test attributes that are a little bit more powerful (the latest draft adds to that with for instance the ability to test for support for various mime types, namespaces, etc. It's currently W3C member-only so email me if you want the link). But I would call that quite optional.

Another optional feature is the support for flagging a filter in the pipe as "last in chain". Both AxKit and Cocoon support this. It basically is a way of saying that the output from that filter will not be an Infoset, and can only happen at the very end of the transformation. It allows for stricter checking and clearer self-documenting pipelines. AxKit and Cocoon also have Providers, which are first-in-chain filters that are the kind that accepts non-XML input.

Another interesting feature is support for multiple Infoset representations. I'm generally happy with passing DOMs around, but in some cases it's really not what you want. AxKit will normally use DOMs as much as it possibly can (because it's faster) but items in the pipeline can prefer XML or SAX for instance, and they negotiate what they get with the previous filter (if negotiations fail the pipeline manager will convert for them). The big gain is that each filter uses whatever is best for itself. I believe that JAXP should make this trivial to implement.

Anyway, cool stuff! :)