Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Tuesday November 29, 2005
04:50 PM

If you don't need a Schema, you don't need XML

[ #27793 ]

XML! The answer to every problem the world has! ... or not.

Almost any technology you can invent is going to be used in ways you won't expect. This holds true of most of the things you write, and it's part of the reason I try to tell people to get their APIs as complete and correct as possible before the first release, so that it's easier for people to do interesting and unexpected things with your code.

XML on the other hand seems to buck this trend.

XML was created to provide a neutral and verifiable format for structured data, so that the biggest problems in doing "document/data interchange" were solved for a (large) one time cost in development resources.

A bunch of people have put in a ton of work to create code that burns a whole bunch of CPU time to solve some very nasty problems, so you can concentrate on the specifics of a situation.

The expense of XML means that unless you are doing document interchange (moving files and data between disparate systems written in different languages or on different backends) it can be REALLY hard to justify all that expense. A lot of the time you'd probably do better with YAML, JSON or even Config::Tiny-derived data storage.

Some of the worst offenders are config files that people create in XML just because it's fashionable. You really don't need it, unless you plan to do document interchange of those very config files (for example the deploy configs for Java web applications).

I arrived a while ago at what I think is good measure of whether you really need XML or not.

"If you don't need a Schema, you don't need XML"

That is, the situations in which it's worth the cost of XML at all are most often those in which you need the power of the validation provided by Schemas, mainly due to trust boundaries.

For example, when swapping documents or data with customers, or when you need to move data between code written by different people. Although it's nice to have trust between you and clients or other coders, what is much better is to be able to work with other people's systems and code without having to trust them at all. Mostly this is protection against miscommunication, stupidity and accidents, rather than outright maliciousness, but there's a lot of all four going round.

I find things like XSLT, which was envisaged for doing tasks where you'd only have the difficulties of writing the XSLT once (like changing NikeShoeML into ChineseFactoryML) a gross waste when employed as a HTML templating mechanism or similar. (although I'm sure there's a subset of cases it's genuinely needed)

As a result, so far in my entire career I've only needed to deploy XML "in anger" once while doing perl consulting work. It's a big sophisticated application doing some wonderous things I try to avoid talking about except verbally or in un-Google'd space.

The client's C-based system (about which I know nothing else) fires XML batch job requests at my Perl server, which processes them over a few minutes or a few hours, and returns the results and errors as another XML document.

So XML for me is a sign of doing Something Big.

I've just deployed an initial development release of my first ever XML CPAN module. It's the beginning of World Domination Plan #6.

Writing a SAX Parser was even more pleasant than it was the first time. I'm really getting more and more impressed with Matt Sergeant's XML::SAX every time I use it. And all I need now is to find a little more time (hopefully at YAPC::AU) to complete the API (which in this case also means the XML Schema) and I'll be ready to unveil plan #6 to the world :)

It's going to kick ass! I promise :)

(once I work out how the hell to install an .xsd file and find it later...)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I was using Data::Phrasebook [cpan.org] to store my SQL calls and I started out using the XML backend. I then realized I needed a more lenient format because SQL can have >= and <= which is not valid XML. I was caught up in the "Oh! I can learn and use XML for that!" syndrome.

    I switched to the YAML backend and I haven't been happier.

  • "If you don't need a Schema, you don't need XML"

    Excellent summation.

    My reaction to XML has been
    And what was wrong with Lisp that XML fixed?
    At least Lisp didn't bend the brackets until they snapped. With those silly weak pointy brackets, XML needs twice brackets as many as Lisp. XML looks like a failed cross between Lisp and Pascal (all blocks end with a NIGEB keyword, but with brackets too).

    But I like your aphorism better... it won't annoy the people who really do need XML; it provides a discriminen

    --
    Bill
    # I had a sig when sigs were cool
    use Sig;