http://norman.walsh.name/2008/07/02/xquery 11 49 2008-07-02T15:29:10-04:00 Norman Walsh 2008 Norman Walsh As XQuery, in the form of my first real work project, kept me busy over the past month or so, it seems logical to start blogging again with some lessons learned. What I said before still applies: I remain impressed with XQuery as a programming language for building web applications on top of a product like Mark Logic Server. I have a slightly odd relationship with XQuery because I was on the XSL Working Group when XPath 2.0, XSLT 2.0, and XQuery 1.0 were being defined. A lot of that work was done jointly, so I've seen a fair bit of XQuery go by, but I wasn't paying that much attention to the XQuery-only bits [Clearly! See below. -ed]. My first real work project was a proof-of-concept exercise. In broad strokes, I had to take collections of items from five or six different XML formats, present them reasonably well in several formats, provide a uniform search interface (full-text and by discrete facets) across all the formats, allow the user to select items and build a new document from those items, and provide some simple forms for adding new items or changing existing items. It's a few thousand lines of XQuery (and some JavaScript libraries, but that's another topic) and it works just they way I want it to. The requirements have shifted a little bit once or twice and XQuery proved quite agile. Which isn't to say without annoyance. First, there's the issue that Micah identified. Careless use of path expressions littered some of my HTML with random source elements. For most of them, I found a cast to xs:string sufficient. For others, as Jeni points out in her comment, you really do need to do the recursive function thing. And, well, there's that whole recursive-descent, walk the tree yourself, approach to converting from one XML vocabulary to another. That's just a drag. If XSLT has it and XQuery doesn't, XQuery is the weaker for it. Formatting dates and times, generating unique identifiers, grouping, who thought these were things you didn't need in XQuery? If you're familiar with variables in XSLT, it's tempting to think of the XQuery let statement as roughly analogous. So you write things like this: let $foo := some expression something[@class=$foo]|something-else[contains(@role,$foo)] And you discover that you've left out the return statement. Careful examination of the XQuery grammar will reveal that let is only allowed in a FLWOR expression, it's just that the for, where, and order by parts are optional. The return isn't. I kid you not. Speaking of the return statement, am I the only one routinely tempted to put it at the end of function bodies, where it doesn't belong? Yeah, maybe I am. Finally, there is a small corner of the XQuery specification which is deeply, fundamentally perverse. XQuery allows you to specify the default element namespace so that the bare element name “somename” in your query will be in the specified namespace. Unfortunately, doing that makes it impossible to write the name of an element that is not in a namespace. So the XQuery specification allows you to bind a prefix to the empty string: declare namespace l = "" You can then refer to elements in no namespace using that prefix, “l:someothername”. That is just wrong, wrong, wrong! I concede that within the context of XQuery, it works and is entirely consistent, but it still makes me want to barf on my shoes. The problem is that the element name “<l:someothername/>” in an actual XML document can never be in no namespace. So the XQuery syntax in this regard seems like a really bad compromise to my eyes. None of these problems can be fixed at this stage, but none of them are show-stoppers. They're just idiosyncratic. I know Perl, I can deal with idiosyncracy.