At 07:56 AM 4/17/03 -0700, Edward Flick wrote:

>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

We have generally been talking about XML as an import/export function. You
seem to
be arguing that storage and internal manipulation of XML is
desirable. Could you explain
your thinking?

> 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.

I think you're jumping way ahead. The relational model has been very
successful
as the basis for data manipulation languages, having eliminated the more
arguably
more powerful network model and the more intuitive hierarchical model and crush
a slew of OODbms's. You seem to be proposing that XML is a workable internal
format, which runs counter to my experience. If this is your intention, please
make a case.

>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.

There is no need for us to discuss standardization of anything on the
client side. There
are plenty of organization eager and willing to do so, and whatever happens
on client
is of little interest to the architecture of the server other than question
of language
interface and optization.

I'm going to have to a disagree with almost anything that contains the tokens
"XML" and "automatic". XML documents can and should be driven by issues
of convenient and general data exchange. Database data models are driven
by data semantics and performance. The idea that anything could take an
arbitrary XML document and map it into a set of database updates is ludacrous.

Any useful mapping utility (either direction) must be driven by an explicit
set of rules. If those rules are expressed in program code (absent a suitable
embedded language), they belong on client. If we can agree on a specification
for mapping rules, then it makes all the sense in the work to move the mapping
code into the server. But that's a pretty big "if". I haven't the
slightest doubt that
there are a hundred specifications competing for the crown of "de facto"
standard;
there may even be a standard blessed by some alphabet soup organization.
If we go that direction, somebody should take on the dreary task of researching
this.

Personally, I think it likely that birectional rules are more trouble than
they're
worth. A nice, clean XML->DML language would be nice. But for the other
direction, a more general DML->text mechanism would be generally more
useful.



Jim Starkey