Hi Dave,

> > > > Native XML storage? What's that supposed to mean? Rubbish!
> > >
> > > Yes, it's a horribly misleading and confusing term. I think that when
> > > people say they want "native XML", what they really want is an XML

column

> > > type that supports DOM, XPATH, or some other XML-specific operations.
> > > This is not a bad idea, IHMO.
> >
> > Not a bad idea? Why not? What exactly does XML mean then? What
> > would you expect the engine to do with it? Validate it? Ask for a

specific

> > node?
>
> Mean? What does a VARCHAR mean? What does a DATETIME mean? It's just a
> domain. The meaning comes from the predicate that backs the relation.
> I see where you're going with this, and I don't necessarily disagree; in
> general, I don't see much that XML has to offer over relational aside from
> its usefulness as a packaging / transport mechanism for data. Why does XML
> need to be in the database? I don't know, but from a theoretical
> standpoint, it's just another type with a set of well-defined (albeit very
> generic and string-oriented) operations.

Yes, it's a domain. But for VARCHAR and the others, the
available operations are agreed upon. Is this the same for
XML?

> I'd expect the engine to do at least the following:
>
> - Ensure syntactical correctness
> - Validate against an XML Schema or DTD
> - Perform queries on subelements
> - Perform modifications to the document model

These can become very tedious - does Firebird want to go
that route, considering XMLs can be huuuuuge in size.

I can imagine validation, because that's part of an RDBMS,
but queries against subelements? Modifications against
parts of the (XML) value?

Of course, this means "native" XML, but does it have a place
in an RDBMS?

> > XML is human readable crap used to exchange data between systems
> > that don't need human readable crap with too much bandwidth to spend :-)
>
> I disagree. It's not always human readable. =)

;-)

> > > "Native" seems to imply that XML is actually saved to disk as XML,

which

> > > seems a) irrelevant, since data independence dictates that we should

not

> > > care how it's saved to disk, and b) undesirable, since most of the

things

> > > people would want to do with XML would perform much better with a

parsed

> > > DOM, not straight text. But of course, this doesn't stop marketing
> > > departments from using the term to promote their clearly superior,
> > > next-generation technology. ;)
> >
> > Ho hum... talking about a step back :-)
>
> Well, I think it depends on your requirements. Maybe XML is a
> self-fulfilling prophecy, but it seems to me that if I were given the task
> of managing a bunch of XML files, and I didn't have to do deep
> modifications to them, I wouldn't bother converting between XML and
> relations. I'd just find some way of managing them as XML. Of course,
> whether the XML was necessary in the first place or not ought to be
> debated, but if it's a fixed requirement, I'd probably start searching for
> a database that understands the syntax of XML.

The problem is that most people think you can store anything
in an XML file and think this is top-notch. But it isn't... It's
history repeating itself all over.

Sure, there are uses for XML ... But with XQuery (and so on),
then have overshoot theirselves...

> > > The ability to manipulate XML data through SQL seems more useful than

the

> > > ability to dump relational data as XML. Some DBMSes provide functions

for

> > > projecting data into XML, but since there's no standard mapping from
> > > relations->XML, every DBMS may conceivably do it differently, and none

of

> > > these variations may be what the application already needs. For

instance,

> > > one common usage of XML is to send structured data to Flash, but if

you

> > > have no control over the format required by the Flash movie, you're

back

> > > to writing procedural code anyway, unless your DBMS's mapping function

is

> > > highly configurable (and it isn't, typically). Not a big deal, IMO.
> >
> > That's the problem... "XML" by itself isn't defined at all...
>
> I have a feeling you're talking about semantics again here, where I'm
> simply talking about types. XML as a type is just a recursive tree
> structure that happens to look like a bunch of nested tags, just like a
> DATETIME is a record structure that happens to look like a formatted
> string.

Ehm, no it doesn't :-)

>Or, at least, that's one potential viewpoint.

Nevertheless, what sort of operation do you expect on a datetime?
UPDATE mytable SET mydate REPLACE month WITH <newmonth>?
(although it _could_ be possible) ;-)

But for the XML type, you're expecting a whole lot of more things!

> > btw, I too use XML for some things - for example, configuration.
> > It's quite useful in those cases...
>
> Perhaps. I'm not a big fan of XML configuration files. They're too wordy
> for my tastes. However, I think it's good for interop, since a lot of
> languages and platforms have support for it.

They have had support for plain text files for ages! ;-)

> Whether or not there's any
> point to persisting XML in a database really depends on the requirements
> of the application, I think.

With regards,

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