(Oops -- sorry about letting so much time sneak by since part 1 on this topic; I got detoured preparing for our Burton Group Catalyst conference next week and attending Microsoft TechEd last week, but the DMS team is committed to making this blog a sustained and regularly updated conversation on data-centric topics, so expect the post frequency to increase as we get into and beyond Catalyst.)
Part 1 on this topic concluded with a summary of ideal attributes for an XML query (general-purpose XML content manipulation, actually) language. XQuery does a great job of addressing those goals, and its role in the common XML processing pipeline is depicted below:
Specifically:
- XQuery is an efficient and effective means of working with information resources including databases, documents, and programming language data structures.
- It doesn't require developer brain transplants, but it is generally more accessible to people familiar with SQL than to people who have been working with content/document-focused systems in the past.
- XQuery has strong potential to replace the use of multiple programming languages often used for XML query and structural transformation operations. In this respect, it's a lot like the shift to SQL more than 20 years ago, in that a lot of difficult-to-maintain procedural code can be replaced with more a declarative, set-oriented (and easier to maintain) approach.
- XQuery is a W3C Recommendation, building on other W3C work including XPath (updated in conjunction with XQuery) and XML Schema (the XSD data type model, although XQuery is not exclusively tied to XSD), along with other related standards such as SQL.
- XQuery is not, despite its name, just for queries. It is an XML data manipulation language, designed for declarative expressions that can be optimized by servers, but it also includes variables, conditional expressions, function and modular declarations, and extension points. The W3C XQuery working group is also expanding XQuery to include insert, update, and delete operations.
- XQuery is not a replacement for SQL; it's designed to be used in conjunction with SQL, as the languages are designed for different data models -- SQL is for the extended relational model, and XQuery is for (ideally well-structured/schema-described) XML content.
Overall, XQuery has significant potential to simplify XML query and structural transformation concerns, and, as support for XQuery increases in a variety of software product categories, XQuery is poised to become, for XML content, what SQL is for relational databases.
Blogger: Peter O'Kelly
Comments