Tuesday, February 12, 2013

XML Prague 2013 Afterthought

An anniversary is supposed to be a happy occasion, but at some point you also tend to feel sad. You sense that when something reaches a certain age, it's also a step closer to death. Happy birthday dear XML.

However, if MicroXML will succeed XML (as proposed by Uche Ogbuji), then perhaps it means that ENQUIRE is going to replace the WWW. Some weeks ago I watched the unveiling of Nintendo 64, when we got all the cool games we still play today. Afterwards I wondered: how can it be Nintendo developed all this stuff back in '96, when I'm still struggling with namespaces? Happy birthday dear me.

I read Michael Kay's blog entry on MicroXML, and his concern for namespaces in XSLT. I understand this concern, but xquery doesn't seem to share this problem. Defining a module from a URI and mapping it to a local namespace is common practice, and recently found its way into JavaScript in the form of require.js, which sails under the flag of the Dojo Foundation. I don't see any problem with that, but I do see what terrible things can happen when you encode modules into your data. It's a bit like trying to draw Java depency management into RDBMS. It would have killed SQL instantly.

To continue musing on JavaScript some more, the require.js pattern was devised to solve the problem of how to download modules from the web asynchronously, and still be able to use them at the proper moment in the application. Although this is a typical requirement for web applications, it does add asynchronism to the stack. I wonder, what's Kay's approach to this in his XSLT for the client implementation? I know that eXist has a function in xquery that can spawn a new thread, and discussed the possibility for asynchronous functionality in xquery with Wolfgang Meier. It seems a lot can be gained from looking at node.js and the way synchronous versus multithreaded programming is handled there.

But perhaps by now the following question has risen: why asynchronous processing of XML, or perhaps at all? Well, lots of reasons really. Say I want to run batch jobs, and I'm certain my machine can take much more load, but is simply waiting to finish the thread. Or I send an http request and don't want to wait for a response. Sure, but why in xquery? Back to JavaScript again. The main problems I face with it on a day-to-day basis is that developers don't know or care about functional programming and immutable data. Moreover, they don't feel any need to write semantically sound code. And yes, we now have require.js and dojo patterns like deferreds and aspects, but JavaScript developers are still relying heavily on delegation, monkey patching and closures.

Another problem with JavaScript that struck me after listening to Juan Zacarias on JSONiq: it doesn't have a good querying interface for it's own bloody data model! Oh, that's right, it doesn't even have a data model ;-) how silly of me. It's just an in-memory construct of what was already available. Why not put it in a database and pretend it is a model and... ok I'll stop. The query interface in JavaScript was never properly fixed by jsonquery, but RQL is a much more solid attempt. Too bad the tla sucks, it does what it needs to do. One problem solved, but still a few to go. When I look at some code that I have to work with or extend upon in Dojo the hairs stand up on the back of my neck. And yet we all know it's the best toolkit out there...

Wouldn't it be more proper to have a client-side implementation of (asynchronous) xquery? Sorry, master, I mean no disrespect, but XSLT doesn't seem to do it for me. Not in this form anyway. Nor does ClojureScript by the way, with it's terseness and steep learning curve. I will leave you with an open question: what should the data model look like?



  1. Wouter have you seen XQiB?


    1. Yes sure. It's seem like a good start, albeit dependent on GWT. But to me it will only be usable if it takes in account the work on ADM and deferred functions.