Michael,
In your case, what advantages does the intermediary steps of XML serialization/deserialization give you?
The way I've done that before (and the way I suspect Musea has done it) is:
1) grab data from 3.x (TCL)
2) emit plpgsql or pl/sql loader script (TCL)
3) load loader script into 4.x data model (pgsql/sql*plus)
If I want to repeat the migration, or the 4.x API evolves, I change the emitter in TCL.
What you're proposing, I think, is:
1) grab data from 3.x (TCL)
1x) emit XML (TCL)
2x) parse XML (TCL)
2) emit plpgsql or pl/sql loader script (TCL)
3) load loader script into 4.x data model (pgsql/sql*plus)
Yes you've improved the prospect of working on the project in parallel by presenting a data interface, but I would argue in this simple case of 3.x->4.x data migration it won't be worth the overhead of XML.
I've done this kind of thing alot, both using XML (when dictated by an XML-stored data source), and more typically the way I've described above. My hunch is that the XML pays off only when complexity grows ( a lot ), when a different team of people or people with a different toolset will do the loading, or when it's already a project requirement and the overhead is marginal.
