Hello Nando,

> MT> XML is a data-exchange and representation format.
>
> Yep.
>
> MT> What else does XML offer?
>
> I don't mind. I just took the opportunity to highlight a possible
> reason why (IMHO) the industry is looking at XML as a storage means.
>
> If you are able to do everything you need with a pure relational
> database then good for you. I outlined why I cannot (conveniently) do
> all I need and I have talked with many people that have the same needs
> and look at XML. Give me a way to store signed documents and query
> their contents and I won't mind about the format - XML is just as good
> as anything else (although I find it excessively verbose but that's a
> different matter).
>
> MT> If people use it for complete documents and store them as such,
> MT> you're using it the wrong way. Why should IBM or anyone else
> MT> accept that and make it query-able etc?
>
> Because there's market there. And huge too. I feel that the relational
> model could easily provide tools to do the above, thus eliminating the
> need to look at XML as storage. But such tools are currently not
> available.

I argue that xml as STORAGE is plain silly.

First: a DBMS can do everything it like to store the data. It can carve
it in tree bark if it likes. Firebird compresses the data, no problem there.
I argued with the MySQL guys about this too because of their
non-standard CHAR/VARCHAR stuff - they argued that storing in
char is different and then some bla bla... I said: no, it isn't. As long as
you pad it with spaces when retrieving :-)

Second: why do you store XML if it's only representation? What
does XML offer you above "plain" relational storage?

Third: relation storage has a logical/mathematical basis. What is the basis
for IBMs XML storage stuff? Or even: for ANY XML-based "DBMS".


With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server
Upscene Productions
http://www.upscene.com