Lists Home |
Date Index |
| I think the XML database world needs a single query language that can be
| used without extra layers of DOM, SAX, Java, or XSLT to do everyday tasks.
| And I think that the few features of XQuery that have not been taken into
| XPath 2.0, such as function definitions and element constructors, are
| extremely useful for everyday tasks.
Some vendors are pursuing multiple XML querying *syntax* strategies
due to the needs of their customers. The XQuery effort in
the W3C and the SQLX effort (www.sqlx.org) are both multi-vendor
groups pursuing syntaxes that various constituencies will
find palatable. Oracle, for example, is participating in both.
You see the names of other large companies with major investments
in (object/)relational database technologies in widespread production
use today on both groups, too.
Our (speaking for Oracle here) customers have begged us to seamlessly
integrate XML Data as *one kind* of data among the other sorts of
information they already process (relational, full-text, multimedia,
spatial, time-series, data warehouse, etc.) For these customers, building
apps that need to work with XML data and with other kinds of data, they
want a single query language that works with them all. These customers
already know SQL, so the SQL extensions for XML (some which are being pursued
in the SQLX group) will likely appeal to them and their developers. If
they know SQL and XPath and a few new SQL keywords, they'll be set.
Developers at companies whose data is purely XML will likely find
XQuery to be a more pleasing syntax for them. Having a query engine
underneath that can handle both constituencies' favorite syntax with
equal performance is what takes lots of hard work. That's at least
what our implementation experience to date has taught us...
Steve Muench - Developer, Product Manager, XML Evangelist, Author
"Simplifying J2EE and EJB Development with BC4J"
"Building Oracle XML Applications" - www.oreilly.com/catalog/orxmlapp