note
aulusoy
<p>
Yes, I agree that a comparison chart would be useful. However, it will take some time to gather the information in an exhaustive way.
</p>
<p>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.</p>
<h1>PROS</h1>
<h2>XML::Twig comparison</h2>
<p>
[cpan://XML::Twig] is obviosuly an excellent module. The main difference with [cpan://XML::Pastor] is that, while working with [cpan://XML::Twig], the code needs to know about the 'xml'ness of the data, whereas, while working with [cpan://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.
</p>
<p>
Another difference with [cpan://XML::Twig] is the ability to validate against the original W3C Schema in [cpan://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.
</p>
<h2>XML::Simple comparison</h2>
<p>
In many respects, [cpan://XML::Pastor] goes much with the philosophy of [cpan://XML::Simple], with one <i>important</i> difference: [cpan://XML::Pastor] has full round-trip binding with XML. This means you can read and write XML with those native Perl objects. With [cpan://XML::Simple] you could do that, but if you have tried anything other than the most trivial, you know you really can't. Really, [cpan://XML::Simple] is useful for reading in a simple config file in xml maybe, but nothing more.
</p>
<p>
Another comparison with [cpan://XML::Simple] is that, [cpan://XML::Simple] produces one big deep data structure upon parser the XML file. In contrast, [cpan://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.
</p>
<p>Another drawback of [cpan://XML::Simple] is the multiplcity of child elements. In default mode [cpan://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 [cpan://XML::Simple] to produce only arrays for child elements, but then the whole thing becomes quite convoluted.
[cpan://XML::Simple] eleviates this problem by counting on the schema to produce the expected result. In reality, [cpan://XML::Pastor] will always prouduce a special kind of array for this situation => [cpan://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.
</p>
<p>Another difference with [cpan://XML::Simple] is the XSD schema validation in [cpan://XML::Pastor]. You can't do that with [cpan://XML::Simple].
<h1>CONS</h1>
<p>
Apart from some pending limitations, the two cons of [cpan://XML::Pastor] are:
</p>
<li>
[cpan://XML::Pastor] requires a W3C XSD Schema to work with.
</li>
<li>
[cpan://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.
</li>
<li>
Updated: [cpan://XML::Pastor] will slurp in the entire XML into memory, much like [cpan://XML::Simple]. This is probably not what you want for huge XML documents. You would be better of with [cpan://XML::Twig] or better yet <b>SAX</b> in that case.
</li>
<li>
Currently, [cpan://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, [cpan://XML::Pastor] is not good for working with a document written in a markup language such as XHTML, for example.
</li>
<p>Cheers, </p>
<p>Ayhan (trinculo)</p>
694627
694636