On 1/1/06, Michael Wechner <[EMAIL PROTECTED]> wrote: > > > >I'm not that much interested into yet another DSL expressed in XML, > >and I don't feel alone at all. Actually I'd much rather drift towards > >a programmatic pipeline API. > > > > what do you mean by a programmatic pipeline API?
Uhm, part of the story is on my blog[1] but I'll give you an excerpt and save you a click ;-) 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. [1] http://www.rabellino.it/blog/?p=117 -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
