> Not entirely. It doesn't tell you anything about physical storage,
> it does tell you about what should be stored (namely: "true"
> values).

...from the point of view of the relational model. Do you want to
claim that the true values in relational model are the only true
values that can exist?

> I'm not saying OODBMSes won't work, just like XML-DBMSes might
> work [in the future]. Nevertheless, there's no solid basis to store
> objects unless you map them.

Nobody claims that XML DBMS is the way to store your relational data.
They are not. But XML DBMS works better for storing semistructured
documents that are accessed as single entities, that do not share any
information between them. There is no normalization, some data are
redundant.

It just has its own use case and do not try to evaluate its
applicability for the typical applications for the relational databases.

> Just because XML has gone way beyond its original "specification"
> does not mean is has a solid foundation for data storage. Remember,
> it was designed for data-exchange. And yes, it comes in handy
> sometimes, I use it myself for certain things as well.

Again, it is not suited for the data storage as you understand the
term "data".

> > Please do not tell me that OO data model does not have math and
> > logic.
>
> Then show it. What exactly defines the "oo data model"?

I will check my "library" for the oo data model where they define it
the same way relational model is defined. Would it be enough for you?

> Who said I was going to introduce a relation?

And how you are going to store information about keywords for the MS
Word attachments, image size for the images, digital signatures for
the executables in one column?

> I would certainly split up the XML document. It has no basis to be
> kept together. Heck, that's why there's different parts in the
> document. It holds info about several entities.

Nope, it holds info about one real-world entity. You cannot split XML
document as you cannot split an 32-bit integer. You can specify a
query SELECT * FROM myTable WHERE myCol BETWEEN 1 AND 64, but you do
not access each bit separately. An XML document is atomic entity. Period.

> > > 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?
>
> No, on insert, extract keywords :-)

So that's the job for the DBMS you say? In case of XML I say that
information already comes into the database preprocessed. How? I do
not care.

> > 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.
>
> If this is relevant info -> store it.

False. You do not explicitly store all available relationships in
RDBMS, but some are implicitly there. Same with XML - some information
is implicitly there. You don't need to store it explicitly.

> If the position in the XML document is relevant, you're actually
> making representation (of the XML document) a factor in the meaning
> of the data. This sounds silly to me. Then again, I might be
> nitpicking, but still.

That is not representation. That is a data model. If data model
explicitly says that order is important, then it is important.

> > And in XML some information does not require adding unnatural
> > constructs.
>
> You're thinking representation, not storage.

I'm thinking about the logical view of the data. About something that
in relational model is said that logical view of relations are tables.

> This is a scary document ... it talks about "parent" and
> "referredby" - pointers, which the relational model was supposed to
> replace because it caused so many problems. And yes, "next" and
> "previous" have been reintroduced as well. I guess it doesn't get
> any better than this.

Relational model was supposed to replace that stuff because it did not
work in many cases, but in some it was perfectly ok. If I need to
compute the shortest path from point A to point B with Dijkstra
algorithm, relational model does not help me a lot simply because my
algorithm is desined on a graph, not on relations. Why do you fail to
see that not everything can be done in relational model?

> Good for stylesheets :-)

What does DTD or XSD have to do with stylesheets?

Roman