Computer? ... Yes, Dear... XQuery and XML Databases
Every era in computing has defined its own paradigms for reading and updating data. If you're reading a relational database to convert into XML then sending XML up to the server and spending time with DOM converting it into SQL, XQuery is for you. XQuery is a lightweight (and non-XML) language for manipulating XML based in large part on the XPath 2.0 specifications that are going gold this month.

I've written two books and perhaps a dozen articles and blog postings on XQuery. They were, admittedly, too far ahead of the curve ­ the specification for an XML-oriented query language has been underway since before 2000 and even today the formal specification strictly handles only the query (not the update) side of data management. However, one of the most interesting facets of XML databases has been the fact that a number of different mechanisms for handling updates have been tried, and the most elegant of them seem to tie into the notion of performing such updates in the same query space as used for getting XML requests in the first place.

I think it's fair to talk about XQuery and XML databases in the same breath. The two are fundamentally tied together, and are further tied to the notion of data provider abstraction. A significant amount of the work involved in putting together a Web application of any complexity involves a translation layer to communicate between the database and the Web client. For the most part, such middle-tier services involve using some sort of data abstraction service such as ODBC, ADO, Spring, etc. to read from or write to specific fields in a database, typically using a language such as C# or PHP to handle this work.

Unfortunately, such code is remarkably fragile, is very verbose, always deals with information at the atomic level even when the information may be coming in (or needs to be produced) at a more abstract aggregate level, and all too often is spread out over several different functions or Web Services, making maintenance costly and cumbersome. XQuery shifts the processing of such queries (and potentially updates as well) out of the server language and into XQuery scripts.

XML databases are becoming both fast and robust, and there are some interesting update extensions proposed (and integrated into open source projects such as HYPERLINK "http://exist.sourceforge.net/" \t "_top" eXist and HYPERLINK "http://www.sleepycat.com/products/bdbxml.html" \t "_top" Sleepy Cat XML Database) that handle the update side of XML data query in a clean and seamless way. From personal experience, such databases can cut your development time significantly in the Web application space.

The Flux in Matter/Anti-Matter Converters XSLT and Transformations
XSLT is old hat in the XML world, but it's becoming a major part of both the client and server side of AJAX programming because most browsers now support some form of XSLT processor. For those that don't (and as a means of consolidating the slight variety in existing XSLT APIs) Google has released the HYPERLINK "http://sarissa.sourceforge.net" \t "_top" Sarissa XSLT Processor that provides JavaScript-based XSLT support (and that invokes native processors when available for performance).

XSLT in the hands of a good programmer is a wonder tool, especially if you can use XSLT 2.0, which goes gold this month as well ­ it provides a means to provide exhaustive transformations from one form of XML into another, can read from multiple XML streams and produce multiple forms of output, can be easily subclassed to handle variations in formats, and works incredibly well even in bindings (which I'll talk about shortly).

One additional facet of eXist that I like is the ability to perform XSLT transformations from within an XQuery and then continue processing the results in the same query (including passing the transformation onto a conditional pipeline of other transformations). I can't stress enough how important XSLT is even now, and how it will perhaps be the dominant mechanism for manipulating XML in the future.

Out of Space-Dock The Move to XHTML
The distinction may seem minor ­ XHTML is, for the most part, simply an expression of HTML using XML rules rather than the older SGML rules ­ but the effects are profound. By shifting to XHTML, you gain all the manipulative tools of XML, including the ability to create arbitrary tags that can be transformed or otherwise bound, the ability to incorporate other namespaces (from the graphically oriented SVG to MathML to RDF for metadata to Xforms), and the means to validate such XHTML content quickly and easily.

What's more, you can incorporate XHTML fragments into transport formats such as Atom, or as secondary documentation in many other formats. Finally, even browsers that don't formally recognize XHTML (such as Internet Explorer) can still take XHTML as valid HTML with a minor change in the response header.

Plotting a Course for Rigel 7 XForms and Schema-Driven Programming
As a technology evangelist, one of the things that I have to be very sensitive to is to recognize those technologies that are still in their infancy but that have the potential to be much more. XForms definitely fits into this category. XForms, another W3C standard, originally was started to create a somewhat more robust set of controls for the Web that could take advantage of the newly emergent XML standard.

One of the first things that came from this was the realization that such components were ultimately mechanisms for handling data-binding (assuming, as has proved prescient, that XML would likely be the ultimate expression of that data). This in turn implied the existence of a data-model, and by extension a control/binding layer that serves to both map content to the controls and constrain what the content can be.

What emerged from this effort was the XForms standard, which was released as a 1.0 standard in 2003 and is scheduled to be released in 1.1 form later this year, designed to handle use cases and ambiguities that arose with the original specification. This specification includes supports for a number of features:

• XPath Mapping: All components are populated either directly or indirectly using XPath expressions.
• New Form Elements: Including
  and (slider) components
• Repeating Component Groups and Contextual Toggles: Making it possible to generate repeating tables, wizards, and similar components.
• Add/Delete Capability: Items (and complete substructures) can be added or removed from the data model using components without an explicit need for imperative code.
• Auto-updating via XML: The XForms data-model will, on submission, post the relevant portions of the data model as XML to the server automatically without losing the page state.
• Constraint Modelling: Constraints are applied to the data model, not the components, though the reaction of components to changes in the value or validity of the model can change the UI.
• Abstract Component Model: XForms components are abstract, and are intended to be subclassed or otherwise bound via some form of presentation layer. All implementations provide default bindings, of course, but the XForm should ultimately be "skinnable."

XForms implementations have been around for a couple of years, with a number of different approaches being taken. Solutions such as IBM's Workplace Forms (formerly PureEdge) and x-port's FormsPlayer are standalone solutions existing in a separate (albeit embeddable) application space from the normal browser. Orbeon is an open source AJAX implementation, while the Mozilla Foundation is creating an XForms extension that should be natively installed with Mozilla Firefox 3.0.

While there are other XML aspects that play a part in the SOA/AJAX space, ultimately they are all moving towards a form of application in which the data (moving around typically as XML, or in the case of lighter-weight messaging as JSON) moves from point to point in a distributed network, one where the client becomes far more important, and where the same client architecture is likely to be rendered on-the-fly in response to a state contained in the user profile and experience.