RE: [xml-dev] XML Database Decision Tree?

[Jeff Lowery <jlowery@scenicsoft.com>]

> I have a gut feeling that 
> the typical
> developer can do a decent data model in XML more easily than 
> he/she could do
> a decent normalized RDBMS model, but that's one for the Time 
> Will Tell file.

The same sorts of arguements are given for object-oriented programming. OO
programming *is* conceptually easier at first blush, but once you get into
domains of sufficient complexity, OO modelling gets very hard indeed.

I think data models in XML have that same, first blush feel. But if you're
using XML for data interchange or data storage, I think the same old
problems associated with update anomalies and their ilk come to fore. There
are more inefficient ways to use XML for your business data than there are
efficient ones.

XML documents, though, do address two varied domains. In one sense they
server a similar purpose as doe RDMBS views: denormalized representations
for output only. But, if you're modifying a document and feeding it back to
its source, you want to avoid introducing inconsistencies in the data
source. True, such inconsistencies can be weeded out though programmed
checks, but the most reliable way is to carefully construct a document so
that the checks can (as much as possible) be done against schema
definitions. This allows consistent checks to be done both at point of
origin and destination.

To put is simply: is the XML used for data output or data input? The former
can be done any way you please, but later is best constructed in such a way
so that maximum validation against a schema can be done, minimizing the need
for disparate (and possibly inconsistent) programmed validation.






> 
>  
> > Now this isn't a new struggle.  Data Architecture 
> historically has had
> > an uphill battle for acceptance, I won't get into the 
> > specifics of that
> 
> I'd appreciate some pointers to resources on "Data 
> Architecture" and its
> principles as it relates to XML.  It sounds like a discipline 
> that we need,
> e.g. to address the question of when to model hierarchically 
> and when to
> model relationally.  
> 
> > In terms of the XML database I think the term database might be bit
> > misleading (I personally think repository fits better) 
> 
> Hmmm ... I'd say that "repository" implies persistent storage 
> and retrieval
> by some primary key, some predefined metadata, and maybe 
> brute force search
> ("grep").    "DBMS" implies that plus more flexible yet 
> efficient queries,
> transactions, integrity enforcement (whatever that means in XML!),
> backup/restore utilities, optimization tools ...  By that 
> definition, a
> vanilla WebDAV server is a "repository" whereas the products from the
> vendors who have participated in this thread are "DBMS".  
> That seems like a
> distinction worth making.
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>