> You have to write xmlGetUser() to take in the userid and return the
> xml required for it. I see no advantage to generating the xml in the
> db rather than in the servlet.
As a counterexample, my PKIX extensions defined an "XML" datatype
that could be used to generate XML instead of the standard format.
E.g.,
select cert as xml from certs where ....;
But this was an exceptional case - for many of the objects the
"standard" format is a base-64 encoded ASN.1 string, but with
XML I need to extract the fields *and* still include the object
as a base-64 encoded ASN.1 string. It was *much* easier to just
generate it in the backend than to do it at the db->xml level.
More generally, I think we need to keep an mind an important
distinction here. Most of the time XML represents the contents
of an entire tuple, and each field corresponds to a attribute.
In these cases an external db->xml layer makes the most sense.
But with extensions it's common to have complex objects in a
single attribute, and there may be a standard way to represent
the object in XML. (E.g., all of my XML conversions are extracted
from the proposed "Signature" schema at W3C.) In these cases
it may make more sense for the extension to provide its own
XML mechanisms, but it would be nice if there was s standard
way of handling this.
My suggestion was mentioned above. Just make "xml" a standard
data type. It can be transparently converted to/from text, but
you can define functions that return "xml" (or accept xml) and
use casts to specify when you want XML instead of the normal
format for that attribute.