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

[aulusoy]

Yes, I agree that a comparison chart would be useful. However, it will take some time to gather the information in an exhaustive way.

I will try to be brief and to the point here at this time. But I will try to post a more comprehensive comparison chart sometime soon.

PROS

XML::Twig comparison

XML::Twig is obviosuly an excellent module. The main difference with XML::Pastor is that, while working with XML::Twig, the code needs to know about the 'xml'ness of the data, whereas, while working with XML::Pastor, the program needs to know -almost- nothing about the xmlness of the data. For the user code, XML elements and attributes are just native Perl objects with accessors and/or regular hash and array access.

Another difference with XML::Twig is the ability to validate against the original W3C Schema in XML::Pastor, and this without needing the schema at run time. By the way, schema validation at run time is stunningly fast, because there is no schema parsing necessary.

XML::Simple comparison

In many respects, XML::Pastor goes much with the philosophy of XML::Simple, with one important difference: XML::Pastor has full round-trip binding with XML. This means you can read and write XML with those native Perl objects. With XML::Simple you could do that, but if you have tried anything other than the most trivial, you know you really can't. Really, XML::Simple is useful for reading in a simple config file in xml maybe, but nothing more.

Another comparison with XML::Simple is that, XML::Simple produces one big deep data structure upon parser the XML file. In contrast, XML::Pastor will produce native Perl Objects for each element and attribute with names and methods (accessors and much more) that correspond to the actual data. Nothing stops the monk from coding additional methods for those objects (using the same package names that resulted from code generation), hence building logic around the native object.

Another drawback of XML::Simple is the multiplcity of child elements. In default mode XML::Simple will produce a hash for a single occurence of a given child node, but will produce an array of hashes if that node appears multiple times. This is very annoying. In another mode, it is possible to instruct XML::Simple to produce only arrays for child elements, but then the whole thing becomes quite convoluted. XML::Simple eleviates this problem by counting on the schema to produce the expected result. In reality, XML::Pastor will always prouduce a special kind of array for this situation => XML::Pastor::NodeArray , which has magical properties. If you access it like a hash or with a method call, it will pass it on to the first element. If you access it like an array, you can too. So, you never need to know.

Another difference with XML::Simple is the XSD schema validation in XML::Pastor. You can't do that with XML::Simple.

CONS

Apart from some pending limitations, the two cons of XML::Pastor are:

XML::Pastor requires a W3C XSD Schema to work with.

XML::Pastor performs code generation, which could be considered clumsy by some. Note that this could be done at run-time, too, albeit paying a slight performance penalty at code start-up (the generated code will run equally fast, though.

Updated: XML::Pastor will slurp in the entire XML into memory, much like XML::Simple. This is probably not what you want for huge XML documents. You would be better of with XML::Twig or better yet SAX in that case.

Currently, XML::Pastor is only good for working with DATA style XML (without mixed mark up). This basically means that an element either contains only text or only child elements, not both mixed. So, XML::Pastor is not good for working with a document written in a markup language such as XHTML, for example.

Cheers,

Ayhan (trinculo)

[holli]

Looks nice but, are you planning to support other XML schema languages like Schematron or Relax NG? I'm asking because XSD is so freaking ugly that I always put my digigloves on before touching it ;-)

A side note for psini who considered the OP being a duplicate: It's not. The version in the code section comes with additional code examples.

[aulusoy]

Schematron and Relax NG are a bunch that I like a lot for checking structure.

Unfortunatly though, neither of these schemas contain enough information for generating the code.

A way of supporting these would be using them just for validation and not for the actual code generation. But that means you would still need an XSD schema for the code generation.

I agree that XSD schemas tend to be utterly ugly. Using a graphical aidfor designing the schema helps a lot. Here's a bunch:

• editix -- freeware
• Oxygen -- Personal/Academic version below $50
• XmlSpy -- The best. But runs only on windoz. Around $500 I think.

[ambrus]

So it's similar to XML::Smart which also lets you access xml as overloaded-tied hash-array-scalars?

[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?