Slashdot Mirror
Perl & XML
The book starts out with a brief explanation of why XML and Perl are well-suited for each other. It then provides a teaser of things to come: an explanation of how to use the XML::Simple module. The first chapter concludes with some warnings and gotchas that seem a little premature since they have not really explained XML. Fortunately, most of these gotchas are covered in context later in the book.
The second chapter provides a whirlwind overview of XML -- covering its structure, DTDs, schemas, and XSLT (transformation). The discussion of XML in general, its history, and parts of an XML document are well done. They give someone who is familiar with static HTML the needed background to understand the structure of an XML document and the vocabulary used to describe it. Unfortunately, the discussion of where XML begins to distinguish itself from HTML, namely with DTDs, the new replacement for DTDs called schemas, and the transformation language XSLT, is too brief. They gloss over these topics with little explanation and few examples. That said, there are other books that do provide more in-depth coverage of XML (this book only promises an introduction).
The next five chapters cover Perl modules designed to process XML, starting with simple parsers and writers. Only methods and syntax relating to XML processing are explained. Therefore, if you are considering reading this book, you should be fairly comfortable with Perl and object-oriented (OO) interfaces to CPAN modules (nearly all the modules discussed provide OO APIs). Again, there are other books and perldoc documentation that cover Perl and it's OO features; so read them first if you are not familiar with OO Perl. If you are familiar with OO Perl, these chapters provide a good overview of the different ways XML can be processed (stream- and tree-based approaches), the advantages and disadvantages of each, and the Perl modules best suited for each approach. These chapters are the biggest strength of this book. The modules discussed in these chapters are by no means an exhaustive list of XML-related modules available from CPAN nor do the explanations of each module cover everything the module does. These chapters do, however, provide the reader with enough information that she can begin to process XML documents intelligently and know where to turn when she needs more information.
The next chapter, Chapter 8, covers XML tree iterators, XPath, XSLT, and XML::Twig. All of these topics are covered in a span of 16 pages (with only slightly over two pages dedicated to XSLT). Indeed, after reading the chapter, you may get the feeling that it was only included so the authors could cram more trite colloquialisms into the book. The short shrift given to these topics creates the impression, which is strengthened in the chapters that follow, that this book was rushed a bit to press.
Chapter 9 discusses applications of XML, including RSS and SOAP, and Chapter 10 is mostly example code. These chapters are intended to give you a feeling for what is possible without really giving you enough information to make it happen. The main problem with these chapters are the examples: the examples are long and the explanations are short. Thus, they are more useful as templates or a quick reference than for learning these topics in detail. Of course, the authors never promised you would be programming SOAP applications when you were done reading this book. And again, there are other books out there which discuss these topics in more detail. So the authors stay true to their promise throughout the book: they will introduce you to XML and tell you how to interact with XML using Perl, no more.
Personally, I found this book did, in general, give me enough information to get started using XML and pointed me where I needed to go to get more information. I am an experienced Perl programmer who is new to XML and comfortable with on-line documentation. This book seems to be written for people who fit this profile and who want to learn by doing (finding the answers to the "hard" questions as they arise). It does introduce a wide variety of XML-related topics and the Perl modules used to interact with them, which is what the authors promised to do in the preface. While it is by no means an authoritative text on Perl and XML, there is something to be said for keeping promises ...
Index As with most first-edition books, the index was adequate but not complete. For example, XML::Twig, which has an entire section covering it, does not appear in the index at all.
Contents
Preface
- Perl and XML
- Why Use Perl with XML?
- XML Is Simple with XML::Simple
- XML Processors
- A Myriad of Modules
- Keep in Mind ...
- XML Gotchas
- An XML Recap
- A Brief History of XML
- Markup, Elements, and Structure
- Namespaces
- Spacing
- Entities
- Unicode, Character Sets, and Encodings
- The XML Declaration
- Processing Instructions and Other Markup
- Free-Form XML and Well-Formed Documents
- Declaring Elements and Attributes
- Schemas
- Transformations
- XML Basics: Reading and Writing
- XML Parsers
- XML::Parser
- Stream-Based Versus Tree-Based Processing
- Putting Parsers to Work
- XML::LibXML
- XML::XPath
- Document Validation
- XML::Writer
- Character Sets and Encodings
- Event Streams
- Working with Streams
- Events and Handlers
- The Parser as Commodity
- Stream Applications
- XML::PYX
- XML::Parser
- SAX
- SAX Event Handlers
- DTD Handlers
- External Entity Resolution
- Drivers for Non-XML Sources
- A Handler Base Class
- XML::Handler::YAWriter as a Base Handler Class
- XML::SAX: The Second Generation
- Tree Processing
- XML Trees
- XML::Simple
- XML::Parser's Tree Mode
- XML::SimpleObject
- XML::TreeBuilder
- XML::Grove
- DOM
- DOM and Perl
- DOM Class Interface Reference
- XML::DOM
- XML::LibXML
- Beyond Trees: XPath, XSLT, and More
- Tree Climbers
- XPath
- XSLT
- Optimized Tree Processing
- RSS, SOAP, and Other XML Applications
- XML Modules
- XML::RSS
- XML Programming Tools
- SOAP::Lite
- Coding Strategies
- Perl and XML Namespaces
- Subclassing
- Converting XML to HTML with XSLT
- A Comics Index
You may also want to check out Erik T. Ray's home page, Jason McIntosh's home page, or O'Reilly's page for the book. 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.
I am a professional developer, working mostly with Perl. I work in the field of biology and bioinformatics, but have spent the last 8 years working as a web and database Internet developer. And, I own practically every O'Reilly Perl book ever published (not that I necessarily think they're all worth buying). So, now that you know where I'm coming from...
If you are preparing to do a serious amount of XML development, and you're in the process of determining a) which Perl XML modules on CPAN you want to use, and b) how to use them; and, you don't have a whole lot of time to spend tracking down the sometimes-hard-to-find documentation on these modules; then buying this book is a no-brainer. It covers all the major XML modules, how to use then and really helps you figure out when to use the different modules.
Even if you're not new to XML and Perl, this book would serve as an excellent refresher course on what XML tools are available out there for you... Maybe you haven't looked at your code in awhile, or want to update it to use a newer module from CPAN? Or, maybe you're looking for a better way to do it? Then, this book would definitely help you out.
While a fan of O'Reilly books in general, I'll be the first to admit some of them are more useful than others. I highly recommend this book, though, as it's actually useful, comprehensive and very well presented. I find myself cracking it open all the time, especially as my utilization of XML has grown more complicated. It has definitely earned its place in my Aqua Perl book collection.
Do you even lift?
These aren't the 'roids you're looking for.
... is not actually learning XML Learn HTML first; so you'll practice & develop a feel for it.
I wonder if this conforms to the dtd
a bit of xml i wrote -- xml comments look something like this
-->
- conversion complexity
- conversion errors
- vast storage requirements
- vast bandwidth requirements
The only benefit AFAIK is that applications from different vendors can use it to "talk" to each other. However, the applications still have to understand the same set of XML tags to begin with, then must conform to this hideous standard with all of its verbosity. Said applications would have been better off using a proprietary (read: efficient) binary storage format in the first place.Ban XML!
You realize that if I get an XML file, I can figure out what it is saying and decide what to do with it. With your ideal (binary) files, I need to reverse engineer the format.
With binary, I need permission to interoperate. With XML, I need a text editor (or print-out) and some common sense.
You worry all you want about the computer's efficiency. I use my machines to make my life easier. I don't jump through hoops to make the computer's life easier...
Taking troll bait,
Alex
Parsing XML indeed. I mean seriously, have any of you ever actually tried to impliment XML parsing? It's an order of magnitude slower than accessing a database, ten zillion times slower than reading a flat file ASCII database, and a trillion times more expensive (well, I'm exaggerating a bit) than reading in a text file with nested variable=value pairs.
Interoperability is great and all, but I think XML is nothing but hype.
Programmers, hear my cry! Spend your precious hours working on your program interface, your error-checking, your overall design and modularity, don't spend time worrying about a scheme with a fancy name that saves data like this: value.
Don't mod me up or down, I just want to foster a discussion about this. I mean, as a standalone programmer using Perl for a majority of their web application products, what benefit does XML give you other than buzzword compliance?
----
Slogan-free since April! We pass the savings on to you!
I think that if you are making a large enough (enterprise?) website that requires a serious amount of XML development, you should ditch perl altogether and write it in Java. Java already handles XML efficiently, and is a better choice for large apps.
If you are writing a smaller website that uses XML, sure, perl is a nice choice. But is the XML necessary?
And I have used (and still use) both perl and Java. I just view Java as a better choice for large web apps, and perl for small web apps and scripting.
Before I get hit with flames, please understand this is my opinion, not fact.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Any Perl/Python bilingual folks out there care to comment how the XML abilities of the two compare nowadays?
...A Six Figure Salary
The book is a little sparse, though. It's about the same thickness as Using csh and tcsh, so don't expect more than an overview of anything. In fact, it might be a little small for US$35.00 (although Bookpool has it for US$21.50). Another small gripe was that it covered parsing XML in far greater detail than generating XML (which was my task at the time I bought the book). Admittedly, parsing XML is typically what most people tend to do and is far more difficult that creating new XML, but I thought a little more coverage was warranted.
If you are faced with doing something involving XML and you're not sure what software bits are up to the task, then this is a good place to find out where to start. You could wind up looking elsewhere if you need lots of nitty-gritty details, but getting off on the right foot is a hard enough task and might be worth the price of the book.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
I can tell you from personal experience, you want to attack the soft, weak center of each element, or, even better, any undefended #PCDATA.
You'll want to avoid attacking the sharp angle brackets present on every element. Your sword blows will simply glance off, and then the XML document will jab you with the sharp corner.
Entities are another hidden danger. The ampersand prefix character is very quick and wiley, and even though it appears smooth and undefended, it can quickly turn on you, showing its offensive nature and bristling an array of pointy teeth. (Note, this depends on your screen font).
In short, attacking XML documents is risky, but with the proper strategy, can yield a nearly limitless supply of delicious data.
Ahem.
Does anybody know of any Perl XSLT module that allows Perl functions to be called from the templates? I.e., to format dates or stuff like that.
I personally didn't want a handholding book as I've worked with XML in other languages, but something that cut through the confusion of all the different ways to do the same thing.
This little book was perfect for me as it's a nice overview of what is out there and how to pick the right library for the job. Don't expect a complete enterprise application in this book - its for programmers that already know perl and the basics of XML and just need a jumpstart in using the libraries available.
No, Thursday's out. How about never - is never good for you?
- Conversion/translation complexity
- Syntax Errors
- Conversion errors
- Storage requirements (object files)
The only benefit AFAIK is that people can read the code better. However, the applications still have to understand the standard coding syntax, which comprises of a hideous amount of keywords and styles. Said applications would have been better off using Assembly (read: efficient) code in the first place.Ban C!
Please note the extremely sarcastic tone of this post.
Your complaints are old fashioned. Maintainability is a major overlooked flaw in Computer Science.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Only the kind of person who thinks XML is a great idea would propose doing in it Perl.
XSLT has the format-number() function, which could be used to format a date. I personally don't recommend mixing XSLT with anything. If you need your date formatted in a specific way, I recommend storing the data in a different structure and use pure XSLT. Rick
Making something out of nothing : MD5 ("") = d41d8cd98f00b204e9800998ecf8427e
In the year 2000 books will be replaced by a huge network of machines.
Gone will be the days of looking at page after
page.
You will be able to find just what you need in seconds!
The future will be great!
Books suck!
Hug a root today!
For a more detailed, and more depressing, take on the above, see http://www.xmlsucks.org/but_you_have_to_use_it_any way/.
Yes, it's a PDF. Unroll it - it's worth the effort.
To a Lisp hacker, XML is S-expressions in drag.
Does anybody know of any Perl XSLT module that allows Perl functions to be called from the templates? I.e., to format dates or stuff like that.
I'm looking into it for XML::LibXSLT, but it's non-trivial due to lack of docs and lack of context. Keep watching CPAN is all I can suggest!
Matt. Want XML + Apache + Stylesheets? Get AxKit.
As far as parsing it, there are libraries for that.
I found this book an excellent introduction for Perl programers who want (or have) to start processing XML. It cuts through the long list of XML modules on CPAN (485 results!) and gives you the basic techniques and tools you can use.
XML is really not that difficult to deal with but it can be a little intimidating. "Perl & XML" is written in a simple and direct style that gives the reader enough information to start writing code, and pointers to find more specific information once they have chosen the tools they need.
Armed with this book, The Perl-XML FAQ and Kip Hampton's column on XML.com any Perl programer can start working confidently with XML.
Look, that's why there's rules, understand? So that you think before you break 'em. (Terry Pratchett)
I am in the same boat as the author of this article - an experienced Perl programmer who needed to learn some XML stuff.
I found this book to be an outstanding resource that got me up to speed very quickly on both XML in general and that variety of ways that Perl deals with it.
Don't let the small size fool you, it is packed with useful information and well worth the price.
To properly process XML you need the DTD or the XML Schema that describes the XML. And since the DTD or XML Schema may be complex, you'll need an XML parser that can properly handle both the XML data and it's meta-description(DTD or XML Schema).
Of course you can solve simple problems by requiring all elements and/or attributes and applying simple ad-hoc rules for data types, but then you'll have to communicate those requirements and rules to other developers whose code produces/digests the XML. But in doing so you render the XML unreadable or at least incomprehensible, despite its being clear text.
Bottom line is, if you're on the sending or receiving end of XML data, you must have the DTD or XML Schema and you must use an appropriate XML parser to process the XML if you wish to reliably service requests.
Here are some other useful books on the subjects:
Learning XML - also an O'Reilly book
Perl in a nutshell - a good starter book on perl
Have you hugged your Karma Whore today?
Yeah, I'm with you... I'm still waiting on the XML lightbulb over my head to turn on. I just don't get it. Who wants to create a parser that can handle any arbitrary XML format? Gack!
And if I give you a CSV file with field names as the first row, can you grok that?
Cool, another book for the masses of unemployed techies to read, and buzzwords to put on their resumes. I'm sure this book will be great company for breaks at McDonald's.
"Tag libs", I'm not even sure what that is, but where I work we use a templating system with Perl, so the html monkeys can modify pages without any understanding of Perl, or programming in general.
Post some benchmarks, Apache+mod_perl can be very efficient, if you're competent efficiency will never become a problem.
Perl has plenty of database apis and plenty of cacheing mechanisms to use to speed up anything you need.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
I use XML as the interchange format for a web publishing system which publishes our internet web site (http://www.bms.com), but the data is actually stored in an oracle database. I have a perl object which handles all the fuss of getting/putting xml into the database.
As an interchange format XML is ideal; think of it comma separated files on steroids. When all your data can be serialized to XML you get the following benefits:
1. XML has rich data structures for complex info.
2. XML can be self describing.
3. XML is 100% portable.
Like HTML, people will discover uses for your XML files that you never thought of. Also, if you lose all the docs, you can read the XML in a standard text or unicode editor and figure it out. This is even better than comma separated, since most CSV files don't bother to include a first row field discription.
Like CVS, you can parse XML files with standard command line tools like grep. And in 100 years, all those Oracle tablespaces will require a lot of reverse engineering to get the data off it, while your text based xml files will still be parsable.
I agree though, with the general notion of the parent. Definitely don't do XML because it sounds cool. Use the best process for the job, and for many data related jobs, relational tables and SQL are best.
One thing you can do to improve speed; serialize your DOM objects using the Perl Storable module, and save along with your plain text versions. Then when you need to access the data, all you need to do is unserialize the object, which is a lot faster than reparsing.
Peace, or Not?
libxml has support for exslt, see http://exslt.org
; Bottom line is, if you're on the sending or receiving end of XML data, you must have the DTD
; or XML Schema and you must use an appropriate XML parser to process the XML if you wish to reliably
; service requests.
And therefore, you may as well use a streamlined / efficient exchange format... plus, you've lost the eXtensible feature.
XML is like circular logic... "you can define your own (schema / DTD / buzzword of today) and tags... that's sooo cool! And anyone can use your data like it's theirs."... but of course when they have to have the proper specifications and tools to use that data, you've lost the argument you started with... why not use a well established format to begin with??
I have recently learned XML/XSLT. I have been able to completely stop writing HTML code. I have been able to write all of my static web pages in XML and use XSLT (via Xalan) to generate the HTML. This is great... but I have only been successful with static web pages, not dynamic ones.
I would like to extend on this flexibility to dynamic web pages. I would like to have some type of CGI script that generates XML instead of HTML... then transforms the XML to HTML via XSLT; all on the fly. I have looked into XML::XSLT. Anyone have any other good solutions?
Instead, use PHP. It's alot easier, and more web-based. It's also faster, and more wide-accepted now.
There are two awesome books on the subject, I happen to own both (ordered via Amazon a week ago!). They are as follows:
- XML and PHP by Vikram Vaswani
- Professional PHP4 XML
Both are pretty good. I like PHP and XML better. It seemed like Wrox just wanted to have a book on the subject to keep up with O'R.www.cgisecurity.com/lib
www.owasp.org
Believe me, if I started murdering people, there would be none of you left.
Not much larger then a pamphlet, the book packs an amazing amount of info into its svelte form. It covers standards, tools, thought process, programming tips, and history in an effortless, breezy tone. In the best tradition of Oreilly books (particularily the Perl ones) you can sit down and read the book cover to cover and enjoy it, or jump in here and there for quick reference.
The authors manage to stir clear the problem that plagues so many XML books, the endless reams of theory without application. E.g., who the hell deals with PIs on a regular basis when parsing XML? And yet every book drones on and on about them, but when the time comes to actually parse a little xml, the example will be a cop-out, the XML equivalent of "hello world", parse this simple, 1 level deep key-value pairs in XML.
Not so with "Perl & XML", the author cover the theory of XML, but are much more interested in getting you coding and producing then being pendantic. The w3c as already got the monopoly of pendantism anyways.
I particularily liked the walk through of XML::RSS late in the book, for an example of how to build something very much real world, and useful without being overly complicated.
And, at least for right now, the book is up-to-date, miracle of miracles, chronicling important new changes in the Perl XML parsing story. (like the new Perl SAX work being done)
Contrast Perl & XML with New Riders' "XML & PHP", which I almost abandoned in the first 20 pages, when they tried to tell me that expat was a compliant SAX parser. Expat is important, and confusing, and its understandable for the authors' to feel defensive about PHP's xml toolset, but the solution isn't to lie, nor be blithely ignorant. The book continues on from there, totally disorganized with no sense of building upon what you've just learned. Also, an entire chapter is dedicated to WDDX? Who uses WDDX? And the authors contribute yet another half-assed PHP RSS parser to the world; is it possible to get negative karma for sharing source?
The reviewer mentions:
This seems to me to show a lack of understanding about much of the real work being done with XML. Its been my expirence that most XML parsing being done, particularily in a scripting environment, does not check against a DTD assuming one even exists. Plus covering DTDs, the proposed W3C Schemas, the increasingly popular challenger RELAX, plus Schematron, and others could easily have added another 100pgs to the book. And XSLT is a book unto itself (and in fact has an Oreilly book to itself).The reviewer suggests that the XPath coverage is included for the purpose of "trite colloquialisms", and while, I'm not sure what that means, I think the fact that Perl has high quality tools supporting standards like XPath is awesome, and very gratifying. Without that sort of work being done, Perl simply wouldn't be a competive choice with Python and Java as an XML processing language.
And finally " it is by no means an authoritative text on Perl and XML,", there are good authoritative books on Perl (lots of them), and good authoritative books on XML (a handful), this book bridges the gap, does it nicely in my view, and I personally love the shortness, the focus, and the form factor.