XQuery, the Server Language
Over the years, I've had the chance to program in a lot of different server-side scripting languages--C, Perl, ASP, JSP, PHP, ASP.NET, Python, Ruby, among others. It seems every few years that we programmers decide that we're bored with the current language and would like to try something new just to try something new. Admittedly, the sensibilities that come with the successes and limitations of preceding languages also tend to shape the new, so that each iteration tends to become, if not more successful, then certainly at least less unwieldy than its predecessors.
As an XML developer, one of the problems that I come across almost invariably within these languages is the fact that they are shaped by people who view XML as something of an afterthought, a small subset of the overall language that's intended to satisfy those strange people who think in angle brackets. However, one side effect of this viewpoint is that a rather disturbing amount of server code is still being written with HTML content (and often badly formed HTML at that) being written inline as successive lines of composed strings. For instance, it's not at all unusual to see inline PHP that looks something like:
$buf ="<html><head><title>".$myTitle; $buf += "</title><body>"; $buf += "<h1>This is a test.</h1>"; $buf += "<p>If this were an actual emergency, we'd be out of here by now."; echo $buf;
Not surprisingly, with this particular approach, your ability to create modular code is virtually nil, the likelihood that you as the developer of this particular page will spend many late hours trying to figure out why your table fails to render properly after the twelfth row (and causes the browser to crash after the 200th) is correspondingly high, and maintaining it after three months well nigh impossible.
This is perhaps one of the biggest benefits of working with XML, even though its not necessarily sold as such--an XML (or XHTML) document has its own internal integrity. You deal with XML at the level of the document, not the level of a string, and as such you can effectively abstract away the complications of creating markup content. Indeed, in a number of successful XML pipelines (such as the Apache Cocoon project), most if not all of the processing can take place through one XML operation (such as an XSLT transformation) or another, so that, in essence, your need to drop out of the XML world back into procedural languages drops off dramatically.
In February 2007, the XQuery specification became a formal W3C Recommendation, after nearly six years of development. As a language, XQuery can best be thought of as a way to turn the integrated language used to retrieve sets of nodes from an XML document, XPath, into a standalone language. To do so, XQuery adds a number of features--command and control structures (such as for expressions), the ability to create intermediate date variables (the let keyword), conditional handling (if/then/else), and the like to the XPath 2.0 language. Perhaps more significantly, however, XQuery also adds the ability to create modules consisting of collections of XQuery functions, and provides a way to subscribe to external functions within their own respective namespaces.
The original intent of the developers of XQuery was to use it, not surprisingly, as an XML-oriented query language. XQuery is not itself XML based (nor for that matter is XPath), but all of its operations are designed to work with XML documents or XML databases to provide a way of filtering or manipulating that XML to produce some form of output, most typically as XML or HTML.
Intriguingly, as a filter on XML, XQuery has seen only limited success. Part of this has to do with the fact that a significant number of the databases currently in use are SQL based, not XML based, so the benefits to gained by using an XML query filter are offset by the need to convert relational data into XML in the first place.
However, a few recent XML databases have taken XQuery to heart, and use it as the primary mechanism for accessing the XML database content. One in particular, the open source eXist project, has gone somewhat further, by inverting the normal sequence of working with XML where the XML object or data store is passed in as an object to the XQuery filter within the context of a server session. In the case of eXist, the various session objects--request, response, server, and so forth--are instead brought into the XQuery engine as externally defined XQuery methods.
In other words, in this situation, the server-side scripting
language is not PHP or ASP.NET or JSP, it's XQuery. In the particular
case of eXist, this all occurs in the context of a servlet hosted by
Jetty or Tomcat or some similar Java Servlet engine, but from the
standpoint of web development, this fact is immaterial. Instead, from
a development standpoint, your XML is all around you, you retrieve it
with document() or collection() methods, you manipulate the XML
directly within the XQuery, then you return the resulting content
(which may or may not be XML), remaining blissfully ignorant of
whether you are working JSP or ASP.NET.
