> OO is no basis for storage, is it?

Who speaks about the storage? Does relational model defines how data
are stored? If I remember Codd correctly, he explicitly tells that
relational model does not define how data are stored. That may be
table, that may be some hash table or whatever you like.

> OODBMS: yes, please, drop them :-)

OODBMS does not tell how data are stored, but how they are accessed
and manipulated. And I know at least one example of very successfull
OODBMS use-case in the company where I worked before with a huge
amount of geographical data (Europe and US, including the building
polygons). Would RDBMS work there? Maybe... but not so good as OODBMS.

> I'd rather see a decent OO <-> DBMS bridge.

They are available, but most likely only in Java :)

> Does XML introduce a data model? If so, please show me the basis
> for this model.

http://www.w3.org/XML/Datamodel.html

I'm almost sure that you find somewhere definition of the
"XML-algebra", but also consider that it will be very similar to the
one used in OODBMS. And there is formal model for OODBMS.

> The relational model has math and logic as its basis.

Please do not tell me that OO data model does not have math and logic.

> One of the primary reasons to create the relational model is
> data independence. How can the above not be done in a
> (R)DBMS? I don't see the benefit of XML here.

You just understand data in XML wrong. Data in the XML I mentioned
before is not a first name or last name or a chapter title, but the
complete document. Not more and not less. So

> 1) user defined types (eg: domains)

Ugu, and how you're going to introduce a relation as a domain keeping
the database at least in first normal form? :)

> 2) being able to create the basic operators on the domains

Wait, aren't you already beyond the relational model?

> 3) keyword extracter

A custom component that is supposed to parse the attachment completely
each time you want to access it? Are you really proposing that?

> A position field? Why? If one author is more important than another,
> then yes, there better be a position field. Cause if the position is
> based upon the "position" in the XML document, then it's really
> plain silly.

It's not. When you take a book in your hands, you see a first author,
then a second one, and so on. So it is relevant info. But in
relational model you have to add that field explicitly, because
relational model explicitly states that there is no order between tuples.

> You should store data, if position is part of the data, store it. If
> the representation of your data inside an XML document containts
> info about the data, you're doing things the wrong way.

That's your private opinion caused by your "relational" thinking. I do
not care about storing information. I want to have the information.
And in XML some information does not require adding unnatural constructs.

> Then, I ask you: what is the solid basis for the model. How is it
> even a model?

http://elib.cs.berkeley.edu/seminar/2000/20000207.pdf

Your problem is that you do not consider graph and operations on graph
to have solid mathematical background.

> but constraints are part of the basis of the relational model and
> a decent (R)DBMS. It's the best we can do to ensure that our DBMS
> knows what the data means and enforces integrity. How does this work
> with XML?

You have a DTD and an XSD. The document that conforms the DTD or XSD
is considered consistent. If a transformation applied to the XML
document does not satisfy the target DTD/XSD it is considered
inconsistent.

Roman