On Thu, 22 Jul 2004, Martijn Tonies wrote:

> "SP: Many developers have been looking for XML support and, while most
> database systems can export or dump to XML, they are looking for native XML
> storage. Is it left to the developer to use a scripting or programming
> language, or is this perhaps a feature of Firebird? What are your XML
> features?"
>
> 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.

"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. ;)

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.

--
.:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.

"When the country is confused and in chaos, information scientists appear."
Librarian's Lao Tzu: http://www.geocities.com/onelibrarian.geo/lao_tzu.html