RE: [xml-dev] Caught napping!

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Subrahmanyam Allamaraju [mailto:subbu@bea.com]
> Sent: Thursday, November 08, 2001 3:05 PM
> To: Jens Jakob Andersen
> Cc: lgrimaldi@neocore.com; jens.jakob.andersen@post.dk;
> xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Caught napping!
> 
> 
> I don't see XML-DB proponents attempting  to specify 
> the logical data model, the role of schema in such a model, query and 
> update semantics, what they mean, possible constraints (including 
> integrity), types (such as numbers and dates) and so on. In 
> the absence 
> of such a logical framework, the problem seems 
> ill-defined/under-specified to me.

XML does not claim to be a general theory of data; it does not compete in
that respect with the relational model, so it's not
"ill-defined/under-specified". You're right about the "update semantics;" I
assure you from working on the DOM specs that XML 1.0 is has a read-only
orientation baked deep into it. Types, of course, are a well-known issue
that is supported in the Schema layer on top of XML itself, and are
admittedly still a bit bleeding edge.

BUT XML is suitable for a particular class (a large one!) of problems where
relationships are defined hierarchically -- "IS-A", "PART-OF", etc. and the
"document", not the elements/attributes in it, is the basic unit of work.
In this class of problems, integrity constraints and update semantics are
not salient issues. In that class of problems, XML databases can be quite
appropriate solutions because they do not force one to consider the
logical-physical mapping:  Native XML databases store data (either
physically or via intermediate data structures that are invisible to the
user) in essentially the same form that is seen by the end user, hence
"database" modelling is essentially the same as "document" modelling as
practiced by the SGML folks for some time.  This has a cost in flexibility
-- you don't get the benefits of data independence, such as ease of re-use
of one physical database by multiple applications with different logical
views -- but a lot of practical benefits in terms of performance, ease of
mapping onto XML interface standards, lower cost of DB administration, etc.