Slashdot Mirror
Perl and XML
With qualities like these, one might think that the marriage of Perl and XML would be total bliss, and the two languages would live happily ever after. In reality, however, the marriage has been far from perfect, and has produced an enormous number of kids: some uglier, some prettier, some simpler, some more sophisticated. Perl & XML is a good attempt to provide an overview of XML processing techniques existing nowadays in the Perl world.
The book does not even make an attempt to give you a brief introduction to Perl, and thus eliminates the weak point of trying to be another Camel book, as many publications in the field attempt to do. The logical assumption is that you know Perl and have heard something about XML. The first chapter of the book tells you why there are so many variations of Perl modules for XML processing, who is behind the well-known modules and why the interaction of Perl with XML has been rather disorganized. Indeed, a short visit to the XML section of CPAN brings up dozens of available modules, most of which characterized by some intimidating or non-descriptive names like SAX, Grove, YAWriter, etc.
The second chapter is titled "XML Recap"; the contents of the chapter, though, are good enough to be called "Concise but Informative Introduction to XML". Don't get your expectations too high -- O'Reilly has a whole bundle of books related just to learning XML, and thus a single chapter can barely touch the surface of what you might need to know, but it provides a good introduction to the world of markup, elements, namespaces, character encoding, processing instructions, schemas and transformations in XML.
Chapter 3 goes from theory to practice, and gives the reader an opportunity to try his first Perl script on XML data. The parsers covered in this chapter are XML::Parser, XML::LibXML, XML::XPath and XML::Writer. Document validation and well-formedness are also explained, and luckily enough this exact chapter is what O'Reilly Publishing decided to publish as a free chapter available on the Web. In this chapter, the authors make a distinction between stream-based and tree-based XML processing, and thus it doesn't come as a big surprise that the next four chapters are dedicated to examples of such processing.
Chapter 4, Event Streams, discusses the issues of processing XML document as a stream of data, where your application has to react to various input without really knowing where the end of the document is. XML::PYX and XML::Parser are covered in this chapter.
Chapter 5 shows examples of using SAX for XML processing with Perl, and also provides an overview of SAX history, which in a nutshell tells you that SAX has been designed for Java with its strong type checking and interface classes. It goes to explain that using it in Perl, which is known for its forgiving nature, thus requires a certain responsibility on the part of programmer. XML::Handler::YAWriter is also discussed in this chapter.
From stream processing, the authors take you to parsing XML trees. In this case, the document is assumed to be loaded into memory and Perl script can safely assume that the whole XML document has been loaded. XML::Simple, XML::SimpleObject, XML::TreeBuilder and XML::Grove are discussed in this chapter, with XML::Parser revisited.
DOM (Document Object Model) is another standard recommended by W3C and it is mostly concerned with how an XML document is stored in computer's memory. XML::DOM is discussed in this chapter with XML::LibXML revisited. The authors also provide a good overview of DOM standard.
The last three chapters deal with applications of Perl in XML data processing that go beyond stream and tree processing -- XPath and XSLT are explained with copious examples. Remember though, that both technologies have several-hundred-page books written about them, and thus several pages in a Perl and XML book can serve at best as good introduction. Chapter 9 deals with RSS and writing SOAP with Perl and XML, with XML::RSS and SOAP::Lite being explained. The last chapter deals with such issues as namespacing, subclassing and for Web designers provides a handy tutorial on converting your XML data into HTML via XSLT stylesheets.
The table of contents is posted on the publisher's Web site.
The first three chapters of the book are easy to read, since they provide a general overview of the data-processing world, history of XML with reference to appropriate events in the Perl community. However, data processing can hardly be called an exciting topic and thus bulk of the book is about routinely introducing particular modules, telling you what you can do with each, and then giving you an example of Perl code processing some XML document. The examples are apt and relate to some of data processing that some us had to do, i.e. shopping lists, address books, recipes, diaries of mad professors, etc.
The code examples are numerous, and if you get tired after looking at pages and pages of Perl lines, you better plan accordingly, as sometimes the subchapter consists of nothing more than an XML file and related Perl processing code with author's notes. For a 200-page book Perl and XML provides a great introduction into the area, provided you have good knowledge of Perl, using CPAN modules and just general knowledge about data processing. The book would probably have a more exact title if it had the word "Cookbook" in its name -- some might consider it a good reference. However, for those just getting acquainted with XML, another tutorial might be needed to get a full comprehension of XML's power.
You can purchase Perl & XML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It's so good, it gets two reviews!
This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
The same argument best used in favor of MySQL applies here as well: not everything has to be a super scalable, completely buzzword compliant, ninth-wonder-of-the-world engineering project. In fact, I'd wager that if you counted up all "developer time" spent in the US every day, you'd find that a large percentage of it is done on "throwaway" projects.
Lots of people just need to regex through logs and make a simple database and draw quick-and-dirty graphs and walk a MIB on a router and automate a build process and probe a firewall and so on and so on. They use perl, shell, whatever. And that's completely fine. Whatever works, works.
And XML, as he notes, it bloated by ivory-tower academic requirements and has made (and will make) zero headway in the Real World.
You couldn't be more wrong. XML couldn't be more real world. SOAP, office doc file formats, database output, jabber, web services, config files, the list goes on. Even nmap spits out XML if you want it to. Hell, we've been fighting to get it used at the university where I work because we've used it in the "real world" and know and like it...
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
It's also dumb to have any introductory XML material if you're not going to be serious about it. Which gives me an excuse to plug my favorite XML for beginners book, Harold's XML Bible, 2nd edition. Yeah, stupid title (who are you, Moses?), and the CD-ROM is badly put together (you'll need to convert some text files from Mac format!). But the book itself is very good. No assumptions at all about previous knowledge If you know jack about XML, or you understand the basics, but can't figure out how it's used, this is the book you want.
The author correctly points out that Perl is best suited for quick, unmaintainable hacks and not serious, large-scale engineering.
A common misconception about Perl, and I understand why you would think this way. Having written several large systems in Perl (as well as several smaller systems in which maintainability was key), I will point out these problems with your thesis:
1. If your quick hacks are unmaintainable, get another job. If your prototypes aren't good enough to turn into a product with a small amount of work, you're wasting lots of your own (presumably valued) time.
2. PDL belies your comments. Take a look at it. It's large, maintainable and certainly serious. Scientific computing is a dream with it.
I generally find that "large scale engineering" is the easy part. What's hard is applying sound engineering and scientific principles to your code. You can do that as easily in C as in Perl as in Python as in Eiffel. It's a little harder in C++, though honestly not by much, because of the action-at-a-distance nature of C++'s object model.
Oddly, Java has a problem in neither area. Java's problems have very little to do with the language itself (which is an acceptable C derivative, if you want a C derivative with GC) and more to do with what Sun does with it, and how that has trained its users to approach it.
Perl's biggest problems are the following:
1. Incomplete object model. This was deliberate, and has given Perl6 the ability to form its object model out of a decade of best practices by those who "rolled their own" in Perl5.
2. Circa AWK/shell subroutine semantics. Also a major aim of the Perl6 effort, this is a subtle thorn in Perl's side. It's easily overcome once you get used to it, but leads to nearly impossible-to-optimize function calls in average code.
3. The lack of true compilation of the language leaves software developers with very few options in terms of shipping programs. Again one of the first aims of Perl6
See the Perl6 theme? Wait for it... it will rock your world.