I don't think the question is as neatly delineated as you all would assume. I would think the issues break down into the following:
Storage Issues Is the database capable of storing XML efficiently, in other words should there be more capabilities added to Firebird for handling possibly polymorphic data(aka variable fields, and sometimes fields with an unknown schema) and metadata associations such as namespaces. XML can represent a structure far more dynamic than most databases can handle, and this issue should be the major concern to address, IMHO
Custom Query Methods There have been numerous advances in the querying of XML data stores XPath, XML-Query, etc. What I would personally love in a database is the ability to natively use query languages other than SQL. I would love to have XPath statements that automatically construct required nested XML documents for querying by XPath. This is one area where engine integration would be nice because of optimization issues. And the dynamic nested XML search trees could be created efficiently because of the built in referrential integrity of the current system.
XML Document Serialization / Deserialization / Mapping This seems to be the source of most controversy around here. I personally think the issue should be broken into XML (De)Serialization as a utility function vs. XML (De)Serialization as a standardized XML Document mapping. We all know that the mapping of XML Documents to a database format could be handled by the client program. But we also know that object oriented programming may be useful but functional programming is enough to program anything (in other words, just because something works doesn't mean implementation of a more advanced incarnation is useless). This is how most people view the issue, as a matter of utility.
I would like to propose the issue is more of a matter of universal standardization. We could implement XML (De)Serialization and any client could automatically use it. They don't have to know how to map everything. Not only that, but almost all statements here are assuming that this issue either be handled on the database server or by the client program. I propose the creation of a standard behavior for client-side interfaces. Whereby, it is required that client side drivers do the automatic recognition and (De)Serialization / Mapping (although custom mappers should of course be allowed). This solution would seem to me to be the best of all worlds.

Anyways, those are just a few of my thoughts on all this controversy. Hope it helps.

Edward Flick



Jim Starkey <jas@...> wrote:
At 02:53 PM 4/16/03 -0400, Paul Schmidt wrote:

>That's what Firebird does, it stores data. XML can be, and should be limited
>to being either a source for data, or a destination for extracted data, in
>other words your populating an XML document with database data. So the
>question becomes should that be done within the engine, or within the client,
>and is the benefit of doing it within the engine worth the cost of doing so.

Well said, sir. That is indeed the question.

Jim Starkey


To unsubscribe from this group, send an email to:
Firebird-Architect-unsubscribe@onelist.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



Edward Flick
Enterprise Applications Designer / Database Administrator / Web Administrator
CDF, Inc.


---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

[Non-text portions of this message have been removed]