(Yet another) XML pipeline language

Sylvain has been noticing the recent W3C activity in establishing a standard XML pipeline language. My first reaction has been “uhm?”, then I went to check what was that group up to and the result was more like “ouch”, “yikes” and “OMG” (add despair to the latest).

It strikes me how, in early 2006, people are still thinking that another XML domain-specific language is the way to go. We are all learning the hard way how the XML verbiage has been useless and, to some extents, detrimental: from Jelly onwards (and yes, I deserve some blame as well) it became crystal clear how programming in XML leads to unmaintainable, opaque and unreadable stuff. The fake myth that XML can be written by grandmas, coupled with the low entry barrier in creating new languages (no compiler’s compiler needed, yay!) has produced a plethora of half-baked solutions that just don’t get how grandmas aren’t going to code anyway, while angle brackets get heavily in the way of anyone who understands even just the basics of programming.

Now, don’t get me wrong: XML is great when properly used. That is, data (some grandmas might even write data at a certain point), information interchange and tool-oriented stuff. But please, pretty please, when talking about programming (that is, data processing and component connections), take those angle brackets out of the picture and give us the power of effective syntaxes. There might be some exceptions: transformation languages such as XSLT, having to deal with XML all the way, are consistently expressed in XML, but that’s not the case for XML pipelines.

Pipelines are about connecting, chaining, concatenating: there’s nothing there that needs XML to be expressed. It’s meta-XML, in a way, a side order to the main XML dish. What we (well, I at least) need are APIs: a standard and effective way to tie XML processing components together so that data manipulation can work in a multistage environment. We then need some machinery around it that provides transparent adapters between the different XML processing world (SAX, DOM, StAX) and we could definitely use some services (logging, management, security) on top of it. But we don’t need XML for that. We might want to use it at a later point, as a sort of wrapper around the pipeline language if, and only if, there is a clear need for tooling that could use a well-established and easy to parse data format, but please save our aging eyes and our carpal tunnels from angle brackets whenever possible.

Personal rule of thumb after a few years spent writing way too many XML languages: if you’re outside the context of an XML document (that is you’re not writing a template processor, basically) and you’re thinking about expressing control flow (if, switch, etc…) in XML, well, think again. Chances are you’ll end up with something like:

<my:test xmlns:my="http://keep/this/short">    
      <my:when condition="whatever">
         ...     
     </my:when>
     <my:otherwise>
         ....
     </my:otherwise>
</my:test>

for a whopping 177 characters compared to the following 43 (a 4x factor!):

if (whatever) {
    ...
} else {
    ...
}

Need to say more?

Comments

comments

1 thought on “(Yet another) XML pipeline language”

Comments are closed.