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]

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.

"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)

"'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."

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)

Clueless?
No, not really. This is a secure site, and they take this very seriously. Besides, after further consideration of the entire thing, it was determined that XML::Simple just wasn't the right answer. I needed more control of the output anyway. Besides, the resulting code is only about 16 lines, including for proper spacing of the code and all. So, things work out in the end after all.