XQuery ... almost
W3C just announced XSLT 2.0, XML Query and XPath 2.0 Candidate Recommendations. I remember, back in 2000, betting on when XQuery would ship. None of us expected that it still would not be a finalized reality in 2006! XML was supposed to be simple! Any XML spec that takes that long to finish should be walked away from. Cut your losses and run!
Don't get me wrong, XQuery is chock-a-block full of amazing ideas. So toss out some of the decisions that made it take 7 years to produce a query language which doesn't even include update! XPath had its problems, but the spec was just a few pages. XPath was too simple, and all the database vendors wanted a query language that fit their existing models... so they designed a language that requires man-decades of development to implement!
Given that we are still figuring out what a semi-structured database really is, and how XML fits into the big picture, why is the W3C asking us to commit to such a juggernaught? And can someone please fix the type-system? The XML-Schema data-types is bad enough for text-validation, but as the type-system behind a programming language it is a colossal mistake.
Don't get me wrong, XQuery is chock-a-block full of amazing ideas. So toss out some of the decisions that made it take 7 years to produce a query language which doesn't even include update! XPath had its problems, but the spec was just a few pages. XPath was too simple, and all the database vendors wanted a query language that fit their existing models... so they designed a language that requires man-decades of development to implement!
Given that we are still figuring out what a semi-structured database really is, and how XML fits into the big picture, why is the W3C asking us to commit to such a juggernaught? And can someone please fix the type-system? The XML-Schema data-types is bad enough for text-validation, but as the type-system behind a programming language it is a colossal mistake.
posted by derek at 1:27 PM
2 Comments:
I think the basic problem causing XQuery delays is the fact that they essentially had to reinvent a complete programming language. Most of the spec bugs and discussions since I've been involved have more to do with general language design (e.g. casting from one type to another, how to handle URIs and namespaces given the differences from how XML treats them and how other programming languages treat them).
In my very humble opinion, XLinq borrows the "amazing" ideas, grafts them onto .NET rather than reinventing the whole framework, and ends up being essentially a superset of "XQuery the Programming Language" with vastly less effort. We'll just have to see how much of XQuery the Programming Language ends up in XQuery as it is actually used by real people in real DBMS. Probably about what was in the spec in 2001 [duck]
LOL. XQuery is a disaster, and everyone knows it.
At best it'll wind up like SQL -- every vendor will implement something slightly different [Hello XLinq], with all sorts of vendor-specific keywords and maddening differences in type definitions. At worst it'll go the way of Haskell, something for research papers and books. Not that I would know anything about XQuery books. :-)
XSLT+JScript is "good enough" for 99.99% of all XML transformation scenarios. And in the remaining .01%, people write their own custom "parser," extract the info they need, and do the rest in code. Eventually, some brilliant hacker out there will riff on this and come up with a new language that fixes the few annoyances of XSLT+JScript and call it a day.
Choosing XQuery over -- well, any other tool -- is like choosing the lambda calculus over AJAX.
Post a Comment
<< Home