[
Lists Home |
Date Index |
Thread Index
]
|> I honestly think that XQuery could do for XML what SQL did for the
|> relational model -- put a single, general tool into the repertoire
|> of mainstream developers that gives them a lot of power to deal with
|> the new approach without having to wrestle with its bizarre details.
|
| I had the same feeling last time I heard Jonathan Robie present XQuery. But!
|
| Unless XQuery also caters for Update, it will never become the SQL of XML,
| it will be overrun by |individual vendor implemantations (probably more
| like the BASIC of XML) that will work on individual |platforms, have
| similarities, but not be a standard.
It's also worth considering what type of customer
will like the XQuery syntax versus a SQL syntax that
is extended with XML-savvy operators.
If a customer has 100% of the data in their organization
in XML, I believe they will like the XQuery syntax for
querying their database.
If a customer has a mix of relational, multimedia,
full-text, geospatial, time-series, multi-dimensional
(a.k.a. datawarehousing) data, in addition to a large
amount of XML documents to manage, there's a good chance
they will prefer a single SQL-based syntax to work with
all of their data. I find it hard to believe that a
typical customer like this (which not surprisingly
are like *most* of our customers doing XML work)
would want to view all of their existing data through
"XML glasses" in order to use XQuery against it.
That at least not what our customer focus groups
have told us. But the former category of users mentioned
above surely will want the "Optimized for Pure XML"
approach that XQuery syntax offers.
Ultimately, having a database engine that is robust,
and fast and can support alternative query syntaxes to
make both of these constituents happy is a way to make the
largest body of database users content. This is why we're
participating in both SQLX and XQuery industry efforts.
As can been seen by the companies participating
in the SQLX meetings (http://www.sqlx.org/Meetings/MeetingInfo.html),
we're not alone in this belief of a multiple-syntax
query world.
The Oracle9i Release 2 database contains support for
many of the SQLX operators currently being voted on
in the ANSI committee. We've changed the syntax of
many of the operators from earlier beta releases of
Oracle9i Release 2 to comply with this evolving standards
work.
I'm giving a technical drill down on the native XPath, SQLX,
and XML Schema features in the new Oracle9i Release 2
database (due to go production *very* shortly) at the
XML Europe 2002 conference in Barcelona in the
"Vendor Presentations" track. I'll explain and demo the product
there to help audience members see how things
work, like: how XPath queries get rewritten under the covers
to use standard database indexes for fast retrieval,
how XML updates works, how the SQLX operators let you
construct XML query results of any shape, how you can
create XMLSchema-valid views on top of existing relational
data to do XPath queries against, how XMLSchema-based
documents get automatically managed into object/relational
storage with full DOM fidelity if desired, and other cool
things...
Hope to see you there.
__________________________________________________________
Steve Muench - Developer, Product Mgr, Evangelist, Author
Simplify J2EE and EJB Development with BC4J
http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
Building Oracle XML Apps, www.oreilly.com/catalog/orxmlapp
|
