At 05:18 PM 4/16/03 +0200, Martijn Tonies wrote:

> >
> > > That still leaves the question though, how is a database engine supposed
>to
> > > deal with it?
> >
> > By exposing a DOM/SAX parser for use in PSQL code.
>
>Perhaps by a "built-in" external function (udf library) that's
>always available? Just like "ibudf"?

There seems broad consensus that XML is general, cross platform, and cross
industry segment. It has not been discussed, but I am prepared to argue that
the server overhead to generate or deconstruct XML is less than the cost of
shipping the data in out or into the server to perform the operations on the
client.

This just leaves the large question of how the data conversions might be done.

So far there have been three suggestions. The first is that XML can be
generated
by existing stored procedure language. Whether or not this is feasible for
more
complex cases, writing a procedure from scratch for each transformation strikes
me as cruel and usual punishment for Firebird users. A second suggestion is
Firebird embed a real programming language, specifically Java, which can
support
a civilized library of functions. Embedding a JVM into Firebird is an
ideal I've
been pushing for years, but so far, no takers. That said, however, it must
also
be recognized that the horrible performance of Java string handling would
almost
certainly cancel any performance gain by not slopping the data around the
network.
A third suggestion, blob filters, is a non-starter due to limitations of
the blob filter
interface.

So, absent a good fairy to deliver a suitable JVM, I think we need to start
thinking
about rulesets that define metadata <=> XML mapping, the semantics (first)
and syntax (second) of the rulesets, where the rulesets reside, how they're
managed, etc.

Jim Starkey