Here's some important facts (or at least important enough for them to occur to me in the few minutes I was typing this post):

• There is no more HTML. The only standard for web browsing is now XHTML, which is an XML application, not an SGML application (as HTML was).
• XML requires a parser to abort if it's malformed. No more browsers that all error-correct malformed HTML in different ways.
• XML is simpler to parse because there are no optional end tags.
• XML is not a universal "data exchange" panacea. You still have to agree on the semantics of the tags. But at least the syntax is clearly indisputable.
• XML is rich enough that almost anything that wants to be a "text" file with structure can be represented as XML
• XML will never be an input format for naive data entry. The rules for constructing XML data are learnable, but not by the average data entry clerk. {grin}

-- Randal L. Schwartz, Perl hacker

If you want to make an informed decision try having a look at some of these for more information:-
http://www.xml.com/
http://xml.apache.org/
http://www.perl.com/reference/query.cgi?xml

If you want to learn more about parsing XML in Perl read this article from the sadly defunct Perlmonth.

Ugly

Istr once reading in a "quick explanation of XML" (can't remember where precisely it was, sorry) that the author made the point that programmers often design file formats without hardly thinking about it: configuration files, state files, document files...

The point is, XML allows for a common structure for most of these one-time formats that autmatically gives benefits such as:

• common parsers, with strong syntax (well-formedness) checking
• parsers in essentially every language out there
• handles character escaping, and specifying character sets
• well-defined way of expressing hierarchies
• a way of specifying semantics in a machine-readable manner for futher checking (DTDs)

( as an example (or indeed a shameless plug), I wrote make_photos which uses XML as an input file- and imho it's perfectly suited, and much better than the text file I used for the script's first incarnation)

I think that most of the "XML Powering YOUR Website!" stuff applies to technology built on top of XML, not XML itself. Which is misleading, but fairly typical marketroid-speak.

XML is just something (actually a meta-language) with an HTML-like syntax (pointy brakets, elements and attributes) except it lets you define your own tags.

This is both a blessing, as now you can define what you data IS as opposed to what it looks like, and a curse, because you now have to figure out what it will look like, usually through style sheets or HTML/RTF/whatever conversion.

XML just defines a syntax, no more, you still have to decide what your tags are going to be and how you are going to structure your data. It just offers a standard syntax that XML tools understand, plus the underlying document/data model is a tree, which is quite powerful.

There are tons of Perl modules that can help you process XML, you can find a 6 month old list on XML.com, and note that some of the modules are reviewed in the Module Reviews

XML could (is) suffer(ing) from much the same thing. I think that people are hoping that they won't have to analyze their information managment requirements. Instead they'll "Just put it into XML". Hmmm.

One the one hand it may be overkill for certain apps, on the other hand it is a nice way of storing information in a consistent and easy to parse format.

You're still gonna have to think about what it is that you're managing using XML and what you're gonna do with it. The more complicated your application environment the more effort its gonna require.

Randy's comments have encouraged me to revisit this for config files that I make. :)