Somebody recently raised the question of whether XML support in Firebird was
a good thing. I think it's an excellent question around which to examine some
architectural issues.

The first question, of course, is whether or not a piece of functionality
is appropriate
to embed in the server. Among the many questions to be answered are:
* Is the function well understood? Is it a subset of a more general
problem that should be addressed instead?
* Is the function sufficiently general? Does it cross applications,
segments of the industry, and differing application topologies?
* Is the function well understood? Is extensibility expected? Required?
* Is there a clear performance benefit to moving the function into the
server? Is network traffic decreased in round trips and bytes
transfered? Can the cost of server resources required to support the
function sufficiently offset in gains in communication efficiency?
* Is there a clear security benefit for moving the function into the
server? Conversely, is there a security liability in doing so?
* What additional information/context must be maintained in the server
to support the function?
* Is there operational information required for the function present
only inside the server?
* Does centralizing the function into the server significantly reduce
application complexity?
I'd be happy to discussion any or all of these in detail, but to my mind,
XML generation
fails the first test but passes all others excepting, perhaps, an
operational imperative for
server residence.

There is nothing magic about generating XML. Anything that can generate
XML can
generate HTML (probably much more interesting), SGML, form letters, and
junk mail.
To my mind, the problem of XML generation translates to "data driven, rule
based,
complex text generation" (a phrase that doesn't exactly roll off the tongue).

Before any real conclusions can be taken (other than dismissing the
function out
of hand), a reference outline of a prospective implementation is
necessary. Among
the questions it should address are:
* How are generation rules expressed? Code? Templates? Combination?
* What are the interface requirements? How is the function exposed
through the various set of plumbing (Y-valve, remote interface, line
protocol, server)? What about access through warts like ODBC and BDE?
* Can the function be supported with the current server
layering? (Hint: the current DSQL implementation is likely to be a major
impediment.)
* Are there additional requirements on other server subsystems?
* Are any development tools required to implement or exploit the function?
There are many, many more questions that will come up as we start down
(up?) the
alternative tree, but these are a start.

Any thought?




Jim Starkey

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