That reminds me another module, called XML::Tie, that we had developed with a colleage of mine. That one naver made it to CPAN but I probably still have the code around if you are interested.
The interesting thing is that I had the same hunch some years back (2002-2003).
XML::Tie would work with all sorts of dark magic to make a DOM tree look like a tree of Perl hashes. In fact, XML::Tie worked very well for reading XML in and dealing with it.
Where XML::Tie failed miserably though, it was when it was time to set values in the DOM. Since the hash made no difference between attributes and child elements, XML::Tie had to take wild guesses to be be able to put the right data in the right XML node in the DOM. The resulting code would still be valid XML, but not necessarily what you had intended it to be (You could see things in an attribute whereas it should have been really in a child element or vice versa.
This sort of thing is fine when it's only your program that reads/writes the XML, but when you have to share it with others, then the nightmare starts. Because usually, there is contract, i.e. schema, to abide by when you deal with the external world. Then XML::Tie was useless.
Code generation from a schema completely solves this problem. You still deal with native Perl objects (with fields in a hash) when you get/set values, but your object knows how to write it into a DOM tree, because it knows which one is an attribute, which one is an element an so on. Furthermore, you can validate against the schema to make sure.
UPDATE: The generated object doesn't know more about the DOM than the tied object. It knows more about the schema. The DOM tells you what is stored as XML. Schema tells you what ought to be.
The down side is that now you are tied, as a programmer, to an XSD schema. Lucikly, it's not that hard to make one up even after the fact.
| 