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

[aulusoy]

I must admit you have a point there. I probably took a shortcut in order to get a point across in the least number of words. For those who do know about CASTOR, just a mere sentence would ring enough bells to get the meaning acroos. For those who don't, there is now enough information in this thread I think.

'Revolutionary' deson't necessarily mean excellent or good. That's not for me to judge anyway. Revolutionary just means that there is an abrubt change in the way things work.

In this respect, I tend to stick to my idea. The reason is that XML::Pastor introduces a whole new way of dealing with XML by generating native Perl classes starting from a W3C XSD schema. The resulting objects are even easier to manipulate than what results from XML::Simple on one hand. Furthermore, writing back to XML conformant to the original schema is taken care of.

If you require more information, I would suggest that you check out the documentation of XML::Pastor or even download it and play with it.

By the way, without being too critical, I would like to say that I try to keep myself up to date on what's going on out there even when it's not related to Perl. It doesn't mean I like Java per se, but it means I would like to be open-minded to new ideas.

[sundialsvc4]

A curious parenthetical comment in that last paragraph... I doubt that anyone who has been in this business for any length of time whatever “knows only about Perl.” It seems rather odd even to suggest it. Bloop! Off my (duck's) back it went. Splash.

One thing that, I think, keeps bumping against my head on this one is that you compare to XML::Simple ... which is, even on a good day, “just that.” If you are doing heavy-lifting XML work in Perl, you probably are not using Simple. How does that affect the self-assessment you present? Does it?

The approach that you describe is what is sometimes called “pragmatic programming.” It's “machine generated software,” and it's not that new. It may well be the fact that you describe it in such glowing terms, and yet against one of the weakest XML-support libraries in CPAN (good though it is...), that makes me squint a little bit over my new bifocals “variable focus lenses.”

[aulusoy]

So, if what you say is correct, that is, people are interested or at least know about other technology as well, then I was not that wrong assuming that they might also know about Castor. In that case one wonders why yourself know nothing about it, although it has been around for some time now and is quite popular for dealing with XML in Java.

Why the comparison with XML::Simple? The answer is simple. Despite its many limitations and shortcomings, I have always liked the philosophy of XML::Simple, that is, representing XML data as native Perl data. Most of the other XML modules (XML::Writer, XML::Twig, ...) don't do that. Although they may have other merits, you need to know that you are working with XML when you access XML.

So, I have compared to the module which I believe has got the idea right in the first place. It's true that XML::Simple has got quite a few limitations. But many of those limitations are actually overcome with XML::Pastor. So, I see no reason for not using it for some heavy duty XML work (apart from the fact that the code is not that mature yet). By the way, the only area where XML::Pastor is weak compared to XML::Twig is when working with huge XML documents and mixed content. You need to revert to Twig or SAX when you are working on huge documents. Otherwise, you can do pretty much everyhting. There is even some basic namespace support.

Coming back to the discussion about 'revolution'. It's true => code generation is not a new concept. Furthermore, XML is not new, XSD is not new, Perl is not new. However, "Dealing with XML in Perl via code generation from XSD" is a completely new way of doing things.

[Jenda]

XML::Pastor: "Dealing with XML in Perl via code generation from XSD"

XML::Compile: "Where other Perl modules (like SOAP::WSDL) help you using these schemas (often with a lot of run-time XPath searches), XML::Compile takes a different approach: instead of run-time processing of the specification, it will first compile the expected structure into a pure Perl CODE reference, and then use that to process the data as often as needed."

Looks to me like there are some similarities. While XML::Pastor seems to generate a set of classes that you can then use to build up or modify the XML, XML::Compile just generates some code that transforms between XML and Perl datastructure. I think both make a lot of sense. And both are good tools to keep in the toolbox. I don't think it's wise to restrict oneself to just one XML processing module.