relational<-->XML translation: a Python specialty absorbed by adatabase?

[rzed]

"John Benson" <jsbenson at bensonsystems.com> wrote in message
news:mailman.1181.1075855864.12720.python-list at python.org...
> Hi, I've been looking at the "Oracle9 i Database New Features" guide, from
> which I quote:
>
> XML Generation
> In response to the challenge of generating XML in bulk from a database,
XML
> generation capabilities have been moved into the database and application
> server
> kernels and made available as built-in SQL operators. The kernel proximity
> of these
> operators ensures massively sustainable throughputs, enough for the
largest
> content repositories or the busiest exchanges.
>
> (end quote)
>
> I've been quaffing the XML kool-aid recently and imagining that scripting
> languages like Python would be key in moving data between relational
> databases and the Web by doing XML translation. From the preceding quote,
it
> would appear that databases might be appropriating this task to some
extent.
>
> It's pretty obvious a few XML operators added to SQL (or SQL*Plus, in the
> case of Oracle) may not seriously challenge the expressiveness of Python
or
> Java, but they may tend to shape XML requirements in the direction of
> simplicity so that the maximum can be done by the database itself.
>
> Comments?

I've recently been working with a fairly large database with an Oracle back
end, and I've seen the difference made by moving processing to the server.
It's better. But it's not perfect.

A lot depends on the relationship between what is actually stored and the
complexity of the XML on output. If the end product consists of relatively
few elements, and the data comprising the elements corresponds pretty well
with the database, then most storage and retrieval operations would be
similar in their character to normal database tasks. That's a good thing, if
it is possible to match the data to the output closely. Adding XML
generation to the back end should make that more efficient.

If the data is complex and stored with fine granularity, then database
operations will be expensive in any case. XML in the back end will help a
little, but it would still be far more time-efficient to pull unparsed
chunks of XML data and to parse them in memory. Loading the data would also
be more efficient if it can be prechunked and stored that way. That's where
I'd think Python would shine: in the immediate pre- and post-processing
steps.

--
rzed