A couple of weeks ago Simon St. Laurent (a well known XML guru) published The XQuery Chimera Takes Center Stage on XML.com. He highlighted the advantages a native XML based architecture has and how XQuery is coming along at the right time to enable it. in his words: "XML might actually finally change the Web significantly -- and soon".
In a case of convergent but independent thinking, earlier this year I posted The XQuery Chimera to start this blog and ponder what XQuery means for XML.
I couldn't agree more with Simon about the emergence of XQuery and it's place at the heart of content applications.
But I do wonder what this early mash-up (a Chimera is supposed to be a lion, a goat and a serpent each with its own head!) has to do with a query language for XML.
It's true, XQuery can be like a lot of different things. It is:
- Like SQL for Content. With XQuery you can directly access specific elements across XML documents in a way that is very analogous to accessing rows of data based on column values. This programmatic access to the structure of your content has vastly different results than SQL in that it returns XML nodes of content not rows of data (think of how different a result of book *chapters* is than a result-set of chapter meta-data like title, author, etc.)
- Like PL/SQL for Content Applications. Once the XML is returned XQuery has programmatic capabilities to allow you to manipulate the content further, use values in the returned content to perform additional queries and build the basic parts of a content application in XQuery. This is very similar to how PL/SQL stored procedures can be an integral part of an application. The primary difference is that PL/SQL is usually used to execute business logic (for instance: calculate state taxes on purchase orders) and XQuery is used for content logic (as in: find me the other books for each of the authors of each chapter)
- Llike Perl (and the like) for Content Manipulation. Finally XQuery has a very rich set of content manipulation features. Check out just the string functions and you will see that this is a serious too for content. Like Perl or Java you can use these functions to do just about any content function from executing display rules to complex text processing. But unlike these generic tools, with XQuery you are operating on the XML and the content at the same time and never have to 'recreate' or separately parse the XML. The oldest Perl example:
$msg = "hello world";
print qq^<h1 style="main">$msg</h1>^;
is now this:
let $msg := "hello world"
return
<h1 style="main">{$msg}</h1>
Using the XQuery node constructor, you are creating XML instead of working with a string representation.
It's been speculated that the mythical beasts were created to be powerful symbols. Ask around and you'll find most people - even the ones who haven't played Dungeons and Dragons - know what a Chimera is.
I will leave it to you to consider which part of XQuery maps to the Chimera parts (I vote Perl to be the serpent . . . but the goat??).
One thing, however, is certain: XQuery is sure to be memorable.
MT
Comments