Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

RFC: XML::Composer

by Ovid (Cardinal)
on Sep 30, 2005 at 21:34 UTC ( #496522=perlmeditation: print w/replies, xml ) Need Help??

X-Posted from my use.perl journal (though this meditation is a bit different).

I know many would rather not see another module in the XML namespace, but I've started putting together a proof of concept called XML::Composer (it was originally called XML::JFDI with apologies to Jesse). It will let you write really, really bad XML. It will also allow you to write XML "variants" like the awful Yahoo! IDIF format. Namespaces? It doesn't know about 'em or care about 'em. If you want to use a colon in an attribute name, go ahead. Want to inject an XML snippet from somewhere else? Go ahead. It will simply do whatever you tell it to do. It's a sad fact of life that there's a lot of bad XML "variants" out there that we, as developers, have to live with (maybe this module should be called XML::Awful).

The primary idea is to be able to write XML in just about any format you want. Frequently this means that it will cheerfully produce bad XML, but rather than spend hours scouring the docs only to find yourself reporting another bug, you can quickly and easily tweak what you want. Unfortunately, most of the modules in the XML namespace are geared towards producing correct XML. Sometimes you need to produce bad XML so you roll your own XML generator and hope no one ever sees it.

The aim of XML::Composer is to make bad XML easy to write. If you have to produce it, at least you should produce it as easily as possible.

use XML::Composer; my $xml = XML::Composer->new({ # tag method 'ns:foo' => 'foo', 'bar' => 'bar', 'ns2:baz' => 'baz', }); $xml->Decl; # add declaration (optional) $xml->PI('xml-stylesheet', {type => 'text/xsl', href="$xslt_url"}) +; $xml->foo( { id => 3, 'xmlns:ns2' => $url}, $xml->bar('silly'), $xml->Comment('this is a > comment'), $xml->Raw('<bad tag>'); $xml->baz({'asdf:some_attr' => 'value'}, 'whee!'), ); print $xml->Out; if ($xml->Validate) { # false for above example } __END__ <?xml version="1.0"> <?xml-stylesheet type="text/xsl" href="$xslt_url"?> <ns:foo id="3" xmlns:ns2="$url"> <bar>silly</bar> <!-- this is a &gt; comment --> <bad tag> <ns2:baz asdf:some_attr="value">whee!</ns2:baz> </ns:foo>

This module (not yet on the CPAN) assumes that you, the programmer, know what you're doing. It's designed for agile development: produce something quickly but have a test suite to verify that your output is correct. In short, there is a very specific design philosophy here and I wouldn't recommend it for those who don't have test suites, but it makes coding very fast (and no, it doesn't use AUTOLOAD to build those methods).



New address of my CGI Course.

Replies are listed 'Best First'.
Re: RFC: XML::Composer
by Zaxo (Archbishop) on Oct 01, 2005 at 01:42 UTC

    How about calling it XML::Composter?

    Garbage in, garbage out!

    After Compline,

      Bwahahaha! Brilliant. This deserves more than the one ++ I can give.

      Makeshifts last the longest.

      You should go talk to a gardener. Garbage in, garbage out? More like Garbage in, good natural fertilizer out. So I don't think "Composter" is the right term. Also ... I don't think the "XML::Awful" is a good name. That's unnecessary duplication. "XML" eq "Awfull".

      XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

Re: RFC: XML::Composer
by samtregar (Abbot) on Sep 30, 2005 at 21:40 UTC
    Consider not putting it in the XML namespace if it doesn't produce valid XML. Data::XMLish perhaps? Either way, please put in lots of big bold warnings explaining why the module shouldn't be used generate valid XML.


      Actually, it can be used to generate perfectly valid XML and it's pretty easy to do. The main thing is that it trusts you to actually know what you're doing. So long as you have decent tests, there shouldn't be a problem.


      New address of my CGI Course.

        Sure, so can HTML::Template. And with a proper test suite it can make a pretty good XML generator. Does that mean I should rename it XML::Template and recommend it for use producing XML? I don't think so!


      XML::Almost and Data::AlmostXML come to mind as well
Re: RFC: XML::Composer
by graff (Chancellor) on Oct 01, 2005 at 02:58 UTC
    I suppose it would be a bit too tongue-in-cheek to call it "XML::Wizard"...

    Since it has the potential (according to the user's skill/intent) of being either perfectly compliant with or unconstrained by certain XML "constraints", perhaps better to call it "Text::XMLout" (oops, there's that tongue in the cheek again), or even just Text::XML (there's nothing by either name as yet).

    (update: in case anyone missed the pun, the Webster's definition of "Lout" is "noun: an awkward brutish person")

Re: RFC: XML::Composer
by diotalevi (Canon) on Sep 30, 2005 at 21:46 UTC

    So which modules am I supposed to use if I want to make XML? The very few times I've had to deal with this I found myself having to manually encode data for interpolation into a string area. I also found that XML::Simple made it difficult to create XML that had the tags in all the right order so it would still pass DTD validation.

    So please let me know what is actually supposed to be used and probably include that in your module too.

      Monk 1: What X should I use?
      Monk 2: My favourite is a.
      Monk 3: Oh, I always use b. b rules!
      Anonymonk 1: Oh, come on, b is the sux0r! It can't even handle z properly
      Monk 3: Can't we just get rid of anonymonks? They're such a pain.
      Monk 4: Everyone I know is using c. Seems to do the job for me ...

      Translation: oi, you could start a flamewar with a question like that. :-)

      I may not have many tools in my XML toolbox, but XML::Twig has seemed to handle everything so far. Admittedly it won't handle "bad" XML as Ovid is trying to do, but for "good" XML production, I've been quite happy with XML::Twig. My requirements when I chose XML::Twig were to be able to read in an XML template, look up data from other data sources, process it, and insert transformed data into the XML template, and then have that parsed/used by a Java application where order usually mattered. XML::Twig allowed me to turn around that project in a matter of time that impressed me. YMMV

      There are tons of modules that let you write XML. <snark>Which one you want to use depends upon which set of bugs you want to avoid</snark>. Seriously, XML::Genx and XML::Writer are both fairly decent thought getting namespaces to work can be excruciatingly painful.


      New address of my CGI Course.

        FYI - XML::Writer does allow you to generate invalid XML. You just have to turn off the well-defined check(s) that you're violating. :-)

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      Any XML generator module that you use will have the same problem with regard to tag ordering. If you need to get tag a and then tag b in the right order, it's really up to you to do that. Usually, the best way is a small wrapper library on top of whatever XML generator you're using. As to which one, I have to point out XML::Genx, which I wrote (well wrote the XS interface anyway). It's very, very careful about making damned sure that you don't end up with non-well-formed XML. That means that you'll either produce parseable XML, or get an exception. If you make it produce non-well-formed XML, it's a bug. -Dom

        I just modified my code so that attributes are passed in an array reference instead of a hash reference, thus preserving attribute order.

        Update: I modified it again so it takes either a hashref or an arrayref.


        New address of my CGI Course.

Re: RFC: XML::Composer
by dragonchild (Archbishop) on Oct 01, 2005 at 01:11 UTC
    I like it the idea, a lot. XML::Composer sounds like a great name.

    The only thing I'd love to see is a way of parsing XML-like data so that the crap you have to hand-roll a parser for is easier to work with. Though, I'm pretty sure this is beyond the scope of this module.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: RFC: XML::Composer
by redhotpenguin (Deacon) on Sep 30, 2005 at 22:15 UTC

    In short, there is a very specific design philosophy here and I wouldn't recommend it for those who don't have test suites, but it makes coding very fast

    Maybe the coding is faster, but what about debugging, especially in the case of bad xml? If your goal is to make it easier to generate XML quickly, perhaps a wrapper to lessen the book-keeping code on one of the existing modules might be a better approach.

      The wrapper doesn't work. There are many companies that routinely generate and use XML that is not well-formed. While it's terrible to have to work with this, most existing XML modules don't play with with poorly formed XML (as well they shouldn't).

      Also, debugging is a snap. Unlike the existing modules, the interface is very transparent. You get exactly what you ask for.


      New address of my CGI Course.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://496522]
Approved by Enlil
Front-paged by Arunbear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (2)
As of 2022-12-04 21:29 GMT
Find Nodes?
    Voting Booth?

    No recent polls found