Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

XML and Perl

timothy posted more than 11 years ago | from the texty-bits dept.

Perl 138

davorg writes "One of Perl's great strengths is in processing text files. That is, after all, why it became so popular for generating dynamic web pages -- web pages are just text (albeit text that is supposed to follow particular rules). As XML is just another text format, it follows that Perl will be just as good at processing XML documents. It's therefore surprising that using Perl for XML processing hasn't received much attention until recently. That's not saying that there hasn't been work going on in that area -- many of the Perl XML processing modules have long and honourable histories -- it's just that the world outside of the Perl community doesn't seem to have taken much notice of this work. This is all set to change with the publication of this book and O'Reilly's Perl and XML." Read on to see how well Davorg thinks this book introduces XML text processing with Perl to the wider world.

XML and Perl is written by two well-known members of the Perl XML community. Both are frequent contributors to the "perl-xml" mailing list, so there's certainly no doubt that they know what they are talking about. Which is always a good thing in a technical book.

The book is made up of five sections. The first section has a couple of chapters which introduce you to the concepts covered in the book. Chapter one introduces you separately to XML and Perl and then chapter two takes a first look at how you can use Perl to process XML. This chapter finishes with two example programs for parsing simple XML documents.

Section two goes into a lot more detail about parsing XML documents with Perl. Chapter three looks at event-driven parsing using XML::Parser and XML::Parser::PerlSAX to demonstrate to build example programs before going to talk in some detail about XML::SAX which is currently the state of the art in event-driven XML parsing in Perl. It also looks at XML::Xerces which is a Perl interface to the Apache Software Foundation's Xerces parser. Chapter four covers tree based XML parsing and presents examples using XML::Simple, XML::Twig, XML::DOM and XML::LibXML. In both of these chapters the pros and cons of each of the modules are discussed in detail so that you can easily decide which solution to use in any given situation.

Section three covers generating XML documents. In chapter five we look at generating XML from text sources using simple print statements and also the modules XML::Writer and XML::Handler::YAWriter. Chapter six looks at taking data from a database and turning that into XML using modules like XML::Generator::DBI and XML::DBMS. Chapter seven looks at miscellaneous other input formats and contains examples using XML::SAXDriver::CSV and XML::SAXDriver::Excel.

Section four covers more advanced topics. Chapter eight is about XML transformations and filtering. This chapter covers using XSLT to transform XML documents. It covers the modules XML::LibXSLT, XML::Sabletron and XML::XPath.

Chapter nine goes into detail about Matt Sergeant's AxKit, the Apache XML Kit which allows you to create a website in XML and automatically deliver it to your visitors in the correct format.

Chapter ten rounds off the book with a look at using Perl to create web services. It looks at the two most common modules for creating web services in Perl - XML::RPC and SOAP::Lite.

Finally, section five contains the appendices which provide more background on the introductions to XML and Perl from chapter one.

There was one small point that I found a little annoying when reading the book: Each example was accompanied with a sample of the XML documents to be processed together with both a DTD and an XML Schema definition for the document. This seemed to me to be overkill. Did we really need both DTDs and XML Schemas for every example. I would have found it less distracting if one (or even both) of these had been moved to an appendix.

That small complaint aside, I found it a useful and interesting book. It will be very useful to Perl programmers (like myself) who will increasingly be expected to process (and provide) data in XML formats.


You can purchase XML and Perl from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

138 comments

Sorry! There are no comments related to the filter you selected.

ER (-1)

