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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Yet *another* XML Module? 2 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • What we need is less bad not-quite-XML and more good XML. For generating good XML, the libaries that guarantee producing correct XML are the way to go. My impression is that they are easier to use than the not-so-nice ones because you don't have to worry about screwing up. They do things like always encoding strings, always using UTF-8, always worrying about namespace, and complaining about improperly nested tags.

    If you have to generate not-quite-XML or bad XML, then you have a bigger problem. I am not sure we need another library to make generating that easier. And makes generating good XML harder.

    I have been seeing links to HOWTO Avoid Being Called a Bozo When Producing XML [hsivonen.iki.fi] recently.

    • But there's plenty of bad XML out there already and there are programmers who have no choice but to implement it, particularly if it's a third party requirement. Usually this bad XML tends to cause plenty of problems. Why have even more problems by creating yet another hand-rolled module which may or may not do what you want? Programmers in this unfortunate situation should at least be able to get the job done and not waste time having to reimplement something.

      The good thing about Data::XML::Variant [cpan.org] is

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.