SV: [xml-dev] Caught napping!

["Jens Jakob Andersen, PDI" <jens.jakob.andersen@post.dk>]

Hi Linda

Welcome back.

> schemas out there these days, they are often blatantly 
> influenced by an
> underlying relational mentality.  This is not  a bad thing if your

My experience (both RDBMS and XML DB) is that in the XML world, we all
forgot about the datamodelling aspect. Stuff that the SQL crowd has been
doing for decades, and learned to love and live with (as well as argue
about, even mathematically), we just simply plain forgot.

I guess that some of this is due to the fact, that XML grew out of the
SGML world, a very document oriented world ? (Hey, the W3C XQuery group
had forgotten everything about adding features for updating XML
structures untill I talked with Jonathan Robie about it, since they
worked fully from a "Querying documents" viewpoint...)

Now we have XML, and allmost all the people I've met, are looking at
using XML for data, and not documents. (Allthough one guy I know, told
me: "We've been using SGML for decades for our technical documentation.
It is great. It solves all our problems with _structured documents_. But
now we're looking at XML to solve this, since the tools are cheaper, and
the new kids thinks that SGML is old and dusty, whereas they love XML.
But it is the same issue we're solving, structured documentation.
Anyway, this guy had a punchline too, "We dont care about whether it is
SGML, XML or SQL underlying the system, we just want structured
documentation.")

We need to realize, that all the SQL guys, have gotten used to nice
helpfull features in the RDBMS, such as triggers, rules, joins, views,
batchupdates, import/export tools, high performance, stored procedures
etc., that makes life so much easier for you, when you're working with
data. Remember that the MS in RDBMS stands for "Management System". 

Back to the datamodelling issue:
I can easily design a relational schema, and I can even validate it,
using mathematical formulaes and algortihms. This is great. I can
optimize the data structures, so no matter what new needs my clients
will make up, I can easily facilitate this, since I didnt get bogged
down in a document structure. And I can rebuild any structure from my
data (if I model them correctly.)

With XML, I can make up a schema/DTD, but unfortunately I haven't got
any ways to validate this schema. (Hey, where is the first really great
book on XML Data/Document modelling?)

We need to develop a process for doing XML datamodelling, so that it can
be become a validated science and not just magical art. Then they even
might begin to teach this methodology at the universities, just as they
teach relational algebra and modelling.

> around, would anything change?  Referential integrity, for example,
> between such mundane objects as customers and purchase orders might be
> accomodated by treating the customer and his list of POs as a single
> doc.  Or, if the implementation is efficient enough in terms of data
> footprint, by replicating customer data on each PO.

Ouch!!!!! A fact about XML structures today, is that they promote data
redundancy. And unfortunately, storing the customer together with all
PO's will not guarantee RI as I see it. How do you then ensure, with a
customer with 100 PO's, that when you change the phone no. of the
customer, it is guaranteed to be updated on all 100 PO's ?
I can agree that on a very statical web-site (maybe a bookstore?), you
could store all the data as XML documents, and put all the info about a
book into each XML document. But then again, what would be the benefits
of this ? What we need is XML interfaces to the systems (web.services),
and then the ability to quickly generate XML on the fly for transmission
/ multi device rendering using XSLT.
 
> satisfactory and a real pain to maintain.)  The ability to persist and
> manage XML "natively" may now give us the choice.  The analogy with

Which is what I'd still like to see some real life industrial strenght
examples of, that are not just XML "stores", but real XML DBMS, I mean
XML Database Management Systems, with all the nice bells and whistles
that the SQL crowd has gotten used to, joins, views, triggers (insert,
update, delete etc.), rules, stored procedurs and high performance.

And I would very much like to see a XML DBMS, supporting the W3C
standard; W3C XQuery (it is a great effort and it has joins and views;
definately needed, and W3C Schema for _real_ data modelling.)

And I guess that when the XML really picks up speed, we will see the big
ones, (IBM, Oracle, MS) add W3C XQuery and perhaps W3C Schema
capabilites to their existing database systems, making it very easy to
work with XML data/documents on the storage level.

But all this will not solve the central issue: XML Data/Document
modelling theory.

This mail got a bit long, but I think that we need to addres the central
issue to XML, the modelling theory. The "Native/not native XML" flame,
reminds me a bit about the Mac/PC flames of yesteryear. How data is
stored doesnt matter, it is how they are accessed, managed and modelled.

All the best

Jens Jakob