Let's presume you have a well-formed_document, and ignore the question as to whether it's valid for a particular XSD.

The first mistake you are making is thinking about an XML document's line structure as significant. While newlines and indentation are considered good form in an XML document, the standard is whitespace agnostic. Thus, you should be doing a slurp into a single variable. Something like:

#!/usr/local/bin/perl
use strict;
use warnings;

my $sandboxxml = do {
    open(my $fh, '<', $ARGV[0]) || die("sandbox xml file cannot be loa
+ded;check for file name or existance");
    local $/; # Slurp
    <$fh>;
};
[download]

Second, comments can contain all sorts of text that might interfere with a parse. As well, an XML document may contain a CDATA block, which can contain very nearly arbitrary text. I'm assuming that you don't have them in your trial document since you never handle them, but they are possible and must be removed before you can handle anything else. This also introduces the need to tokenize, as you must extract something from your document, but keep a placeholder in there so you know where your content came from. As who knows what's in the document, we'll need to pick something that can't possibly be legal XML, but that we can work around in our regular expression. How about <<#>>, where # is the index in our token array. Note that since comment delimiters are not special within a CDATA block and vice versa, we must strip them simultaneously. So:

my @tokens;

while ($sandboxxml =~ /<!\[(CDATA)\[|<!--/) {
    if ($1) { # We're in a CDATA block
        $sandboxxml =~ s/<!\[CDATA\[(.*?)\]\]>/'<<' . (0+@tokens) . '>
+>'/es;
        push @tokens, $1;
    } else { # Comment
        $sandboxxml =~ s/<!--.*?-->//s;
    }
}
[download]

Okay, now we can start actually dealing with tags. Because of how XML is structured, we need to work from the inside out; otherwise is very hard in a general regex to know if you've actually matched start and end tags. We also now need to keep track of a tree structure in some way, but fortunately we can do that in a soft way using the tokens array we've already started.

while ($sandboxxml =~ s#(<[^<>]*(?:/|>(?:[^<>]|<<\d*>>)*</[^<>]*)>)#'<
+<' . (0+@tokens) . '>>'#es) {
    push @tokens, $1;
}
[download]

Of course, that's a giant mess. We also haven't built our tree up yet and failed to handle the leading <?xml...> tag. And hundred other things. And if our expressions are that complex, debugging them is going to be a pain.

This may not be what you want to hear but:

How do I match XML, HTML, or other nasty, ugly things with a regex?

Do not use regexes. Use a module and forget about the regular expressions. ... XML::LibXML ...

Other XML modules often recommended are XML::Twig, XML::Rules, or XML::Compile. Personally I prefer XML::LibXML or XML::Twig. (You may run into XML::Simple too, but that is only appropriate for really simple cases, of which this does not appear to be one, so I'd avoid it.)

If you could show some representative sample input and the corresponding expected output, someone might be able to get you started with one of those modules.

pattern match screwed up!! ... Moreover none of the patter match is working.

Its easy for you to figure it out if you use Basic debugging checklist , brian's Guide to Solving Any Perl Problem

Also, its even easier to XML::LibXML with tools like xpather.pl/htmltreexpather.pl which can give you paths to start with, and all the links here Re: Retrieve select information from HTML, they're examples(for tree-xpath and others)/walkthroughs/tutorials ...

You know whats even easier?  [metacpan://junit] [cpan://junit] -> junit junit -> bupkis no dedicated junit parsers on cpan :)

thanks for the hint. I did look into LibXML module but in the activestae installation at office this module is not installed. And apparently I am not allowed to alter this installation. The only module available to me are Simple and Expat.

Talk with your manager at work. Explain what you're trying to do and why. Once there is a legitimate business reason, most companies will allow the installation.

Jason L. Froebe

Blog, Tech Blog

mdfaizy:

In addition to what kennethk so eloquently said, I'd like to offer one little thing: A solution based on regexes can be fragile. You may spend a good bit of effort to make something that "works", and you'll be fine ... ... ... for a while. Every once in a while, the document will have something "interesting" in it, and your regex solution will break. Then you get to fix it. Unfortunately, it'll likely keep happening and irregular intervals.

Even worse, it may appear to be working, but you may miss important things. Since a regex solution doesn't understand the structure of the XML document, you won't know when your regexes aren't working unless they fail in an obvious fashion. The worst failures are when it fails in a non-obvious fashion. As an example, suppose you don't handle attributes on tags because there aren't any currently. Then someone makes a change, and you get a document like this:

  ...
  <orders>
    <order>
      <orderID>1234</orderID>
      .. other order details ..
    </order>
    <order priority="SUPER IMPORTANT">
      <orderID>1235</orderID>
      .. multimillion dollar order ..
    </order>
  </orders>
  ...
[download]

Your boss, expecting a big order sometime soon asks "Hey, did we get any important orders yet?" You look at your log and say, "No, we just got one order today, it doesn't look special." That super important order will likely cause many people headaches and phone calls. But since the attribute existed in the order tag, it got missed.

</endOfContrivedExample>

...roboticus

When your only tool is a hammer, all problems look like your thumb.