Re^4: RFC: XML::Pastor v0.52 is released - A REVOLUTIONARY way to deal with XML

[aulusoy]

Yes, there are some resemblences to XML::Smart in that XML::Pastor will also use quite a bit of overloading, AUTOLOADING magic to make things work right. There's no TIE in this one though.

A few differences:

XML::Pastor uses a W3C XSD Schema to get information about the XML schema. XML::Smart seems to be gathering it from the XML instance.

XML::Pastor can do XSD schema validation.

XML::Pastor will end up with a tree of Perl objets that have the names of the global elements, Complex Types, Simple Types, and so on in the W3C Schema. Whereas XML::Smart: seems to have their own objects

[jettero]

Seems to me tie-ing is the way to go compared to code generation. How is code generation better?

I also much prefer DTD to XSD. I know DTD is getting phased out, but I'm probably not going to stop choosing DTD over XSD until I really have to. Is there going to be DTD support in Pastor eventually?

UPDATE: why does a generated object know more about the DOM tree than a tied object?

[aulusoy]

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.