Re: [xml-dev] Caught napping!

[Ronald Bourret <rpbourret@rpbourret.com>]

Subrahmanyam Allamaraju wrote:
> When I look at relational databases, I know what to look for in a
> product - from the logical model to the query language to other
> "ilities". The same is more or less the case with document management
> systems. However, I've difficulty when it comes to XML databases. They
> are different in terms of level of granularity of operations, query
> languages, etc. Most of these products have additional semantics for
> different kind of operations (queries, updates, inserts, deletes,
> imports, exports, transactions etc) on data. So my question is about the
> logical framework underlying all these "features".

First, it's important to remember that native XML databases model XML
*documents*, not the data in those documents. Thus, it's somewhat
misleading to mix the topics of data modeling and native XML databases.
In the XML world, data modeling is essentially done with DTDs, XML
schemas, or just plain markup in schema-less documents. It's not done in
the database.

Second, every native XML database defines two different models for an
XML document. The first is the physical model, which determines both how
the document is stored and at what level it can be round-tripped. Unlike
relational databases, this is often in plain view in native XML
databases. The minimal physical model is elements, attributes, text, and
document order; the maximal physical "model" is the stream of bytes in
the XML document.

The second is the logical model, which is the underpinning of the query
language. This is commonly the XPath data model and will generally be
the XQuery data model in the future. Note that there is a definite
possibility that the query data model is richer than the physical data
model. For example, if the physical model is minimal (elements,
attributes, text, and document order), an XPath query on a comment won't
do much good. When thinking about the theory of native XML databases and
trying to contrast them to relational theory, it's a good idea to focus
on this model.

Third, a lot of this stuff will coalesce as XQuery gets finished and the
industry matures. In the long run, I think you will still see a variety
of physical models, but very few logical models, with all serious
players standardizing on XQuery's model. Similarly, I predict that an
ODBC-like interface (with XQuery playing the role of SQL) will be
standardized within a couple of years (XML:DB with XPath is here today).

As to implementation details like transaction granularity (document- v.
node-level locking), you'll probably always see differences, just as
there are differences in the relational world today.

-- Ron