Subject Re: [Firebird-Architect] XML
Author Jim Starkey
At 05:18 PM 4/16/03 +0200, Martijn Tonies wrote:
> >
> > > That still leaves the question though, how is a database engine supposed
> > > 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

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
by existing stored procedure language. Whether or not this is feasible for
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
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
be recognized that the horrible performance of Java string handling would
certainly cancel any performance gain by not slopping the data around the
A third suggestion, blob filters, is a non-starter due to limitations of
the blob filter

So, absent a good fairy to deliver a suitable JVM, I think we need to start
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