Anonymous Coward | more than 11 years ago | (#5189586)

Or what should be called.. "How to switch to MS Access and VB"

who else (-1)

Anonymous Coward | more than 11 years ago | (#5189602)

has a woody for banner ads

what the fuck (-1)

Anonymous Coward | more than 11 years ago | (#5189621)

i have gotten 1st 2nd 3rd

It's a great book about a terrific subject (-1, Troll)

PhysicsGenius (565228) | more than 11 years ago | (#5189629)

Perl and XML. XML and Perl. It's a marriage made in heaven. One of them uses a cryptic, machine-readable-only encoding to concisely depict data and programs. The other is a markup language.

Re:It's a great book about a terrific subject (1)

zapfie (560589) | more than 11 years ago | (#5189644)

Perl is a markup language?

Re:It's a great book about a terrific subject (0)

Anonymous Coward | more than 11 years ago | (#5190137)

You are an idiot. HTH.

what the hell (-1)

Anonymous Coward | more than 11 years ago | (#5189633)

fouth too?

Nice (1)

Gortbusters.org (637314) | more than 11 years ago | (#5189662)

Though the reviewer didn't think so, I like it when DTD and XML Schema examples are side by side. Having looked at DTD's for quite some time now, have to change gears to the new standard of using XML schemas.

Would be nice to have a book with more than just one chapter on web services. There are a plethura of Java/C# web services books out there, but it's hard to find one on there just for Perl, PHP, etc.

Re:Nice (5, Informative)

DaRobin (57103) | more than 11 years ago | (#5189738)

Would be nice to have a book with more than just one chapter on web services.

You might be interested in Programming Web Services with Perl [oreilly.com] then.

I'd buy it ... (1, Funny)

B3ryllium (571199) | more than 11 years ago | (#5189663)

... but I thought Perl was a write-only language? How can I be expected to read the book, if it's just gibberish like Perl? Geez. :) (Okay, fine - I admit it - I kinda like Perl. But that's another story.)

Re:I'd buy it ... (1)

nmtratman (49617) | more than 11 years ago | (#5189819)

Perl excels at text processing in part because Perl excels at regular expressions. They are part of the language, instead of a tacked-on library interface. It is easier to extract arbitrarily formatted text using Perl, while other languages have a more difficult time, since the regular expressions don't come naturally in them.

XML has a regular, structured format. It is easily parsed, but almost no one parses it directly. They use a model which represents the data, usually some form of DOM or SAX. Libraries are present in most languages. The need to rely heavily on regular expressions isn't there, and it allows people to choose other languages without paying a huge development penalty.

Not that there isn't a development penalty, but the penalty is mostly same as developing under that language normally. Developing in C will generally take more time than in, say, Perl, Tcl, or Python, because of low-level issues that the other languages don't have. The resulting code, though, isn't necessarily uglier or different in structure.

There are lots of pages on Perl and XML (check google if you don't believe me), but it just seems that Perl doesn't have the overwhelming advantage on other languages on this subject. That's not to say it isn't useful. But if I were to do XML processing, I probably wouldn't be using Perl.

Unless it was to process nasty, arbitrarily formated text into XML.

If you really want your Perl script to be write only, use "chmod 0333 myScript.perl". Nifty language that is constantly coaxing you to the dark side, begging you to give in to your inner desires, to write code that will rip the sanity from those who look at it!

Re:I'd buy it ... (1)

B3ryllium (571199) | more than 11 years ago | (#5189988)

I haven't looked in to XML on Perl (although I had a friend write a regexp-based parser of a fairly large XML feed), but I did look passingly at XML in PHP ... it seemed like PHP had a fairly decent implementation. I plan to explore the PHP version in the future, but if the need exists, I'm always open to Perl. :)

I've never even looked at Python code, but I hear it has a few ... oddities ... over other languages. I've never heard anyone say it sucks, though, so that's a plus. :)

Who cares about Perl? (-1)

Anonymous Coward | more than 11 years ago | (#5189664)

"that the world outside of the Perl community doesn't seem to have taken much notice of this work"

Thats because most programmers have no need of Perl. Just because people go on and on about websites, doesn't mean that its responsible for the majority - or even a significant - amount of code written each day by most coders.

Re:Who cares about Perl? (1)

GombuMstr (532073) | more than 11 years ago | (#5189857)

Uniquely enough our data processing that has nothing to do with the web is heavily constructed with perl. We love the flexibility of it. It doesn't take to long for a new person to figure out how our daily processing works.

In fact I have been looking into perl-xml for processing of scalc spreadsheets that our stores send to us every day. It has been a valuable tool and we would be up a creek with Windows tools trying to do the exact same thing.

--Travis

You lost me on the incredible leap of logic... (0, Insightful)

rand.srand() (243903) | more than 11 years ago | (#5189678)

As XML is just another text format, it follows that Perl will be just as good at processing XML documents.

Since my pasta maker is good at making pasta, and ice cream and pasta are both foods, it follows my pasta maker will be just as good at making ice cream.

Re:You lost me on the incredible leap of logic... (3, Insightful)

sheriff_p (138609) | more than 11 years ago | (#5189984)

Ah no, see, you forgot to read the first line:

"One of Perl's great strengths is in processing text files."

Perl is good at handling text files. XML is a text file. Therefore, Perl is good at handling XML.

As opposed to:

My pasta maker is good at making pasta. Pasta is a type of food. Ice-cream is also food. Therefore, my pasta maker is good at making ice-cream.

Does that help?

Re:You lost me on the incredible leap of logic... (1)

Jagunco (547686) | more than 11 years ago | (#5190078)

Perl's ability to process text files don't make DOM or SAX any easier (or better) than any other implementation. It's plain dumb to say that since XML files are text files because perl is good at processing text files (sic) so perl is good for processing XML documents.

Re:You lost me on the incredible leap of logic... (1)

Requiem (12551) | more than 11 years ago | (#5190719)

No, it actually makes perfect sense.

Consider the following:

for all elements e of a set x, y(e).
z belongs to x.
therefore, by definition, y(z).

Note the "by definition" part.

Re:You lost me on the incredible leap of logic... (1)

C Joe V (582438) | more than 11 years ago | (#5190982)

Note the "by definition" part.

y(z) does not follow "by definition" unless your first assumption is the definition of y. It is not the definition of perl that it is good at processing text files. It is at most a fact about perl.

In fact I don't think it makes sense to claim "For all text files T, perl is good at processing T." That's pretty nonsensical if you ask me. And I don't think it's even true that "For all operations O on text files, perl is a good implementation language for O." If this were really true, then it would follow that perl is a good language for any operation that assumes its input is an XML file, which is what the original poster seemed to mean.

What's more reasonable is to relax the statement to "There exists a fairly large class C of operations on text files such that perl is a good implementation language for any operation O in C." But it does not follow from this that perl is good for XML, unless the intersection of C and "XML operations" is a fairly large portion of the latter set.

CJV

Re:You lost me on the incredible leap of logic... (1)

andy@petdance.com (114827) | more than 11 years ago | (#5190713)

Of course, many (most?) of the Perl XML modules aren't doing the parsing directly, but calling the expat library, which is not Perl at all.

Re:You lost me on the incredible leap of logic... (0)

Anonymous Coward | more than 11 years ago | (#5189989)

if x is a subset of y and you can do z to y, you
can do z to x.
in other words, its not that text and xml are both text formats but that xml is a subset of
text.

Re:You lost me on the incredible leap of logic... (3, Insightful)

IpalindromeI (515070) | more than 11 years ago | (#5190351)

Except that your syllogism is faulty, whereas his is not.

His:
1. (from earlier in his post) Perl is well suited for processing all text formats.
2. XML is a text format.
3. Therefore, Perl is well suited for processing XML.

Yours:
1. Your pasta maker is good at making pasta.
2. Pasta is a type of food.
3. Therefore, your pasta maker is good at making all types of food (for example, ice cream).

You can see that he went from general to specific, whereas you went from specific to general. He argues that being able to do all things in a given set (process all text formats) gives the ability to do one of the things in that set (process a particular text format). You argue that being able to do one thing in a set (make a particular food) gives the ability to do all things in the set (make all foods).

You could save your argument by changing your middle point to be "All foods are a type of pasta," and then your conclusion becomes trivially true. But you'd also have to get everyone to agree that ice cream is pasta.

XML is NOT just text! (5, Insightful)

Anonymous Coward | more than 11 years ago | (#5189685)

The whole point of XML is that it is NOT just a string of text. That's why Perl isn't particularly any better than Java or C++ or VB or whatever for processing XML - you're going to be using a library that gives you SAX or DOM access to your XML, and you'll never need to know that there's a text representation being serialized onto some wires somewhere.

Re:XML is NOT just text! (3, Interesting)

DaRobin (57103) | more than 11 years ago | (#5189872)

True and then not so. Perl's flexible data structures and OO make it a simpler approach than languages that think XML == Object Serialisation. It is also very likely that a lot of what you're going to see flying by in SAX or hanging around in DOM will be text. Sometimes lots of it, sometimes text that has non-XML structure and requires microparsing.

But anyway, what really puts Perl ahead of the pack (together with Python, the only viable competitor I've tried -- Java is really lagging these days) is its large wealth of SAX (and to a lesser degree, DOM) tools. All sorts of very useful filters can be grabbed, complex pipeline management is a given, the SAX writing framework is cool, there are SAX parsers for many non-XML formats, etc.

Re:XML is NOT just text! (0)

Anonymous Coward | more than 11 years ago | (#5190251)

according to this paper on soap [rutgers.edu] , your argument doesn't hold water. Perl xml parsing is actually equal but not better than Java or .NET.

Re:XML is NOT just text! (3, Insightful)

consumer (9588) | more than 11 years ago | (#5189894)

Let's see...

  • Editable in emacs (or vi). Check.
  • Grep-able. Check.
  • Diff-able. Check.
  • Understandable to the naked eye. Check.

Sure smells like text to me.

Re:XML is NOT just text! (3, Insightful)

Anonymous Coward | more than 11 years ago | (#5189951)

What you're looking at there is one possible representation of an XML document. What you can see is NOT XML. XML is an idea - a hierarchical data structure. If you're manipulating some XML programatically, you should be manipulating this hierarchical data structure, and you'll be using some sort of API (SAX or DOM, probably) to do so. You should emphatically NOT be manipulating text strings. Any code of the form
tag = tag + "</" + tagname + ">"
means you're doing it wrong.

So, no, XML is not editable in emacs (or vi), grep-able, diff-able or understandable to the naked eye. Go and think about it again.

Re:XML is NOT just text! (2, Insightful)

EvlG (24576) | more than 11 years ago | (#5190125)

I think it is interesting to note that this is precisely the reason that XML is poorly suited for any task that requires human intervention.

Re:XML is NOT just text! (1)

nosferatu-man (13652) | more than 11 years ago | (#5190334)

... which of course kicks the chair out from under of one of the primary arguments of the XML snakeoil salesmen, that XML is "human-readable", to say nothing of "human-editable".

'jfb

Re:XML is NOT just text! (1)

ClosedSource (238333) | more than 11 years ago | (#5190627)

I'm not sure that "human-readible" is a primary argument for XML, but I don't think it matters much. ASCII codes aren't "human-readible" either, text editors convert them to characters we can read.

You can't efficiently use a text editor to edit pictures, sounds or movies but this doesn't limit our ability to edit them using more appropriate tools.

If I were going to edit or process XML, I would use the best tool for the job and if that's not a text editor, so what?

Re:XML is NOT just text! (2, Insightful)

cygnus (17101) | more than 11 years ago | (#5191148)

you're doing it wrong.

...

So, no, XML is not editable in emacs (or vi), grep-able, diff-able or understandable to the naked eye. Go and think about it again.

yes it is.. just because you claim that "you're doing it wrong," doesn't mean it's impossible.

xml is text just as much as html is.. are you going to tell me that html isn't editable in emacs or human-readable? how is html different from DocBook, for example?

Re:XML is NOT just text! (old school answer) (1)

fishdan (569872) | more than 11 years ago | (#5190276)

Wow, are we arguing about what is text? Now that is an old school computing arguement that I'm not sure the kids will appreciate! (no offense intended.)

My $.02 : XML is composed of text because it only allows ascii characters. Thats it. Well-formed XML "the language" requires more definitions, but an xml "file" is just another text file format. You're talking about nondeterministic finite automata [unimi.it] quintuple that specifies how XML is parsed. understood, etc. But within that quintuple, I is the set of all ascii characters >= 32 and 128. At least I think that's true. Can someone post if I'm wrong? I appreciate learning of my misconceptions.

Re:XML is NOT just text! (old school answer) (0)

Anonymous Coward | more than 11 years ago | (#5190570)

XML allows unicode characters.

Re:XML is NOT just text! (old school answer) (1)

fishdan (569872) | more than 11 years ago | (#5190675)

Good to know, thanks.

Re:XML is NOT just text! (2, Insightful)

orcrist (16312) | more than 11 years ago | (#5191493)

The whole point of XML is that it is NOT just a string of text. That's why Perl isn't particularly any better than Java or C++ or VB or whatever for processing XML - you're going to be using a library that gives you SAX or DOM access to your XML, and you'll never need to know that there's a text representation being serialized onto some wires somewhere.

I'll respond to you though many others are making similar arguments. First of all, when you say "XML is NOT just text!" do you mean "XML is NOT merely text" or "XML is not solely text"? I'll agree with the first, but the second is generally not true.

What noone seems to be mentioning is what you get out of those libraries: you get the entire structure in nodes thanks to the library's parser, but what are the contents of those nodes? Text! You might argue that the element names and most of the attributes are either defined by the dtd/schema, etc. but at least CDDATA will often be abitrary text. And, at least in my experience (mostly web-based applications), there will often be a need to process some of that text, e.g. extract links which are embedded in the text, convert newlines to <br>s, and many other things. And then, isn't it handy when the language reading the contents of those nodes has strong text-handling abilities?

Just a thought.

-chris

Natural? (1, Redundant)

CaseyB (1105) | more than 11 years ago | (#5189708)

As XML is just another text format, it follows that Perl will be just as good at processing XML documents.

Not really. If you're using XML as "just another text format", then you're making a funamental mistake. Within your software, you should always be treating XML as a hierarchical data structure, not as a text stream. Apart from manipulating CDATA or attribute value text, Perl has no particular strength with XML.

Re:Natural? (3, Informative)

mortonda (5175) | more than 11 years ago | (#5189761)

Not really. If you're using XML as "just another text format", then you're making a funamental mistake. Within your software, you should always be treating XML as a hierarchical data structure, not as a text stream. Apart from manipulating CDATA or attribute value text, Perl has no particular strength with XML.

Indeed, the perl only XML libraries are quite slow. I believe most of the quality perl XML handling is done by modules that use C libraries to do the grunt work. However, if the data in the XML itself is text data, then of course, perl and XML are a good match. Add SOAP and mod_perl into the mix, and you got some very nifty tools.

If Larry Wall gave his wife a gift... (-1, Troll)

digitalgimpus (468277) | more than 11 years ago | (#5189715)

If Larry Wall gave his wife a gift...

Would it be a Perl Necklace? ;)

Re:If Larry Wall gave his wife a gift... (-1)

Anonymous Coward | more than 11 years ago | (#5189725)

If he had a boat, would he park it in Perl Harbour?

What a dumb-assed question.

Re:If Larry Wall gave his wife a gift... (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5189746)

That's harbor, you fucking British Nazi.

In Soviet Russia... (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5189722)

...the Perl XML's you!

Re:In Soviet Russia... (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5189724)

I XML'd your mom.

Petal (3, Informative)

Chris Croome (24340) | more than 11 years ago | (#5189727)

One new, and cool, Perl XML module that people might not know about is Petal [cpan.org] (PErl Template Attribute Language).

It is an implementation of the Zope TAL (Template Attribute Language) specification [zope.org] and it basically allows you to create XML templates where all the templating commands are just attributes of existing tags.

This allows things like XHTML templates which are very WYSIWYG friendly since the editors don't do anything with attributes that they don't know about.

Formalised features of Perl (in this book?) (-1, Troll)

Rat Tank (612088) | more than 11 years ago | (#5189736)

(Moderators: skip to note at the end before you moderate this ;) )
I've programmed for some time in Perl, but at no time has this been anything to do with the CompSci degree I'm studying; no course even mentions it. Why is this? Perl doesn't seem to have much respect in educated programming circles, and I think this is why;
It's type system is not entirely sound. Inference upon the typing rules (which aren't formally stated anywhere; I had to derive them from the sourcecode) can lead to propositional contradictions.
It is most certainly _not_ Turing complete (trivially provable); hence not all algorithms can be implemented in it that you could with a Turing complete language like Java or C(++).
It's reference counting system of garbage collection can sometimes result in memory leaks, as opposed to the more thorough graph traversal employed in other languages.
IMPORTANT: Please, only reply to this post or moderate it if you actually understand the principles of compsci that I'm arguing about. I've been smacked down before by ignorant kiddies before, and would much prefer to see more reason in the future.

Re:Formalised features of Perl (in this book?) (-1, Offtopic)

Billly Gates (198444) | more than 11 years ago | (#5189770)

Mod this sucker down.

Thank you.

Re:Formalised features of Perl (in this book?) (-1)

Anonymous Coward | more than 11 years ago | (#5189797)

wow dude, what a well argued case you made there! lemme see now, you either want it modded because
(a) u r a perl zealot who can't stand the idea that anyone has a different opinion to you
(b) ur an ignorant fuck who diddnt understand the op
(c) combination of above

Re:Formalised features of Perl (in this book?) (-1)

Anonymous Coward | more than 11 years ago | (#5189828)

WTF are the moderators on? the thing about the type system makes sense; perhaps the mods just can't stand the truth (or they're just totally under the thumb of the guy who said 'mod this sucker down)

Re:Formalised features of Perl (in this book?) (2, Interesting)

Mr. Droopy Drawers (215436) | more than 11 years ago | (#5189947)

As you're also aware, most Comp Sci courses fawn over Pascal, a VERY formalized language. However, it's not mentioned much past education circles (and Apple afficionados).

In practice, reference counting doesn't seem to lead to memory leaks as you describe. And, I would argue it is much more efficient than Java's method.

PERL is an excellent SCRIPTING language. Larry Wall describes it as a "glue" language. XML is a good thing to glue together. It's perfect for that. Every tool has its purpose; push any too far, and you start abusing it.

Trying to find the quote from Larry Wall. I think it goes something like this: "Perl did easy things easily and made impossible things doable."

Re:Formalised features of Perl (in this book?) (1)

egoots (557276) | more than 11 years ago | (#5190185)

As you're also aware, most Comp Sci courses fawn over Pascal, a VERY formalized language. However, it's not mentioned much past education circles (and Apple afficionados).

Ever heard of Borland's Delphi product? The language is object-Pascal.

Perl6 is a mistake (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5189740)

I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby [ruby-lang.org] as well, and I intend to move my department over to it instead of wasting time with Perl 6.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster [mozilla.org] . People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language [rubycentral.com] (and not one with loads of irritating whitespace [python.org] thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal [lysator.liu.se] does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this [perl.com] . Does he want Perl 6 to be flex [gnu.org] or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse [goatse.cx] . I'd prefer to use a language [ruby-lang.org] which has always been pure synthesis of science and engineering, not some half-baked imposter [beonex.com] .

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but BSD^W Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Re:Perl6 is a mistake (-1, Funny)

Anonymous Coward | more than 11 years ago | (#5189776)

Wow. My troll is still around... It's almost as old as *BSD is Dying now...

Anyone reckon a Java-bashing paragraph is needed?

-- keesh

Mod this down, please. (-1, Offtopic)

teamhasnoi (554944) | more than 11 years ago | (#5189744)

I won't see the results for 3 days.

Why is Slashdot so slow? My God, it is so slow as to be unreadable!

Is slashdot now hosted on a Lego Brick? A Mac SE? An Atari 2600? WTF?

Poorly (spell)checked stories, duplicates, and now unbearably slow.

How about /. changes to a newsletter that gets mailed out every day? The page updates would be faster, the EDs could use the spellcheck in MS Works, and stories could be filed once! in a filing cabinet.

This is a book review? How about a Slashdot review?

Alright. Start your oh-so-predictable mods. Yawn. Wake me when the page refreshes.

Re:Mod this down, please. (0)

Alcohol Fueled (603402) | more than 11 years ago | (#5189781)

"...and stories could be filed once! in a filing cabinet."

Knowing Slashdot, someone would have made a copy of the newsletter and filed that too...

Re:Mod this down, please. (0)

Anonymous Coward | more than 11 years ago | (#5189995)

I'd agree with you, but I can't get to slashdot to read your post.

Re:Mod this up, please. (0)

Anonymous Coward | more than 11 years ago | (#5190806)

Cause it is so true.

Re:Mod this down, please. (0)

Anonymous Coward | more than 11 years ago | (#5190938)

I won't see the results for 3 days.

Why is Slashdot so slow? My God, it is so slow as to be unreadable!

Is slashdot now hosted on a Lego Brick? A Mac SE? An Atari 2600? WTF?

Poorly (spell)checked stories, duplicates, and now unbearably slow.

How about /. changes to a newsletter that gets mailed out every day? The page updates would be faster, the EDs could use the spellcheck in MS Works, and stories could be filed once! in a filing cabinet.

This is a book review? How about a Slashdot review?

Alright. Start your oh-so-predictable mods. Yawn. Wake me when the page refreshes.

Maybe the editors should read this book, and speed up slashdot...

This was a review? (4, Insightful)

Syris (129850) | more than 11 years ago | (#5189749)

I'm sorry, but this just wasn't a terribly deep review and well below par for /. Listing contents of a book and then nitpicking a detail don't a book review make.


How effective were the examples? How easy to read and understand were the general concepts? Were the descriptions of libraries and API's clear? Was the writing generally readable?


Would this book even make a good reference?


Jeez, anyone want to follow up the post with a real review?

XML frees us from Perl (4, Interesting)

Euphonious Coward (189818) | more than 11 years ago | (#5189774)

The whole point of XML is to free us from having to do the kinds of things Perl is meant for. Absent free-form text munging, Perl really has no advantage over other languages. At the same time, it has real deficits for people who need to know they have solved a problem correctly and completely.

(For reference, see this rant [underlevel.net] by the brilliant net.kook Erik Naggum. The most quotable bit, for the lazy among you, is

...[Perl] rewards idiotic behavior in a way that no other language or tool has ever done, and on top of it, it punishes conscientiousness and quality craftsmanship -- put simply: you can commit any dirty hack in a few minutes in perl, but you can't write an elegant, maintainabale program that becomes an asset to both you and your employer; you can make something work, but you can't really figure out its complete set of failure modes and conditions of failure. (how do you tell when a regexp has a false positive match?)
)

Re:XML frees us from Perl (1)

Slugbait (17229) | more than 11 years ago | (#5189841)


The whole point of XML is to free us from having to do the kinds of things Perl is meant for. Absent free-form text munging, Perl really has no advantage over other languages. At the same time, it has real deficits for people who need to know they have solved a problem correctly and completely.

I essentially agree with you but one still has the problem of merging a non-xml document into xml form. Here perl can be fairly useful.

Re:XML frees us from Perl (1)

Euphonious Coward (189818) | more than 11 years ago | (#5189908)

Slugbait writes: "...one still has the problem of merging a non-xml document into xml form."

That's true, but the Perl XML-handling modules are not much help for that.

Re:XML frees us from Perl (2, Informative)

DaRobin (57103) | more than 11 years ago | (#5189955)


Not much help? If you start counting the number of Perl modules that expose a SAX interface to non-XML data (not to mention the host of other super-useful SAX tools) you'll probably find only one egal, Python.




And if you think that XML has freed us from additional text processing, you obviously haven't used XML much, or at least without much variety. Most people seem constantly bent on including microlanguages in attribute values or text content. Those need good text processing.


Perl is a reflection of your soul (4, Interesting)

Nexus7 (2919) | more than 11 years ago | (#5189864)

Well, perhaps not your soul, but your Perll code just reflects the way you think to a greater extent than other languages. This isn't something that's done underhandedly, it is well advertised in every posting in c.l.perl and the Camel book, and every other book about Perl. Which is that Perl is not at all orthogonal, TMTOWDI (there's more than one way to do it). If you want to be rigorous and declare everything and not have your typos become references automatically, you "use strict" and your magic line is "#!/usr/bin/perl -w". If not, well Perl allows you to do that too. If you want objects, you can do that, if not, not.

If is possible to write quality code in Perl Just because the language allows you to not do so isn't its fault. It doesn't stop you from doing it, because that'd stop you from doing brilliant things.

To address some specific things you mentioned, you can do full-fledged exception handling in Perl if you want to (with eval and specific modules), or, you know, not. And I'm not familiar with the false positive matches in regexps (perhaps you're referring to some famous problem). But if a regexp doesn't do what you want it to, isn't is wrong? Between // and tr and split I get along just fine.

Re:XML frees us from Perl (4, Insightful)

glwtta (532858) | more than 11 years ago | (#5189992)

how do you tell when a regexp has a false positive match?

A what? You (or rather the brilliant person being quoted) either mean that it matches a string that the expression isn't supposed to, which would be a serious bug in the language (and I am not aware of any such bugs); or you mean that it matches correctly, but matches things you didn't expect it to, in which case you tell, by (gasp!) testing your code. In any case, how do you tell a "false positive" regexp match in Java?

but you can't write an elegant, maintainabale program that becomes an asset to both you and your employer

Perhaps you can't. I have, and I do.

Re:XML frees us from Perl (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5190035)

Okay, I'll bite.

The whole point of XML is to
free us from having to do the kinds of things Perl is meant for.

So how does XML do that in, let's say, system administration?

Absent free-form text munging, Perl really has no advantage over other languages.

So ehmm... what type of things is XML made out of? Elements' names, contents, etc, it's all text.

You can commit any dirty hack in a few minutes in perl, but you can't write an elegant, maintainabale program that becomes an asset to both you and your employer

You can write a dirty hack in any language. And about the last part: what about CPAN [cpan.org] ?

(How do you tell when a regexp has a false positive match?)

That would be by understanding the regex, just as any other chunk of code. (Funny, that... When you want to say something bad about Perl, moan about its horrible, illegible, etc regexes. When you want to mention something positive about another language -- especially when comparing to Perl -- mention support for powerful, fast, etc regexes. And advertised as "Perl-compatible" at that.)

-- Arien

Re:XML frees us from Perl (1)

Euphonious Coward (189818) | more than 11 years ago | (#5190604)

Arien asked, "how does XML [free us from doing the kinds of things Perl is meant for] in, let's say, system administration"

When config files are in XML, they can be munged programmatically without regexp hackery.

He goes on, "... what type of things is XML made out of? Elements' names, contents, etc, it's all text."

It's not free-form text, it's structured text. Somebody else pointed out, though, that there is a distressingly large amount of free-form text to be parsed in attribute strings, body text, and (!) comments, that XML structure extraction tools don't help with.

(I won't answer criticism of Naggum's rant; he's not known as a net.kook for nothing. Take it up with him.)

Re:XML frees us from Perl (0)

Anonymous Coward | more than 11 years ago | (#5190238)

Yeah, I'm amazed how many Perl programs don't handle error conditions well. By "don't handle well" I mean "ignore completely". When I first saw this page [zgp.org] (it's written in Perl), some of the values were zero when they shouldn't have been. They get the data by scraping altavista, but they don't check for errors when they retreive the data. Lucky it's just a novelty site and isn't actually showing something important.

Slashdot (written in Perl) randomly gives me some some weird "formkey" error when I try to post -- that's a step up, at least it's recognizing that an error occured -- but it's caught too late, and the software tries to blame the error on me. It says I had pressed the back button (I hadn't) or I have a firewall (I have, but I don't see what that's got to do with random errors on Slashdot). Clearly an error had occured earlier, but they didn't catch it at its origin.

Also on Slashdot, when the site is under heavy load, the front page sometimes shows ads -- the same ad repeated -- between each story. I don't think that's meant to happen.

Then there's the famous story of the two high-school kids who were suspected of taking a shotgun to school [slashdot.org] because of a subtle Perl error.

That's just some anecdotal evidence, but it's representative of my personal experience with software written in Perl. I don't know if it's the language or the programmers. I suspect it's both. Some more anti-Perl material:

What's wrong with Perl [garshol.priv.no] by Lars Marius Garshol

Is Perl Difficult? [prescod.net] by Paul Prescod

Re:XML frees us from Perl (2, Insightful)

scrytch (9198) | more than 11 years ago | (#5190636)

Maybe the author was unable to write anything but hacks, and couldn't make anything elegant or maintainable. I've written programs with multiple subsystems, and put them well into maintenance without a lick of trouble, all in perl.

Yes, $dd->updsp( 1,3, @ad ) looks worse than $Driver->update_displays( $Display:LOBBY, $Display:CUSTSERV, @additional ), and boy it's just a shame that perl doesn't let me use meaningful identifiers or document API's or forward declare functions for arg checking ahead of time. Oh wait... Really. The argument is dead, continuing to raise it is just trolling.

I switched to python because I got tired of leaning on my shift key. Tcl has probably the prettiest syntax for me, but as a language it's braindead beyond belief (not to mention slow)

Re:XML frees us from Perl (1)

Internet Dog (86949) | more than 11 years ago | (#5190842)

Absent free-form text munging, Perl really has no advantage over other languages. At the same time, it has real deficits for people who need to know they have solved a problem correctly and completely.

Absolutely. Once you get beyond text parsing by standadizing the syntax, the goal of a program is to manipulate objects. XML maps very well into object trees and that is why it is commonly processed using Java and Python. If you want the powerful capabilities of a dynamically typed language, with a simple, easy to learn grammer, then you should use Python for processing XML, not Perl. (Perl's object syntax is as obtuse as the rest of the language and offers no advantages over the elegant object model of Python. In fact, Larry Wall borrowed much of the Perl object design from Python. Use the genuine original, not the imitation.) The standard Python library includes a fine package for navigating through XML data and zero text processing code needs to be written to do this. It's objects all the way down.

There is a good article [xml.com] that explains how to use Python generators to process XML content. This is something you will never be able to do as easily in either Java or Perl.

Re:XML frees us from Perl (1)

Mark_Uplanguage (444809) | more than 11 years ago | (#5191479)

How do you tell when anything has a false positive match...TESTING

Let's reinvent the wheel again (1)

Chocolate Teapot (639869) | more than 11 years ago | (#5189789)

Although I agree that Perl/XML sounds like a powerful and flexible way to serve dynamic content, I can't help thinking that it is ultimately better to adapt existing frameworks (Slashcode, PHP-Nuke & friends etc..). Maybe a friendly group of Perl/XML gods will read the book and produce a framework/toolkit that the rest of us mere mortals can use. I suspect that I will buy this book anyway, read it, and after frying my brain for a few days I will stuff it on my bookshelf and walk away with a huge inferiority complex. My bookshelf makes me look like a guru, but secretly, my encyclopaedic knowledge comes from here [bathroomreader.com] .

Re:Let's reinvent the wheel again (1)

jslag (21657) | more than 11 years ago | (#5189926)

Maybe a friendly group of Perl/XML gods will read the book and produce a framework/toolkit that the rest of us mere mortals can use.

That happened years ago: the Apache XML project's AxKit [axkit.org] .

Re:Let's reinvent the wheel again (1)

davorg (249071) | more than 11 years ago | (#5190457)

Although I agree that Perl/XML sounds like a powerful and flexible way to serve dynamic content,

You need to move on from thinking that everything is there purely to be used for the web. Well over half of the work I've done with XML and Perl has nothing to do with the web.

Re:Let's reinvent the wheel again (1)

Chocolate Teapot (639869) | more than 11 years ago | (#5190489)

Considering that 'web' appears five times in the story, I don't think I jumped to any conclusions.

i hate perl... (1)

cygnus (17101) | more than 11 years ago | (#5189792)

and i know there are going to be a lot of posts saying "XML obviates Perl!"...

but i disagree. Perl absoulely RIPS through this stuff, unlike the Java stuff i've written. sometimes, there's nothing like some good, old-fashioned procedural code to munge one document into another.

the only problem i had was with UTF-8 stuff. perl really wasn't quite there until perl 5.8, and i'm having trouble finding installs of it on the machines i need to use it on at the university i work for.

Re:i hate perl... (0, Flamebait)

dubbayu_d_40 (622643) | more than 11 years ago | (#5190308)

Perl does not rip through text files. Programmers can rip through perl code, but perl is SLOW. I once rewrote a Perl parser in Java and went from 9hrs to 45mins.

Re:i hate perl... (2, Insightful)

etcshadow (579275) | more than 11 years ago | (#5190628)

"I once rewrote a Perl parser in Java and went from 9hrs to 45mins"

Well, shit. I once rewrote a Perl parser in *Perl* and went from 9hrs to 45mins. What the hell kind of flame-bait shit is this!?

It is true that extremely well-written C code can outperform perl code at anything. It is also true that for things that perl is made for (like ripping through tons of text-data), a typical Perl program will *most likely* do it better than a typical C program, simply because it is making use of more optimized underlying algorithms (even though the actual execution structure is slightly more bloated than C... double-dereferencing pointers, compile-time imediately before run-time, etc). ... However, Java is just as goddamn interpretted as Perl, if not more so! Perl compiles to *native* byte-code prior to execution, unless you are talking about eval'd strings, whereas Java sits in non-native byte-code that has to be interpretted real-time by the VM. Best case: you have a good just-in-time compiler that pulls Java up to even with Perl (that is, compiled imediately prior to run-time into native byte-code).

Also, Java has all the same disavantages with respect to C... that is more insulation from the *actual* memory (no such thing as a real pointer in either, garbage-collection, etc).

Anyway, bottom-line is this. If what you say is at all true, then you had a shittily-written Perl program. I promise you that I can write just as shitty a program in Java... does that mean that we should trash Java?!?!? Abso-f*cking-lutely not! I'll do you one better, too: I'll write just as shitty and slow of a parser in Java that doesn't even *look* that bad to someone who doesn't understand the subtleties behind such simple abstractions as strings, lists and arrays.

I'm very serious with what I said originaly, I have, in fact, taken a Perl parser (a super-light-weight XML parser, actually) and reduced the parse-time by several orders of magnitude. The idiot who wrote it originaly (myself), went walking through the string or stream looking for 's (with a regexp), at the highest level. It is *terribly* slow to strip leading characters off of a long string in Perl (I'm pretty sure that it copies the whole goddamn string, minus those 10 (or however many) characters on the front). I made a *very* simple change, namely this:

# split on positive lookahead assertion of a ''
# then we just deal individually with blocks of text that all start
# with a ''... should save time
my @xml = split(/(?=)/,' '.$xml);
shift @xml;

And, you'll note that I f*cking commented it (something which people just don't seem to understand when they trash perl). Bang! Many orders of magnitude in speed improvement. Simple.

Anyway, pull your head out of your ass.

Friggin less-than's (1)

etcshadow (579275) | more than 11 years ago | (#5190640)

The above includes several places that *should* have had a less-than character. You'd think that posting "Plain Old Text" would properly escape them as &lt;, but I guess you'd be wrong.

Oh, well. You know what I meant.

The Right Tool for the Right Job (2, Funny)

nathanz (555048) | more than 11 years ago | (#5189844)

I think one of the main reasons Perl and XML aren't generally used together is because Perl isn't object oriented in the same way the Java and C# are. I know that OO concepts have been bolted on to Perl in the same way the OO was bolted on to C++ and in my opinion with similar results (i.e., kludge-fest). It's very natual in Java to parse an XML doc and get an object, while it's more natural to parse a log file or CSV file with Perl.

Re:The Right Tool for the Right Job (1)

DaRobin (57103) | more than 11 years ago | (#5189980)

That's because you see XML more or less as an object serialisation syntax when it has been proven over and over again that there's serious impedance mismatch between those two views (at least, with Java's rather limited view of OO). See XML Schema if you don't think so.

Don't forget that the Desperate Perl Hacker was in the requirements for XML. And they succeeded pretty well in making XML match Perl.

If you REALLY want to buy the book (1, Offtopic)

Cy Guy (56083) | more than 11 years ago | (#5189879)

Then maybe you should get it from Amazon [amazon.com] , where it is $12 cheaper.

Please Rob, explain to us how whatever deal you have with bn.com is worth your user base overpaying by so much? Users can buy the book through the link above, and I will put a third of my affiliate commission (about $1.40 per copy) towards Perl development projects [affero.net] . This way everybody wins. Using your link, I assume you win, and that bn wins, but your loyal user base is out an additional $12 and I can't imagine your deal with bn.com nets you that much for providing the link.

Re:If you REALLY want to buy the book (0)

Anonymous Coward | more than 11 years ago | (#5190031)

They use BN because Jeff Bezos is a clown who abuses the patent system. Why support that shit?

Re:If you REALLY want to buy the book (3, Informative)

graxrmelg (71438) | more than 11 years ago | (#5190033)

But if people are interested in getting a good price rather than putting a commission into your pocket (and contributing to a company that abuses software patents), maybe they should order it from Bookpool [bookpool.com] instead, for $3 less than Amazon. (I don't have any affiliation with Bookpool.)

Re:If you REALLY want to buy the book (1)

Cy Guy (56083) | more than 11 years ago | (#5190915)

But if people are interested in getting a good price rather than putting a commission into your pocket (and contributing to a company that abuses software patents),

They can't really abuse the patent, they can only take advantage of it. If you want to boycott anyone over their one-click patent, boycott the US government that issued them the patent. If you think the patent was issued in error, then provided the prior art to discredit the patent. ...they should order it from Bookpool [bookpool.com] instead, for $3 less than Amazon.

Except that unless you buy another book to get over BookPool's $40 Free Shipping threshhold you will just be paying that $3 to UPS instead of me and the Perl Development Fund. Amazon's Free Shipping [amazon.com] threshhold of $25 falls conveniently just under their price for the book [amazon.com] .

Re:If you REALLY want to buy the book (2, Informative)

Badger (1280) | more than 11 years ago | (#5190231)

Actually, /. used to link to Amazon, and had an affiliate program. Once Amazon started enforcing their one-click patent, and the Amazon boycott began, /. switched to Fatbrain (which was bought by BN).

SLASHDOT BLOCKING MOZILLA (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5189885)

I can't access SLaSHdoT WIth MOZILLA!

It's blocking mozilla but I can get to it with IE!! UGh!

HeLp!!

XML (0)

Anonymous Coward | more than 11 years ago | (#5189962)

Treat XML as Lisp sexps, but with terrible syntax (and that's compared to Lisp!).
It's much less painful in the long run.

Re:XML (0)

Anonymous Coward | more than 11 years ago | (#5190230)

Treat XML as Lisp sexps

I thought sexps was for printing pr0n pics on a PostScript printer, and had nothing to do with lisp.

So, where's the review? (3, Insightful)

mattdm (1931) | more than 11 years ago | (#5189994)

I see the table of contents explained in paragraph form. And then one complaint about the organization of the book. And then I expect to read the review, but it's already on to "you can buy this book here", and user comments.

I know complaining about slashdot stories is like shooting those proverbial barreled fish, but sheesh.

XML isn't text (0)

Anonymous Coward | more than 11 years ago | (#5190094)

XML may look like text, but it isn't.

Instead, XML is structured data, represented as text.

Perl's text processing operators are all regular-expression (pattern) based. That works great for text (such as old-style log files) but works piss-poorly when coming to a structured file such as XML.

It'd be a royal pain in the arse to match, using a regular expression, some of the things you need to match when processing XML. Don't believe me? Take a look at what you do with XSLT (a great language for processing XML) and think of the matching power you can do with XPath, that you cannot do with Perl's regular expressions.

- David

Perl is for suckas (0)

Anonymous Coward | more than 11 years ago | (#5190162)

Perl is excellent... if you need to push your CPU to its limits. Why bother running Folding@Home or SETI@Home when Perl is sucking away all the CPU?

Re:Perl is for suckas (0)

Anonymous Coward | more than 11 years ago | (#5190177)

Perl is much better suited for CPU burn-in torture tests. Its CPU utilization would push any overclocked system to the brink of collapse. Folding@Home? SETI@Home? Bah, they aren't even in the same league.

XML::Simple (2, Interesting)

Anonymous Coward | more than 11 years ago | (#5190271)

I'm seeing a lot of comments that perl doesn't have any particular strengths when dealing with XML. A good module people should check out is XML::Simple. Basically, it automagically turns XML into a nested data structure, and automagically turns a nested data structure into XML. The great thing about it you just make a single API call, and just directly access the data from there without having to learn anything more complicated. Definitely not an end-all solution, but definitely handles the common case wonderfully, and has quite a few handy options to allow more fine tuned control.

Perl & XML -- issues (0)

Anonymous Coward | more than 11 years ago | (#5190273)

A few comments of my recent experiences with Perl & XML:

At my current dev project I was asked to design a small application or script that would read an XML file, validate it using a DTD, perform more complex validation using data in our DB, and then save the XML file into various DB tables.

Issue #1: The XML::Parser module doesn't do any validation. You will need XML::libXML which uses the gnome xml library.

Issue #2: XML::LibXML was a pain to install on our Solaris environment. There were a couple of dependencies. Overall, having to install XML::LibXML on multiple machines would be very difficult.

These issues weren't show stoppers, however, we ultimately decided to go the Java route. Deployment with java was much simpler. The java XML parsers handle validation. Also, incorporating this into our WebLogic app would be easier (if we later decided to do that).

For the most basic uses, XML::Parser should suffice. XML::Parser::Simple is really easy to use (it creates a hash table of hash tables representing your XML document for you to parse).

XML doesn't create regular languages... (1)

davids-world.com (551216) | more than 11 years ago | (#5190418)

XML is NOT just a text file (just because we can read it with a simple "more hello.xml"). Perl is good at processing text, because it knows regular expressions and some extensions to them. However, an XML DTD (or a Schema) defines a context-free grammar, which make a language class above the regular languges. That's why we can't fully parse XML files with Perl's RE. A good example would be nested tags that result from recursive grammar rules in the DTD. These cannot be parsed without some serious geekism in Perl RE. However, I love to write those little tools that operate on XML data in Perl. Very often, you can work with regular expressions on context-free/sensitive language data!

hasn't received much attention until recently? (4, Informative)

HealYourChurchWebSit (615198) | more than 11 years ago | (#5190505)



The reviewer is correct, Perl is a good tool for slamming and jammin' text, including XML. What I'm not so sure of is the quote "It's therefore surprising that using Perl for XML processing hasn't received much attention until recently."

I mean one need only scroll down the extensive list of CPAN Modules [cpan.org] to see well over 50, as well as many sites/authors devoting [cpan.org] time, energy and resource.

Similarly, I would point out some press modules supporting web services via XML, such as SOAP::Lite as far back as 02/26/01 [netscape.com] and XML-RPC also in '01 [sourceforge.net] -- or O'Reilly's own XML.com with articles such as "Processing XML with Perl [xml.com] " written shortly after the turn of the millenium.

Point is, though I personally love Perl, blatant plugs such as "... it's just that the world outside of the Perl community doesn't seem to have taken much notice of this work. This is all set to change with the publication of this book and O'Reilly's Perl and XML." " don't inspire confidence in the reviewer's objectivity.

Axkit, perl & XML so happy together (2, Informative)

porter235 (413926) | more than 11 years ago | (#5190572)

check it out. http://axkit.org/ [axkit.org]

"Apache AxKit is an XML Application Server for Apache. It provides on-the-fly conversion from XML to any format, such as HTML, WAP or text using either W3C standard techniques, or flexible custom code. AxKit also uses a built-in Perl interpreter to provide some amazingly powerful techniques for XML transformation."

picture coccoon for perl. using perl for xsp pages and doing pipline transformations on xml. great stuff.

A simple answer to the question: (0)

danbeck (5706) | more than 11 years ago | (#5190722)

Who gives a damn? XML is generally a pain in the ass, long winded, over-the-top way to store simple data. Simple comma delimited text files are more than sufficient enough for many data needs and serious people who need real data storage of complex relational data use a database engine of some sort.

The conclusion? There isn't much development of Perl XML tools because no one cares about them. XML, with the exception of a few specialized purposes, is a buzzword for marketdroids and the technically incompetent. Why should I spend hours working out an application to parse XML data when I can write a quick script in any language to parse a comma separated text file in a few minutes?

Maybe CSV isn't quite as kewl sounding as XML?

use AxKit! (1)

sbwoodside (134679) | more than 11 years ago | (#5190744)

Use AxKit! You're selling yourself short if you start to develop a site without it. It's just the ideal way to get the whole separation of content and presentation thing that XML is supposed to be all about. It makes it dirt easy to store your content in XML, use XSLT for transformations and XSP for dynamic back-end processing. Check it out [axkit.org] !

Also read this [monasticxml.org]

simon

XML makes Perl less important (1)

mackman (19286) | more than 11 years ago | (#5190796)

Perl's strength is text processing was its ability to work with (read and generate) poorly structured data. XML makes it easy to create well structured data thus writing document processing code in languages like C++ is easier. People who don't know Perl, or people who learned other XML toolkits first, have less reason to learn XML with Perl.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?