bestkungfu weblog

XML is not a relational database, so using existing relational approaches doesn’t always apply. In moving relational data to XML via SQL and the DOM, you write a lot of uninteresting code. Robie goes over three approaches:

Code it yourself

It’s portable, but sucks to write.

XML/SQL

SQL 2003 includes a set called SQL/XML that is easy to use for existing SQL programmers. It also includes a set of SQL functions to bridge relational data to XML. Support is available for DB2 and Oracle, and an independent implementation is available from DataDirect.

Native XML programming

XML is fundamentally hierarchical; object-oriented systems are fundamentally graph-oriented. It’s also more than just text, but a description of relationships of data. Native XML programming abstracts away the issues with parsing, etc. XSLT, XQuery, etc., are among those things he considers to be native.

Robie offers a fourth way:

XQuery for Java

The “JDBC for XQuery” is XQuery for Java. It doesn’t exist yet. Robie’s company has submitted a proposal under the Sun Java Community Process to meet this need. It needs to deal with relational and XML data equally, but ultimately must be XML-centric.

Question (well, hypothesis) from the audience: “Logical progression that says that XSLT should go away.” Robie says, “Not necessarily,” and notes that there are some applications where XSLT is just easier to do. XSLT will be used for design, and XQuery will be used for data management, as designed.

XQuery seems to be the subject of a lot of buzz this week. Paul Cotton, who presented before Robie, offered two pages in small print of XQuery implementations in his slides. They’re not all complete, and most probably never will be, but by all appearances it should be mentioned as commonly as XSLT about two XML conferences from now.