Step By Step: Why XML Pipelines Make Sense

by Kurt Cagle

As usual, I've been busy the last couple of weeks, working mainly on a new JavaScript template library that I hope will simplify a lot of the pain of XML development, at least on Firefox. I've discovered the same truth that other JavaScript practitioners are coming to realize - if you stop thinking of JavaScript as Java, the language becomes far more flexible and capable - sometimes scarily so. I'll be posting this new template library to SourceForge shortly, along with the documentation for it and article here describing it, but until then ...

Norm Walsh recently provided an update about XProc - a generalized XML Pipeline language that is being worked on by the W3C. The idea behind XProc is simple enough - you create an XML document that provides "glue" or conditional bindings for difference processes that can occur in an application. One such "standard" project for such a language already exists - Ant - and I find it interesting that Ant has been slowly replacing the cryptic and awkward make syntax in an increasing number of applications, only a small portion of which are XML based.


M. David Peterson
2006-11-18 14:36:46
Nice overview! Methinks we may need to collaborate on building a prototype -- lets chat off-line about it.
Rich Salz
2006-11-19 08:22:18
SOAP and WS is not antithetical to pipelines. You could argue the SOAP processing model (actor/role) presages the current pipeline fad. WS and enterprise busses are making distributed pipelines real...
David Webber
2006-11-20 11:52:54
Kurt, good thoughts.

We'll have to see how the OASIS CAM technology plays into this in 2007 also. Seems like a natural fit at first blush - good mash-up toolkit?!? jCAM open source tool

Kurt Cagle
2006-11-20 12:21:58

I agree with your assertion (and probably need to rewrite that section a bit, because it is a little forceful). Actor/role SOAP processing (and SOAP as a general messaging protocol) works fine in a pipelining context - I just tend to have reservations about ad hoc client/server SOAP RPCs, because of their inherent fragility. I recognize that most modern day SOAP experts feel much the same way, but I also know that for many people SOAP still means RPC.

Pipelining and orchestration is macro-programming - utilizing the network as a generalized processor. I think we're really just beginning to enter the age where such macro-programming is feasible, and like every other software endeavor we've undertaken over the years, it will take time and experience to sort out what are the best protocols and methodologies, and it will also take a certain realization that once you shift from a largely private conversation between two nodes into a public (and ever shifting) conversation among many nodes in many potential configurations, that it necessitates a shift in perspective and abstraction. WS/SOAP is one key approach to this, and I think it has helped to highlight both the strengths and weaknesses of previous thinking on macro-programming, and will continue to gain presence in developing larger scale applications.

My question is whether that will translate into a corresponding change at the other end of the spectrum, the one currently occupied by RSS/Atom feeds and the fairly strong Fielding philosophies that seems to form the counterweight to SOAP. I see the emergence of two architectures at the network level, one marked by reliability at the expense of simplicity, the other marked by simplicity at the expense of reliability. Both are intrinsically necessary - the requirements of bank processing monetary transactions are VERY different from a political organization trying to communicate their message, for instance - and my suspicion is that we'll still be arguing the benefits of REST vs. SOAP (or its contemporary incarnation) in 2035.

-- Kurt

2007-09-21 12:12:46
"I’ll be posting this new template library to SourceForge shortly, along with the documentation for it and article here describing it"

Sounds good... Is this available yet?