Basically what you are doing is applying a transformation from an RDBM schema to some specific XML schema. XSLT is very good at transforming XML to XML, or XML to text. Obviously its not so good at the reverse mapping of 'anything' into XML. There's a program called pyana though which allegedly enhances XSLT transforms with python functionality, but there, still, I think the python is constrained to work with a source XML document rather than 'anything'.

For work recently though, I've been trying to make adhoc mappings of data from PostgreSQL and Oracle databases into an XML metadata schema. Basically what I did was take an instance document of the desired target XML schema and pepper it with elements like and containing raw python code or SQL expressions respectively. This template is fed into a python-based XML parser that evaluates the SQL and python elements and replaces those elements with the result of its evaluations. Consequently this is an 'anything' to XML transformer, and its limited purely by python's limitations (well, that and my crap code).

But anyway, to do it properly it also requires, and has, program constructs like and , which you would recognise as XSLT constructs. Probably it would benefit from more XSLT-like functionality like and elements.

It would be cool if something like this was written/designed and spec'ed by experts though. Be nice to use something robust from off-the-shelf ...

As part of your subsequent downstream processing, would you next transform this database-centric XML to a more concise form?

For example, rather than go straight to VCard from the XML above, make it a two-step process with something like this in the middle...

<Contacts><Contact><Name>Norm Walsh</Name><Address><Line>221B Baker Street</Line><City>London</City><PostalCode>NW1 6XE</PostalCode><Country>England</Country></Address></Contact> ...

I find that 2-step process hides a fairly ugly but not difficult transform in the first part, leaving an ideal input for the final transform (to VCard) output. Makes the whole transform more maintainable.

If only there were an XML transform pipeline language to tie it all together, oh wait... ;)

With this particular XML, you could argue for another initial transform that just throws away the data elements you're not interested in to simplify the input. That could be a pretty common operation with database-centric dumps like this one. You could then choose to drive the data element selection with a common transform and an XML file to make the field selections. And the pipeline document would be common as well among this type of transform.

Are thoughts like these guilty of using an XML toolset hammer? Perhaps. I think your approach is worthwhile and generally useful, therefore these 'extensions' might also be.

I'd be interested in your thoughts, because you wield an exceptionally mighty XML hammer! Thanks.

In this particular case, I have an existing vCard-to-something else toolchain, so I went from the SQL dump to vCard. But as a general rule, I'm in favor of using a series of simple transformations instead of one complex transformation where practical.