On the note of XML,

I am far from a expert on the subject, but, I just finished a project that
produced XML output from a interbase 5.6 database.

I was given the format for the output file (headers, formating, headings etc)
I created a stored procedure that read a series of tables and populated a
varchar (1000) result on a line by line basis.

Our users do a select on the stored procedure and get the result they want.

With Firebirds eval feature, and some tables to define the output, (and a
little work) you should be able to make a generic routine to generate XML (or
html, sgml etc) for the end user without any changes to the core engine.

Or, the client could generate the data....

I do not think you would need a UDF or Filter or even any code changes to
implement this (unless you want the whole xml to be put into a blob) , just a
nice little script to be run by users who want that functionality.

best regards

Dalton

PS, I still have those UDF's for people or, if I am upgraded to developer
status, I will put them up myself.

On Thursday 27 March 2003 11:11, Jim Starkey wrote:
> 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]
>
>
> 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/