Another post in the series of key DMS topics for 2008; see this post for part 1 (topic: DBMS redux)
XQuery ("XQuery 1.0: An XML Query Language") is a W3C Recommendation for an XML content/data manipulation language. Burton Group's DMS team believes XQuery is going to become one of the most significant (transformational, if you'll excuse the pun) information management advances since SQL went mainstream in the 1980s, although XQuery is also something of a paradox in some respects.
Why XQuery is needed:
- Organizations are doing a lot more with XML these days, whether in XML data-centric domains such as inter-organization information exchanges (that might have been done in EDI, in the previous generation) or more document-oriented domains such as the use of ODF or OOXML for productivity application file formats.
- While the leading DBMSs are getting better at handling XML (as in full-fidelity XML data model management, rather than just "shredding" into relational tables or storing XML documents as blobs), SQL is not well-suited to address the somewhat idiosyncratic nature of XML -- hierarchy and sequence are fundamentally important to document-centric XML management, for instance, and SQL (indeed, the relational data model) was not designed to accommodate such document-centric concerns. XML usage patterns also vary considerably in the use of elements and attributes, another issue that does not map well to SQL.
- Many traditional content and document management systems use proprietary content manipulation languages for beyond-the-basics needs, sort of like how things were in the DBMS market more than 20 years ago, before SQL became the norm. Proprietary == badness in terms of vendor lock-in, higher training/admin costs, etc.
- XPath is useful for intra-XML document expressions, but it doesn't address more data-centric, multi-document XML usage scenarios; for that, we need something that is more analogous to the relational calculus approach embodied in SQL.
- Overall, along with explosive growth in XML information (content and/or data) management, there's a market need for something more powerful and succinct than today's common approach, which is often to use 7 +/- 2 programming/scripting languages (with lots of custom coding), SQL, XPath, and XSLT, in order to handle the common pipeline scenario depicted below:
- This also tends to get into ugly pair-wise "impedance mismatch" challenges, e.g., object/relational, object/XML, relational/XML, etc.
To recap, we need:
- An efficient and effective means of exploiting the best of all possible worlds -- data management, document/content management, and programming language data structure models (typically object orientation)
- With models and languages that don't require widespread brain transplants:
- There's no way to press the restart button on existing content, tools already deployed, organizations already entrenched...
- The industry needs a vast simplification (e.g., relative to SQL + XSLT + XPath + custom coding in a half-dozen programming languages, in many XML pipeline scenarios), but also more synergy -- a new gestalt...
- And of course it should all be done with a true industry standard, community-driven and open.
And that's where XQuery enters the picture -- more on that in part 2 of this post series.