On Wed, 2013-05-15 at 23:10 +0000, David Lee wrote: [...] > I boldly propose that perhaps as a group we step back and get off our > high horse and admit that some procedural aspects to XML processing > be embraced instead of hidden in the dark corners of "vendor > implementations" that every single vendor has had to provide because > pure functional programming has simply not lived up to its promise.
I don't think it's about a high horse. The XQuery WG spent multiple years trying to wrestle with adding procedural hooks to XQuery. Part of the difficulty was that it was a group of people who did not share a common goal. For example, some people thought it would be nice to offer a sort of bait-and-switch language where the easy stuff was procedural but anything hard was functional, a sort of gentle slope learning curve followed by a cliff, instead of a very steep hill at the start. Others needed synchronization and orchestration. My own feeling is still that the scripting extensions would work better as a framework rather like XProc, orchestrating functional chunks of XQuery (and/or XSLT) at a higher level, with clearly-defined boundaries for optimization & transactions. One problem with them as written today is that it's easy to put a semicolon instead of a comma in places where it's still legal, but has a different meaning, one which has the side-effect (!) of effectively disabling a lot of optimization. At any rate we ended up delaying XQuery 3 for a year or more while working on the scripting extensions, without really coming to a good consensus. Maybe the long term answer is XQuery extensions to JavaScript. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml _______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
