I don't know XML::Simple much, but the conversion of

<preferrededitlist>"default"</preferrededitlist>
[download]

<preferrededitlist>&quot;default&quot;</preferrededitlist>
[download]

looks perfectly valid to me, except that your consumer of the output likely doesn't know what to do with that. Maybe you should use a templating module like Template::Toolkit instead. Another idea could be to try other XML modules, maybe the less compliant XML::Tiny or some other tagsoup parser.

      # translate xml text to hash ref
      $xmlparms = eval { XML::Simple::XMLin($xmltext, nsexpand => 1,
                                  ForceArray => 1,
                                  KeepRoot => 1,
                                  KeyAttr =>[],
                        )};
[download]

Update:
Actually the quotes are generated per default by XML::Simple on output. You can turn off this behavior by specifying the option:

NoEscape=>1
[download]

<?xml version="1.0" encoding="utf-8"?>
<AttributeDatabase>
     <attribclass toolonly="false" hidden="false" dbvault="true">
    <editlist name="default">
    <entry>*</entry>
    </editlist>
    <preferrededitlist>"default"</preferrededitlist>
    <attribdef name="mtl_param" synthetic="true" array="true">
        <desc>IsSynthetic</desc>
        <type>Attrib.Types.Vector4</type>
        <bound>True</bound>
        <properties platform="common">
        <mincount>2</mincount>
        <maxcount>2</maxcount>
        </properties>
    </attribdef>
    <attribdef name="mtl_Kdiff" toolonly="true">
        <memberkeyvalue path="" key="push(bits)-&gt;::mtl_param:common
+:0:w"/>
        <desc>controls --&gt; mtl_param[0].w </desc>
        <type>EA.Reflection.Float</type>
        <bound>False</bound>
        <increment>0.001</increment>
        <properties platform="common">
            <max>2.0</max>
            <min>0.0</min>
            <defaultreflectedobject>1.0</defaultreflectedobject>
        </properties>
    </attribdef>    
     </attribclass>
</AttributeDatabase>
[download]

I have an article on using xsh2 to scrape HTML as well (embargoed at the moment, should go live in a few weeks).

Don't use XML::Simple, it is one of the most complicated 'Simple' modules that I have ever come across.

XML::Twig is better for XML documents that have any sort of complexity.

I agree, XML::Twig is great, although its API is humongous. It takes a while to find out what the correct name of the method is that you need, and they are not even sorted in any sensible way in the documentation.

XML::Twig also adheres to TIMTOWTDI. I can see two immediate ways to achieve your goal:

1. Read in the whole XML file with

   XML::Twig->new()->parsefile('my xml file');

   then access individual nodes and change their values. (For example,

   my $twig = XML::Twig->new()->parsefile('my xml file');
   # Use XPath-like expressions to find the nodes you want.
   my @nodes = $twig->get_xpath('attribclass/attribdef[@name="mtl_Kdiff')
   +;
   for my $node (@nodes) {
       # Process...
       # Example: $node->set_att('synthetic', 'false');
   }
   
   # Or navigate through references.
   my @attribdefs = $twig->root->first_child('attribclass')->children('at
   +tribdef');
   for my $node (@attribdefs) {
       # Process...
   }
   [download]

2. Create an XML filter:

   my $twig = XML::Twig->new(
       twig_handlers => {
           'attribdef' => sub {
               my ($twig, $elt) = @_;
               if ($elt->att('name') eq 'mtl_param') {
                   # Do something.
               }
               elsif (...) {
               }
               # etc.
   
               $twig->flush;
           }
       }
   )->parsefile('my xml file');
   $twig->flush;
   [download]

   This will read in the file, parse it, and while parsing, call the twig handlers defined above. The handlers can do their stuff (change element names, change values, cut and paste subtrees, and all other cool things), and the final XML text will be output to STDOUT ($twig->flush;).

   However, this approach is not very practical if you first need to read in some data from the file, do some processing with them, and only later go and update the file. You could first read in the file in as a data structure (almost?) identical to what XML::Simple produces:

   my $hash = XML::Twig->new()->parsefile('my xml file')->simplify();
   use Data::Dumper;
   print Dumper($hash);
   [download]

   You can then do what you like with the read values, and later use that information to construct an XML filter that will produce the final file.

This sounds more complicated than it really is. On the other hand, XML is often too complicated for its own good.

Warning: code examples not tested.

--
print "Just Another Perl Adept\n";

I've been down this road before, and depending on what you're trying to do another answer is to use XSLT. Now if you're not familiar with it, it certainly takes getting used to. Even when I knew it I would write a program using XML::Twig. In hindsight I've found using a simple XSLT copy template, and then adding in the templates for the cases you need is best. Additionally, the nice thing about XSLT is that you can read ahead/behind of your current node in order to pull different values together. The next level is to realize you can plug in Java functions into the namespace and get any kind of programming done. Of course none of this takes into account your memory or processing speed requirements.

There is a monk here somewhere whose signature is something like, "Don't write your own XML parser." But of all the scores of languages I have ever seen, I have found XML to be absolutely the easiest to write a parser for. As far as your needs are concerned, the Backus Naur Form (BNF) is the shortest I can imagine for a language. Something like this would about cover it:

Document :== Heading [Tag ... ]
Heading :== "<" [!">" ...] ">"
Tag :== "<" { TagName [Assignment ...]} ">" {Value|Substructure} "</" 
+Tagname ">"
Value :== [!"</" ...]
Substructure :== [Tag...]
Assignment :== name "=" QuotedString
[download]

Of course, you also need a lexical analyser - about half a page in Perl and a thrower to walk past whitespace and carriiage returns, which can also poll the lexer rather than be written from scratch. You would also need to choose a structure that differentiates between simple value tags and tags that contain a substructure (e.g. tagname => { VALUE => scalar } versus tagname => { SUBTAGS => arrayReference }).

The code generation is a mirror of the parser, reading through your datastructure and generating the appropriate XML - thus equally trivial. You need to track the recursion depth of the puttag routine and just multiply $tabsize*($depth - 1) X " " to indent, putting each tag on its own line.

But the case for writing your own parser actually depends on whether or not you have a continuing need to meet new requirements that you cannot predict in advance (in my case there are multiple streams of XML to and from different organisations that have to be addressed for a single system) and cannot therefore nail your colours to any particular module that might already be available.

I don't agree on writing a custom XML parser, but if that's your poison, I recommend Parse::RecDescent. It's simply superb.

--
print "Just Another Perl Adept\n";

Writing parsers from scratch is like cleaning the bathroom. It's a dirty job, but someone has to do it and once you do it once, it becomes part of your daily routine.

-M

Free your mind