in reply to Re: Re: Parsing XML into a Hash
in thread Parsing XML into a Hash

Given the general consensus shown in the other replies, I'm probably putting up flame bait (or at least a downvote magnet), but here goes... You say:

I just get to sit here and make executive decisions about the code like, "Well, since I am controlling all the input and output of this program, and I am controlling all the changed to the XML file, I'll just write a simple handler to accomodate what I know is going to be in the XML file," and be done with it.

To which I say "Amen, Brother!" Based on the very tidy and fairly simple XML sample in your original post, I don't see a problem with writing a "tightly-bound" (i.e. ad-hoc) "parser" in a dozen or so lines of perl -- the point being to get the job done with minimal fuss (including, mainly, minimal fuss with the folks who are paying for this job). What this really means is that you just need to be very careful about testing the script that creates this XML stream, to make sure its output always meets the constraints assumed by the downstream "parser" script.

Assuming that you can manage the quality of the XML stream as it's being created, then something like the following would probably suit the bill for reading that stream: 

open( XML, "source_of_xml.data" ) or die "I died 'cuz $!";
{
    local $/ = "</item>\n";
    my %item;
    while (<XML>) {  # read one whole <item>...</item> into $_
        for my $tag (qw/name working uptime downtime/) {
            ($item{$tag}) = m{<$tag>(.*?)</$tag>}s;  # (leave off "s",
                  # if tags are always fully contained on one line)
        }
        # now, do what you want with %item...
    }
}

[download]
So what's wrong with that? If you really are creating the XML stream as well as processing it -- and if the data structure is really as flat as your example makes it out to be -- then you really don't need an XML parsing module.

In essence, you seem to be using XML simply as a means of "embellishing" (reformatting) a flat table, and there's no need for a hefty, C-compiled module to handle that.

Replies are listed 'Best First'.
4Re: Parsing XML into a Hash
by jeffa (Bishop) on Nov 04, 2003 at 02:58 UTC

    "So what's wrong with that?"

    Murphy will rear 'is ugly and head and next thing you know the XML will need be nested: 
    ...
    <name>
      <first_name>Foo</first_name>
      <last_name>Bar</last_name>
    </name>
...

    [download]
    and attributes will be needed: 
    ...
    <name part="first">John</name>
    <name part="last">Smith</name>
...

    [download]
    .. and more goodies waiting around the corner for anyone trying to write a parser that has never written any kind of compiler. I personally do not like to waste valuable time reinventing a wheel that only takes a few moments to install. You download it, you install it, you write stuff that matters and you don't worry about the issues i pointed out.

    But .... IF and if that XML will never get more complicated that originally posted, then your code should suffice. However, a "real" XML parser does not 10 lines of code make, just take a look at XML::SAX::PurePerl. ;)

    UPDATE:
    Now you are just being silly graff. My whole point was that one shouldn't have to worry "as the need arises". Not when all you do is install a CPAN module (i like BrowserUk's suggestion: XML::Parser::Lite). mcogan1966 - you are in for a bumpy ride. Please take BrowserUk's suggestion. If you really are "Lord and Master", then use a module for this. But don't take my word for it (besides, what could i possibly know about projects that never finish because of red tape?) just wait till Murphy gets you. ;)

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]
[select]
      Nested schmested! Those examples still look like a flat table to me. ;^) ... Seriously, this could just mean changing the names/regex patterns to identify the tags that really matter, including their attributes, as the need arises.

      Granted, the poor soul might someday have to face elements whose attributes and/or content structure show significant variability, or even -- God help him -- recursion. Then he's really not in flat-table-land anymore, and it's time to bring in the right tools (a real parser).

[reply]
        Nested schmested! Those examples still look like a flat table to me.

        And they are.
        And they will continue to be.
        I am Lord and Master of this code.
        All it has to do is what they want it to do.
        I get to make the design decision.
        So, if it's a flat-file XML format, then that's what it is.
        And nothing goes into that file without my approval now.
        *insert evil laugh here*
[reply]

In Section Seekers of Perl Wisdom