Provided by: libxml-simple-perl_2.25-2_all bug

NAME

       XML::Simple - An API for simple XML files

SYNOPSIS

       PLEASE DO NOT USE THIS MODULE IN NEW CODE.  If you ignore this warning and use it anyway, the
       "qw(:strict)" mode will save you a little pain.

           use XML::Simple qw(:strict);

           my $ref = XMLin([<xml file or string>] [, <options>]);

           my $xml = XMLout($hashref [, <options>]);

       Or the object oriented way:

           require XML::Simple qw(:strict);

           my $xs = XML::Simple->new([<options>]);

           my $ref = $xs->XMLin([<xml file or string>] [, <options>]);

           my $xml = $xs->XMLout($hashref [, <options>]);

       (or see "SAX SUPPORT" for 'the SAX way').

       Note, in these examples, the square brackets are used to denote optional items not to imply items should
       be supplied in arrayrefs.

STATUS OF THIS MODULE

       The use of this module in new code is strongly discouraged.  Other modules are available which provide
       more straightforward and consistent interfaces.  In particular, XML::LibXML is highly recommended and you
       can refer to Perl XML::LibXML by Example <http://grantm.github.io/perl-libxml-by-example/> for a tutorial
       introduction.

       XML::Twig is another excellent alternative.

       The major problems with this module are the large number of options (some of which have unfortunate
       defaults) and the arbitrary ways in which these options interact - often producing unexpected results.

       Patches with bug fixes and documentation fixes are welcome, but new features are unlikely to be added.

QUICK START

       Say you have a script called foo and a file of configuration options called foo.xml containing the
       following:

         <config logdir="/var/log/foo/" debugfile="/tmp/foo.debug">
           <server name="sahara" osname="solaris" osversion="2.6">
             <address>10.0.0.101</address>
             <address>10.0.1.101</address>
           </server>
           <server name="gobi" osname="irix" osversion="6.5">
             <address>10.0.0.102</address>
           </server>
           <server name="kalahari" osname="linux" osversion="2.0.34">
             <address>10.0.0.103</address>
             <address>10.0.1.103</address>
           </server>
         </config>

       The following lines of code in foo:

         use XML::Simple qw(:strict);

         my $config = XMLin(undef, KeyAttr => { server => 'name' }, ForceArray => [ 'server', 'address' ]);

       will 'slurp' the configuration options into the hashref $config (because no filename or XML string was
       passed as the first argument to "XMLin()" the name and location of the XML file will be inferred from
       name and location of the script).  You can dump out the contents of the hashref using Data::Dumper:

         use Data::Dumper;

         print Dumper($config);

       which will produce something like this (formatting has been adjusted for brevity):

         {
             'logdir'        => '/var/log/foo/',
             'debugfile'     => '/tmp/foo.debug',
             'server'        => {
                 'sahara'        => {
                     'osversion'     => '2.6',
                     'osname'        => 'solaris',
                     'address'       => [ '10.0.0.101', '10.0.1.101' ]
                 },
                 'gobi'          => {
                     'osversion'     => '6.5',
                     'osname'        => 'irix',
                     'address'       => [ '10.0.0.102' ]
                 },
                 'kalahari'      => {
                     'osversion'     => '2.0.34',
                     'osname'        => 'linux',
                     'address'       => [ '10.0.0.103', '10.0.1.103' ]
                 }
             }
         }

       Your script could then access the name of the log directory like this:

         print $config->{logdir};

       similarly, the second address on the server 'kalahari' could be referenced as:

         print $config->{server}->{kalahari}->{address}->[1];

       Note: If the mapping between the output of Data::Dumper and the print statements above is not obvious to
       you, then please refer to the 'references' tutorial (AKA: "Mark's very short tutorial about references")
       at perlreftut.

       In this example, the "ForceArray" option was used to list elements that might occur multiple times and
       should therefore be represented as arrayrefs (even when only one element is present).

       The "KeyAttr" option was used to indicate that each "<server>" element has a unique identifier in the
       "name" attribute.  This allows you to index directly to a particular server record using the name as a
       hash key (as shown above).

       For simple requirements, that's really all there is to it.  If you want to store your XML in a different
       directory or file, or pass it in as a string or even pass it in via some derivative of an IO::Handle,
       you'll need to check out "OPTIONS".  If you want to turn off or tweak the array folding feature (that
       neat little transformation that produced $config->{server}) you'll find options for that as well.

       If you want to generate XML (for example to write a modified version of $config back out as XML), check
       out "XMLout()".

       If your needs are not so simple, this may not be the module for you.  In that case, you might want to
       read "WHERE TO FROM HERE?".

DESCRIPTION

       The XML::Simple module provides a simple API layer on top of an underlying XML parsing module (either
       XML::Parser or one of the SAX2 parser modules).  Two functions are exported: "XMLin()" and "XMLout()".
       Note: you can explicitly request the lower case versions of the function names: "xml_in()" and
       "xml_out()".

       The simplest approach is to call these two functions directly, but an optional object oriented interface
       (see "OPTIONAL OO INTERFACE" below) allows them to be called as methods of an XML::Simple object.  The
       object interface can also be used at either end of a SAX pipeline.

   XMLin()
       Parses XML formatted data and returns a reference to a data structure which contains the same information
       in a more readily accessible form.  (Skip down to "EXAMPLES" below, for more sample code).

       "XMLin()" accepts an optional XML specifier followed by zero or more 'name => value' option pairs.  The
       XML specifier can be one of the following:

       A filename
           If  the  filename contains no directory components "XMLin()" will look for the file in each directory
           in the SearchPath (see "OPTIONS" below) or in the current directory if the SearchPath option  is  not
           defined.  eg:

             $ref = XMLin('/etc/params.xml');

           Note, the filename '-' can be used to parse from STDIN.

       undef
           If  there  is  no XML specifier, "XMLin()" will check the script directory and each of the SearchPath
           directories for a file with the same name as the script but with the extension '.xml'.  Note: if  you
           wish to specify options, you must specify the value 'undef'.  eg:

             $ref = XMLin(undef, ForceArray => 1);

       A string of XML
           A  string  containing  XML  (recognised  by  the  presence  of '<' and '>' characters) will be parsed
           directly.  eg:

             $ref = XMLin('<opt username="bob" password="flurp" />');

       An IO::Handle object
           An IO::Handle object will be read to EOF and its contents parsed. eg:

             $fh = IO::File->new('/etc/params.xml');
             $ref = XMLin($fh);

   XMLout()
       Takes a data structure (generally a hashref) and returns an XML  encoding  of  that  structure.   If  the
       resulting  XML  is  parsed  using "XMLin()", it should return a data structure equivalent to the original
       (see caveats below).

       The "XMLout()" function can also be used to output the XML as SAX events see  the  "Handler"  option  and
       "SAX SUPPORT" for more details).

       When translating hashes to XML, hash keys which have a leading '-' will be silently skipped.  This is the
       approved  method for marking elements of a data structure which should be ignored by "XMLout".  (Note: If
       these items were not skipped the key names would be emitted as element or attribute names with a  leading
       '-' which would not be valid XML).

   Caveats
       Some care is required in creating data structures which will be passed to "XMLout()".  Hash keys from the
       data structure will be encoded as either XML element names or attribute names.  Therefore, you should use
       hash key names which conform to the relatively strict XML naming rules:

       Names  in  XML  must  begin with a letter.  The remaining characters may be letters, digits, hyphens (-),
       underscores (_) or full stops (.).  It is also allowable to include one colon (:) in an element name  but
       this should only be used when working with namespaces (XML::Simple can only usefully work with namespaces
       when teamed with a SAX Parser).

       You  can use other punctuation characters in hash values (just not in hash keys) however XML::Simple does
       not support dumping binary data.

       If you break these rules, the current implementation of "XMLout()" will  simply  emit  non-compliant  XML
       which  will be rejected if you try to read it back in.  (A later version of XML::Simple might take a more
       proactive approach).

       Note also that although you can nest hashes and arrays to arbitrary levels, circular data structures  are
       not supported and will cause "XMLout()" to die.

       If  you wish to 'round-trip' arbitrary data structures from Perl to XML and back to Perl, then you should
       probably disable array folding (using the KeyAttr option) both with "XMLout()" and  with  "XMLin()".   If
       you still don't get the expected results, you may prefer to use XML::Dumper which is designed for exactly
       that purpose.

       Refer to "WHERE TO FROM HERE?" if "XMLout()" is too simple for your needs.

OPTIONS

       XML::Simple  supports  a number of options (in fact as each release of XML::Simple adds more options, the
       module's claim to the name 'Simple' becomes increasingly  tenuous).   If  you  find  yourself  repeatedly
       having to specify the same options, you might like to investigate "OPTIONAL OO INTERFACE" below.

       If  you can't be bothered reading the documentation, refer to "STRICT MODE" to automatically catch common
       mistakes.

       Because there are so many options, it's hard for new users to know which ones are important, so here  are
       the two you really need to know about:

       •   check out "ForceArray" because you'll almost certainly want to turn it on

       •   make  sure  you  know  what  the  "KeyAttr"  option does and what its default value is because it may
           surprise you otherwise (note in particular that 'KeyAttr' affects both "XMLin" and "XMLout")

       The option name headings below have a trailing 'comment' - a hash followed by two pieces of metadata:

       •   Options are marked with 'in' if they are recognised by "XMLin()" and 'out' if they are recognised  by
           "XMLout()".

       •   Each option is also flagged to indicate whether it is:

            'important'   - don't use the module until you understand this one
            'handy'       - you can skip this on the first time through
            'advanced'    - you can skip this on the second time through
            'SAX only'    - don't worry about this unless you're using SAX (or
                            alternatively if you need this, you also need SAX)
            'seldom used' - you'll probably never use this unless you were the
                            person that requested the feature

       The options are listed alphabetically:

       Note:  option  names  are no longer case sensitive so you can use the mixed case versions shown here; all
       lower case as required by versions 2.03 and earlier; or you can add underscores between  the  words  (eg:
       key_attr).

   AttrIndent => 1 # out - handy
       When  you  are using "XMLout()", enable this option to have attributes printed one-per-line with sensible
       indentation rather than all on one line.

   Cache => [ cache schemes ] # in - advanced
       Because loading the XML::Parser module and parsing an XML file can consume a significant  number  of  CPU
       cycles, it is often desirable to cache the output of "XMLin()" for later reuse.

       When parsing from a named file, XML::Simple supports a number of caching schemes.  The 'Cache' option may
       be  used to specify one or more schemes (using an anonymous array).  Each scheme will be tried in turn in
       the hope of finding a cached pre-parsed representation of the XML file.  If no cached copy is found,  the
       file  will  be  parsed and the first cache scheme in the list will be used to save a copy of the results.
       The following cache schemes have been implemented:

       storable
           Utilises Storable.pm to read/write a cache file with the same name as  the  XML  file  but  with  the
           extension .stor

       memshare
           When  a  file  is  first  parsed, a copy of the resulting data structure is retained in memory in the
           XML::Simple module's namespace.  Subsequent calls to parse the same file will return a  reference  to
           this structure.  This cached version will persist only for the life of the Perl interpreter (which in
           the case of mod_perl for example, may be some significant time).

           Because each caller receives a reference to the same data structure, a change made by one caller will
           be visible to all.  For this reason, the reference returned should be treated as read-only.

       memcopy
           This scheme works identically to 'memshare' (above) except that each caller receives a reference to a
           new  data  structure  which  is  a copy of the cached version.  Copying the data structure will add a
           little processing overhead, therefore this scheme should only be used where  the  caller  intends  to
           modify  the  data  structure  (or  wishes to protect itself from others who might).  This scheme uses
           Storable.pm to perform the copy.

       Warning! The memory-based caching schemes compare the timestamp on the file to the time when it was  last
       parsed.   If  the  file is stored on an NFS filesystem (or other network share) and the clock on the file
       server is not exactly synchronised with the clock where your script is run, updates  to  the  source  XML
       file may appear to be ignored.

   ContentKey => 'keyname' # in+out - seldom used
       When  text  content  is  parsed  to a hash value, this option lets you specify a name for the hash key to
       override the default 'content'.  So for example:

         XMLin('<opt one="1">Text</opt>', ContentKey => 'text')

       will parse to:

         { 'one' => 1, 'text' => 'Text' }

       instead of:

         { 'one' => 1, 'content' => 'Text' }

       "XMLout()" will also honour the value of this option when converting a hashref to XML.

       You can also prefix your selected key name with a '-' character to have "XMLin()" try a little harder  to
       eliminate unnecessary 'content' keys after array folding.  For example:

         XMLin(
           '<opt><item name="one">First</item><item name="two">Second</item></opt>',
           KeyAttr => {item => 'name'},
           ForceArray => [ 'item' ],
           ContentKey => '-content'
         )

       will parse to:

         {
           'item' => {
             'one' =>  'First'
             'two' =>  'Second'
           }
         }

       rather than this (without the '-'):

         {
           'item' => {
             'one' => { 'content' => 'First' }
             'two' => { 'content' => 'Second' }
           }
         }

   DataHandler => code_ref # in - SAX only
       When you use an XML::Simple object as a SAX handler, it will return a 'simple tree' data structure in the
       same  format as "XMLin()" would return.  If this option is set (to a subroutine reference), then when the
       tree is built the subroutine will be called and passed two arguments:  a  reference  to  the  XML::Simple
       object  and  a  reference to the data tree.  The return value from the subroutine will be returned to the
       SAX driver.  (See "SAX SUPPORT" for more details).

   ForceArray => 1 # in - important
       This option should be set to '1' to force nested elements to be represented as arrays even when there  is
       only one.  Eg, with ForceArray enabled, this XML:

           <opt>
             <name>value</name>
           </opt>

       would parse to this:

           {
             'name' => [
                         'value'
                       ]
           }

       instead of this (the default):

           {
             'name' => 'value'
           }

       This  option  is  especially useful if the data structure is likely to be written back out as XML and the
       default behaviour of rolling single nested elements up into attributes is not desirable.

       If you are using the array folding feature, you should almost certainly enable this option.   If  you  do
       not, single nested elements will not be parsed to arrays and therefore will not be candidates for folding
       to  a  hash.  (Given that the default value of 'KeyAttr' enables array folding, the default value of this
       option should probably also have been enabled too - sorry).

   ForceArray => [ names ] # in - important
       This alternative (and preferred) form of the 'ForceArray' option allows you to specify a list of  element
       names  which  should  always  be  forced  into  an array representation, rather than the 'all or nothing'
       approach above.

       It is also possible (since version 2.05) to include compiled  regular  expressions  in  the  list  -  any
       element  names  which  match  the  pattern  will be forced to arrays.  If the list contains only a single
       regex, then it is not necessary to enclose it in an arrayref.  Eg:

         ForceArray => qr/_list$/

   ForceContent => 1 # in - seldom used
       When "XMLin()" parses elements which have text content as well as attributes, the text  content  must  be
       represented as a hash value rather than a simple scalar.  This option allows you to force text content to
       always parse to a hash value even when there are no attributes.  So for example:

         XMLin('<opt><x>text1</x><y a="2">text2</y></opt>', ForceContent => 1)

       will parse to:

         {
           'x' => {           'content' => 'text1' },
           'y' => { 'a' => 2, 'content' => 'text2' }
         }

       instead of:

         {
           'x' => 'text1',
           'y' => { 'a' => 2, 'content' => 'text2' }
         }

   GroupTags => { grouping tag => grouped tag } # in+out - handy
       You  can  use  this  option  to  eliminate  extra levels of indirection in your Perl data structure.  For
       example this XML:

         <opt>
          <searchpath>
            <dir>/usr/bin</dir>
            <dir>/usr/local/bin</dir>
            <dir>/usr/X11/bin</dir>
          </searchpath>
        </opt>

       Would normally be read into a structure like this:

         {
           searchpath => {
                           dir => [ '/usr/bin', '/usr/local/bin', '/usr/X11/bin' ]
                         }
         }

       But when read in with the appropriate value for 'GroupTags':

         my $opt = XMLin($xml, GroupTags => { searchpath => 'dir' });

       It will return this simpler structure:

         {
           searchpath => [ '/usr/bin', '/usr/local/bin', '/usr/X11/bin' ]
         }

       The grouping element ("<searchpath>" in the example) must not contain any attributes  or  elements  other
       than the grouped element.

       You  can  specify multiple 'grouping element' to 'grouped element' mappings in the same hashref.  If this
       option is combined with "KeyAttr", the array folding will occur first and then the grouped element  names
       will be eliminated.

       "XMLout"  will  also  use  the  grouptag  mappings  to re-introduce the tags around the grouped elements.
       Beware though that this will occur in all places that the 'grouping tag' name occurs - you probably don't
       want to use the same name for elements as well as attributes.

   Handler => object_ref # out - SAX only
       Use the 'Handler' option to have "XMLout()" generate SAX events rather than returning a  string  of  XML.
       For more details see "SAX SUPPORT" below.

       Note:  the  current  implementation  of  this  option  generates a string of XML and uses a SAX parser to
       translate it into SAX events.  The normal encoding rules apply here - your  data  must  be  UTF8  encoded
       unless you specify an alternative encoding via the 'XMLDecl' option; and by the time the data reaches the
       handler  object,  it will be in UTF8 form regardless of the encoding you supply.  A future implementation
       of this option may generate the events directly.

   KeepRoot => 1 # in+out - handy
       In its attempt to return  a  data  structure  free  of  superfluous  detail  and  unnecessary  levels  of
       indirection,  "XMLin()"  normally  discards  the root element name.  Setting the 'KeepRoot' option to '1'
       will cause the root element name to be retained.  So after executing this code:

         $config = XMLin('<config tempdir="/tmp" />', KeepRoot => 1)

       You'll be able to  reference  the  tempdir  as  "$config->{config}->{tempdir}"  instead  of  the  default
       "$config->{tempdir}".

       Similarly,  setting  the  'KeepRoot'  option  to '1' will tell "XMLout()" that the data structure already
       contains a root element name and it is not necessary to add another.

   KeyAttr => [ list ] # in+out - important
       This option controls the 'array folding' feature which translates nested elements  from  an  array  to  a
       hash.  It also controls the 'unfolding' of hashes to arrays.

       For example, this XML:

           <opt>
             <user login="grep" fullname="Gary R Epstein" />
             <user login="stty" fullname="Simon T Tyson" />
           </opt>

       would, by default, parse to this:

           {
             'user' => [
                         {
                           'login' => 'grep',
                           'fullname' => 'Gary R Epstein'
                         },
                         {
                           'login' => 'stty',
                           'fullname' => 'Simon T Tyson'
                         }
                       ]
           }

       If the option 'KeyAttr => "login"' were used to specify that the 'login' attribute is a key, the same XML
       would parse to:

           {
             'user' => {
                         'stty' => {
                                     'fullname' => 'Simon T Tyson'
                                   },
                         'grep' => {
                                     'fullname' => 'Gary R Epstein'
                                   }
                       }
           }

       The  key  attribute  names  should  be supplied in an arrayref if there is more than one.  "XMLin()" will
       attempt to match attribute names in the order supplied.  "XMLout()" will use  the  first  attribute  name
       supplied when 'unfolding' a hash into an array.

       Note 1: The default value for 'KeyAttr' is ['name', 'key', 'id'].  If you do not want folding on input or
       unfolding on output you must set this option to an empty list to disable the feature.

       Note  2:  If  you  wish  to  use  this  option,  you should also enable the "ForceArray" option.  Without
       'ForceArray', a single nested element will be rolled up into a scalar rather than an array and  therefore
       will not be folded (since only arrays get folded).

   KeyAttr => { list } # in+out - important
       This alternative (and preferred) method of specifying the key attributes allows more fine grained control
       over  which elements are folded and on which attributes.  For example the option 'KeyAttr => { package =>
       'id' } will cause any package elements to be folded on the 'id' attribute.  No other elements which  have
       an 'id' attribute will be folded at all.

       Note: "XMLin()" will generate a warning (or a fatal error in "STRICT MODE") if this syntax is used and an
       element  which  does not have the specified key attribute is encountered (eg: a 'package' element without
       an 'id' attribute, to use the example above).  Warnings can be suppressed with the lexical "no warnings;"
       pragma or "no warnings 'XML::Simple';".

       Two further variations are made possible by prefixing a '+' or a '-' character to the attribute name:

       The option 'KeyAttr => { user => "+login" }' will cause this XML:

           <opt>
             <user login="grep" fullname="Gary R Epstein" />
             <user login="stty" fullname="Simon T Tyson" />
           </opt>

       to parse to this data structure:

           {
             'user' => {
                         'stty' => {
                                     'fullname' => 'Simon T Tyson',
                                     'login'    => 'stty'
                                   },
                         'grep' => {
                                     'fullname' => 'Gary R Epstein',
                                     'login'    => 'grep'
                                   }
                       }
           }

       The '+' indicates that the value of the key attribute should be copied rather than moved  to  the  folded
       hash key.

       A '-' prefix would produce this result:

           {
             'user' => {
                         'stty' => {
                                     'fullname' => 'Simon T Tyson',
                                     '-login'    => 'stty'
                                   },
                         'grep' => {
                                     'fullname' => 'Gary R Epstein',
                                     '-login'    => 'grep'
                                   }
                       }
           }

       As described earlier, "XMLout" will ignore hash keys starting with a '-'.

   NoAttr => 1 # in+out - handy
       When  used  with  "XMLout()",  the generated XML will contain no attributes.  All hash key/values will be
       represented as nested elements instead.

       When used with "XMLin()", any attributes in the XML will be ignored.

   NoEscape => 1 # out - seldom used
       By default, "XMLout()" will translate the characters '<', '>', '&' and '"' to '&lt;', '&gt;', '&amp;' and
       '&quot' respectively.  Use this option to suppress escaping (presumably because  you've  already  escaped
       the data in some more sophisticated manner).

   NoIndent => 1 # out - seldom used
       Set  this  option to 1 to disable "XMLout()"'s default 'pretty printing' mode.  With this option enabled,
       the XML output will all be on one line (unless there are newlines in the data) - this may be  easier  for
       downstream processing.

   NoSort => 1 # out - seldom used
       Newer  versions  of XML::Simple sort elements and attributes alphabetically (*), by default.  Enable this
       option to suppress the sorting - possibly for backwards compatibility.

       * Actually, sorting is alphabetical but 'key' attribute or element names (as in  'KeyAttr')  sort  first.
       Also, when a hash of hashes is 'unfolded', the elements are sorted alphabetically by the value of the key
       field.

   NormaliseSpace => 0 | 1 | 2 # in - handy
       This option controls how whitespace in text content is handled.  Recognised values for the option are:

       •   0  =  (default)  whitespace  is  passed  through unaltered (except of course for the normalisation of
           whitespace in attribute values which is mandated by the XML recommendation)

       •   1 = whitespace is normalised in any value used as a hash key (normalising means removing leading  and
           trailing whitespace and collapsing sequences of whitespace characters to a single space)

       •   2 = whitespace is normalised in all text content

       Note: you can spell this option with a 'z' if that is more natural for you.

   NSExpand => 1 # in+out handy - SAX only
       This  option  controls  namespace  expansion - the translation of element and attribute names of the form
       'prefix:name' to '{uri}name'.  For  example  the  element  name  'xsl:template'  might  be  expanded  to:
       '{http://www.w3.org/1999/XSL/Transform}template'.

       By  default,  "XMLin()"  will return element names and attribute names exactly as they appear in the XML.
       Setting this option to 1 will cause all element and attribute names  to  be  expanded  to  include  their
       namespace prefix.

       Note: You must be using a SAX parser for this option to work (ie: it does not work with XML::Parser).

       This  option  also  controls whether "XMLout()" performs the reverse translation from '{uri}name' back to
       'prefix:name'.  The default is no translation.  If your data contains expanded names, you should set this
       option to 1 otherwise "XMLout" will emit XML which is not well formed.

       Note: You must have the XML::NamespaceSupport module installed if you want "XMLout()" to  translate  URIs
       back to prefixes.

   NumericEscape => 0 | 1 | 2 # out - handy
       Use  this  option  to have 'high' (non-ASCII) characters in your Perl data structure converted to numeric
       entities (eg: &#8364;) in the XML output.  Three levels are possible:

       0 - default: no numeric escaping (OK if you're writing out UTF8)

       1 - only characters above 0xFF are escaped (ie:  characters  in  the  0x80-FF  range  are  not  escaped),
       possibly useful with ISO8859-1 output

       2 - all characters above 0x7F are escaped (good for plain ASCII output)

   OutputFile => <file specifier> # out - handy
       The  default behaviour of "XMLout()" is to return the XML as a string.  If you wish to write the XML to a
       file, simply supply the filename using the 'OutputFile' option.

       This option also accepts an IO handle object - especially useful in Perl 5.8.0 and later for output using
       an encoding other than UTF-8, eg:

         open my $fh, '>:encoding(iso-8859-1)', $path or die "open($path): $!";
         XMLout($ref, OutputFile => $fh);

       Note, XML::Simple does not require that the object you pass in to the  OutputFile  option  inherits  from
       IO::Handle - it simply assumes the object supports a "print" method.

   ParserOpts => [ XML::Parser Options ] # in - don't use this
       Note:  This option is now officially deprecated.  If you find it useful, email the author with an example
       of what you use it for.  Do not use this option to set the ProtocolEncoding, that's just  plain  wrong  -
       fix the XML.

       This  option allows you to pass parameters to the constructor of the underlying XML::Parser object (which
       of course assumes you're not using SAX).

   RootName => 'string' # out - handy
       By default, when "XMLout()" generates XML, the root element will be named 'opt'.  This option allows  you
       to specify an alternative name.

       Specifying  either  undef  or  the  empty  string  for  the RootName option will produce XML with no root
       elements.  In most cases the resulting XML fragment will not be 'well formed' and therefore could not  be
       read  back  in  by  "XMLin()".   Nevertheless,  the  option  has  been  found  to  be  useful  in certain
       circumstances.

   SearchPath => [ list ] # in - handy
       If you pass "XMLin()" a filename, but the filename include no  directory  component,  you  can  use  this
       option  to specify which directories should be searched to locate the file.  You might use this option to
       search first in the user's home directory, then in a global directory such as /etc.

       If a filename is provided to "XMLin()" but SearchPath is not defined, the file is assumed to  be  in  the
       current directory.

       If  the first parameter to "XMLin()" is undefined, the default SearchPath will contain only the directory
       in which the script itself is located.  Otherwise the default SearchPath will be empty.

   StrictMode => 1 | 0  # in+out seldom used
       This option allows you to turn "STRICT MODE" on or off for a particular call, regardless  of  whether  it
       was enabled at the time XML::Simple was loaded.

   SuppressEmpty => 1 | '' | undef # in+out - handy
       This  option  controls  what "XMLin()" should do with empty elements (no attributes and no content).  The
       default behaviour is to represent them as empty hashes.  Setting this option to a true value (eg: 1) will
       cause empty elements to be skipped altogether.  Setting the option to 'undef' or the  empty  string  will
       cause  empty  elements  to  be  represented as the undefined value or the empty string respectively.  The
       latter two alternatives are a little easier to test for in your code than a hash with no keys.

       The option also controls what "XMLout()" does with undefined values.  Setting the option to undef  causes
       undefined  values  to  be output as empty elements (rather than empty attributes), it also suppresses the
       generation of warnings about undefined values.  Setting the  option  to  a  true  value  (eg:  1)  causes
       undefined values to be skipped altogether on output.

   ValueAttr => [ names ] # in - handy
       Use this option to deal elements which always have a single attribute and no content.  Eg:

         <opt>
           <colour value="red" />
           <size   value="XXL" />
         </opt>

       Setting "ValueAttr => [ 'value' ]" will cause the above XML to parse to:

         {
           colour => 'red',
           size   => 'XXL'
         }

       instead of this (the default):

         {
           colour => { value => 'red' },
           size   => { value => 'XXL' }
         }

       Note:  This  form of the ValueAttr option is not compatible with "XMLout()" - since the attribute name is
       discarded at parse time, the original XML cannot be reconstructed.

   ValueAttr => { element => attribute, ... } # in+out - handy
       This (preferred) form of the ValueAttr option requires you to specify both the element and the  attribute
       names.  This is not only safer, it also allows the original XML to be reconstructed by "XMLout()".

       Note: You probably don't want to use this option and the NoAttr option at the same time.

   Variables => { name => value } # in - handy
       This  option allows variables in the XML to be expanded when the file is read.  (there is no facility for
       putting the variable names back if you regenerate XML using "XMLout").

       A 'variable' is any text of the form "${name}" which occurs in an attribute value or in the text  content
       of  an  element.   If  'name'  matches a key in the supplied hashref, "${name}" will be replaced with the
       corresponding value from the hashref.  If no matching key is found, the variable will  not  be  replaced.
       Names must match the regex: "[\w.]+" (ie: only 'word' characters and dots are allowed).

   VarAttr => 'attr_name' # in - handy
       In addition to the variables defined using "Variables", this option allows variables to be defined in the
       XML.  A variable definition consists of an element with an attribute called 'attr_name' (the value of the
       "VarAttr"  option).  The value of the attribute will be used as the variable name and the text content of
       the element will be used as the value.  A variable defined in this way will override a  variable  defined
       using the "Variables" option.  For example:

         XMLin( '<opt>
                   <dir name="prefix">/usr/local/apache</dir>
                   <dir name="exec_prefix">${prefix}</dir>
                   <dir name="bindir">${exec_prefix}/bin</dir>
                 </opt>',
                VarAttr => 'name', ContentKey => '-content'
               );

       produces the following data structure:

         {
           dir => {
                    prefix      => '/usr/local/apache',
                    exec_prefix => '/usr/local/apache',
                    bindir      => '/usr/local/apache/bin',
                  }
         }

   XMLDecl => 1  or  XMLDecl => 'string'  # out - handy
       If  you want the output from "XMLout()" to start with the optional XML declaration, simply set the option
       to '1'.  The default XML declaration is:

               <?xml version='1.0' standalone='yes'?>

       If you want some other string (for example to declare an encoding value), set the value of this option to
       the complete string you require.

OPTIONAL OO INTERFACE

       The procedural interface is both simple and convenient however there are a  couple  of  reasons  why  you
       might prefer to use the object oriented (OO) interface:

       •   to  define  a  set  of  default  values  which should be used on all subsequent calls to "XMLin()" or
           "XMLout()"

       •   to override methods in XML::Simple to provide customised behaviour

       The default values for the options described above are unlikely  to  suit  everyone.   The  OO  interface
       allows  you  to  effectively  override  XML::Simple's defaults with your preferred values.  It works like
       this:

       First create an XML::Simple parser object with your preferred defaults:

         my $xs = XML::Simple->new(ForceArray => 1, KeepRoot => 1);

       then call "XMLin()" or "XMLout()" as a method of that object:

         my $ref = $xs->XMLin($xml);
         my $xml = $xs->XMLout($ref);

       You can also specify options when you make the method calls and these values  will  be  merged  with  the
       values specified when the object was created.  Values specified in a method call take precedence.

       Note:  when  called  as  methods,  the  "XMLin()"  and "XMLout()" routines may be called as "xml_in()" or
       "xml_out()".  The method names are aliased so the only difference is the aesthetics.

   Parsing Methods
       You can explicitly call one  of  the  following  methods  rather  than  rely  on  the  "xml_in()"  method
       automatically determining whether the target to be parsed is a string, a file or a filehandle:

       parse_string(text)
           Works  exactly  like  the  "xml_in()"  method but assumes the first argument is a string of XML (or a
           reference to a scalar containing a string of XML).

       parse_file(filename)
           Works exactly like the "xml_in()" method but assumes the  first  argument  is  the  name  of  a  file
           containing XML.

       parse_fh(file_handle)
           Works  exactly like the "xml_in()" method but assumes the first argument is a filehandle which can be
           read to get XML.

   Hook Methods
       You can make your own class which inherits  from  XML::Simple  and  overrides  certain  behaviours.   The
       following  methods  may  provide useful 'hooks' upon which to hang your modified behaviour.  You may find
       other undocumented methods by examining the source,  but  those  may  be  subject  to  change  in  future
       releases.

       new_xml_parser()
           This method will be called when a new XML::Parser object must be constructed (either because XML::SAX
           is not installed or XML::Parser is preferred).

       handle_options(direction, name => value ...)
           This  method  will be called when one of the parsing methods or the "XMLout()" method is called.  The
           initial argument will be a string (either 'in' or 'out') and the remaining  arguments  will  be  name
           value pairs.

       default_config_file()
           Calculates  and  returns  the  name  of  the  file which should be parsed if no filename is passed to
           "XMLin()" (default: "$0.xml").

       build_simple_tree(filename, string)
           Called from "XMLin()" or any of the parsing methods.  Takes either a file name as the first  argument
           or "undef" followed by a 'string' as the second argument.  Returns a simple tree data structure.  You
           could override this method to apply your own transformations before the data structure is returned to
           the caller.

       new_hashref()
           When  the  'simple  tree'  data  structure  is  being built, this method will be called to create any
           required anonymous hashrefs.

       sorted_keys(name, hashref)
           Called when "XMLout()" is translating a hashref to XML.  This routine returns a list of hash keys  in
           the order that the corresponding attributes/elements should appear in the output.

       escape_value(string)
           Called  from  "XMLout()", takes a string and returns a copy of the string with XML character escaping
           rules applied.

       escape_attr(string)
           Called from "XMLout()", to handle attribute values.  By default, just calls "escape_value()", but you
           can override this method if you want attributes escaped differently than text content.

       numeric_escape(string)
           Called from "escape_value()",  to  handle  non-ASCII  characters  (depending  on  the  value  of  the
           NumericEscape option).

       copy_hash(hashref, extra_key => value, ...)
           Called from "XMLout()", when 'unfolding' a hash of hashes into an array of hashes.  You might wish to
           override this method if you're using tied hashes and don't want them to get untied.

   Cache Methods
       XML::Simple implements three caching schemes ('storable', 'memshare' and 'memcopy').  You can implement a
       custom caching scheme by implementing two methods - one for reading from the cache and one for writing to
       it.

       For  example,  you  might implement a new 'dbm' scheme that stores cached data structures using the MLDBM
       module.  First, you would add a "cache_read_dbm()" method which accepted a filename for use as  a  lookup
       key  and  returned  a  data  structure  on  success,  or  undef  on failure.  Then, you would implement a
       "cache_read_dbm()" method which accepted a data structure and a filename.

       You would use this caching scheme by specifying the option:

         Cache => [ 'dbm' ]

STRICT MODE

       If you import the XML::Simple routines like this:

         use XML::Simple qw(:strict);

       the following common mistakes will be detected and treated as fatal errors

       •   Failing to explicitly set the "KeyAttr" option - if you can't be bothered reading about this  option,
           turn it off with: KeyAttr => [ ]

       •   Failing  to  explicitly  set  the  "ForceArray"  option - if you can't be bothered reading about this
           option, set it to the safest mode with: ForceArray => 1

       •   Setting ForceArray to an array, but failing to list all the elements from the KeyAttr hash.

       •   Data error - KeyAttr is set to say { part => 'partnum' } but the XML  contains  one  or  more  <part>
           elements without a 'partnum' attribute (or nested element).  Note: if strict mode is not set but "use
           warnings;" is in force, this condition triggers a warning.

       •   Data  error  -  as  above,  but non-unique values are present in the key attribute (eg: more than one
           <part> element with the same partnum).  This will also trigger  a  warning  if  strict  mode  is  not
           enabled.

       •   Data error - as above, but value of key attribute (eg: partnum) is not a scalar string (due to nested
           elements etc).  This will also trigger a warning if strict mode is not enabled.

SAX SUPPORT

       From version 1.08_01, XML::Simple includes support for SAX (the Simple API for XML) - specifically SAX2.

       In  a  typical  SAX  application,  an  XML parser (or SAX 'driver') module generates SAX events (start of
       element, character data, end of element, etc) as it  parses  an  XML  document  and  a  'handler'  module
       processes  the  events  to  extract the required data.  This simple model allows for some interesting and
       powerful possibilities:

       •   Applications written to the SAX API can extract data from  huge  XML  documents  without  the  memory
           overheads of a DOM or tree API.

       •   The SAX API allows for plug and play interchange of parser modules without having to change your code
           to  fit  a  new  module's  API.  A number of SAX parsers are available with capabilities ranging from
           extreme portability to blazing performance.

       •   A SAX 'filter' module can implement both a handler interface  for  receiving  data  and  a  generator
           interface  for  passing modified data on to a downstream handler.  Filters can be chained together in
           'pipelines'.

       •   One filter module might split a data stream to direct data to two or more downstream handlers.

       •   Generating SAX events is not the exclusive preserve of XML parsing modules.  For  example,  a  module
           might  extract  data  from  a  relational  database  using  DBI  and pass it on to a SAX pipeline for
           filtering and formatting.

       XML::Simple can operate at either end of a SAX pipeline.  For example, you can take a data  structure  in
       the form of a hashref and pass it into a SAX pipeline using the 'Handler' option on "XMLout()":

         use XML::Simple;
         use Some::SAX::Filter;
         use XML::SAX::Writer;

         my $ref = {
                      ....   # your data here
                   };

         my $writer = XML::SAX::Writer->new();
         my $filter = Some::SAX::Filter->new(Handler => $writer);
         my $simple = XML::Simple->new(Handler => $filter);
         $simple->XMLout($ref);

       You  can  also put XML::Simple at the opposite end of the pipeline to take advantage of the simple 'tree'
       data structure once the relevant data has been isolated through filtering:

         use XML::SAX;
         use Some::SAX::Filter;
         use XML::Simple;

         my $simple = XML::Simple->new(ForceArray => 1, KeyAttr => ['partnum']);
         my $filter = Some::SAX::Filter->new(Handler => $simple);
         my $parser = XML::SAX::ParserFactory->parser(Handler => $filter);

         my $ref = $parser->parse_uri('some_huge_file.xml');

         print $ref->{part}->{'555-1234'};

       You can build a filter by using an XML::Simple object as a handler and setting its DataHandler option  to
       point  to  a  routine  which  takes  the  resulting tree, modifies it and sends it off as SAX events to a
       downstream handler:

         my $writer = XML::SAX::Writer->new();
         my $filter = XML::Simple->new(
                        DataHandler => sub {
                                         my $simple = shift;
                                         my $data = shift;

                                         # Modify $data here

                                         $simple->XMLout($data, Handler => $writer);
                                       }
                      );
         my $parser = XML::SAX::ParserFactory->parser(Handler => $filter);

         $parser->parse_uri($filename);

       Note: In this last example, the 'Handler' option was specified in the call to  "XMLout()"  but  it  could
       also have been specified in the constructor.

ENVIRONMENT

       If  you  don't  care  which parser module XML::Simple uses then skip this section entirely (it looks more
       complicated than it really is).

       XML::Simple will default to using a SAX parser  if  one  is  available  or  XML::Parser  if  SAX  is  not
       available.

       You   can   dictate   which   parser   module   is  used  by  setting  either  the  environment  variable
       'XML_SIMPLE_PREFERRED_PARSER' or the  package  variable  $XML::Simple::PREFERRED_PARSER  to  contain  the
       module name.  The following rules are used:

       •   The  package  variable  takes precedence over the environment variable if both are defined.  To force
           XML::Simple to ignore the environment settings and use its default rules, you  can  set  the  package
           variable to an empty string.

       •   If  the  'preferred  parser'  is  set  to the string 'XML::Parser', then XML::Parser will be used (or
           "XMLin()" will die if XML::Parser is not installed).

       •   If the 'preferred parser' is set to some other value, then it is assumed to be  the  name  of  a  SAX
           parser  module  and  is  passed  to  XML::SAX::ParserFactory.   If  XML::SAX is not installed, or the
           requested parser module is not installed, then "XMLin()" will die.

       •   If the 'preferred parser' is not defined at all (the normal default state), an attempt will  be  made
           to  load  XML::SAX.   If  XML::SAX  is  installed, then a parser module will be selected according to
           XML::SAX::ParserFactory's normal rules (which typically means the last SAX parser installed).

       •   if the 'preferred parser' is not defined and XML::SAX is not  installed,  then  XML::Parser  will  be
           used.  "XMLin()" will die if XML::Parser is not installed.

       Note: The XML::SAX distribution includes an XML parser written entirely in Perl.  It is very portable but
       it is not very fast.  You should consider installing XML::LibXML or XML::SAX::Expat if they are available
       for your platform.

ERROR HANDLING

       The  XML  standard is very clear on the issue of non-compliant documents.  An error in parsing any single
       element (for example a missing end tag) must cause the whole document to be rejected.   XML::Simple  will
       die with an appropriate message if it encounters a parsing error.

       If  dying  is not appropriate for your application, you should arrange to call "XMLin()" in an eval block
       and look for errors in $@.  eg:

           my $config = eval { XMLin() };
           PopUpMessage($@) if($@);

       Note, there is a common misconception that use of eval will significantly slow down a script.  While that
       may be true when the code being eval'd is in a string, it is not true of code like the sample above.

EXAMPLES

       When "XMLin()" reads the following very simple piece of XML:

           <opt username="testuser" password="frodo"></opt>

       it returns the following data structure:

           {
             'username' => 'testuser',
             'password' => 'frodo'
           }

       The identical result could have been produced with this alternative XML:

           <opt username="testuser" password="frodo" />

       Or this (although see 'ForceArray' option for variations):

           <opt>
             <username>testuser</username>
             <password>frodo</password>
           </opt>

       Repeated nested elements are represented as anonymous arrays:

           <opt>
             <person firstname="Joe" lastname="Smith">
               <email>joe@smith.com</email>
               <email>jsmith@yahoo.com</email>
             </person>
             <person firstname="Bob" lastname="Smith">
               <email>bob@smith.com</email>
             </person>
           </opt>

           {
             'person' => [
                           {
                             'email' => [
                                          'joe@smith.com',
                                          'jsmith@yahoo.com'
                                        ],
                             'firstname' => 'Joe',
                             'lastname' => 'Smith'
                           },
                           {
                             'email' => 'bob@smith.com',
                             'firstname' => 'Bob',
                             'lastname' => 'Smith'
                           }
                         ]
           }

       Nested elements with a recognised key attribute are transformed (folded) from an array into a hash  keyed
       on the value of that attribute (see the "KeyAttr" option):

           <opt>
             <person key="jsmith" firstname="Joe" lastname="Smith" />
             <person key="tsmith" firstname="Tom" lastname="Smith" />
             <person key="jbloggs" firstname="Joe" lastname="Bloggs" />
           </opt>

           {
             'person' => {
                           'jbloggs' => {
                                          'firstname' => 'Joe',
                                          'lastname' => 'Bloggs'
                                        },
                           'tsmith' => {
                                         'firstname' => 'Tom',
                                         'lastname' => 'Smith'
                                       },
                           'jsmith' => {
                                         'firstname' => 'Joe',
                                         'lastname' => 'Smith'
                                       }
                         }
           }

       The <anon> tag can be used to form anonymous arrays:

           <opt>
             <head><anon>Col 1</anon><anon>Col 2</anon><anon>Col 3</anon></head>
             <data><anon>R1C1</anon><anon>R1C2</anon><anon>R1C3</anon></data>
             <data><anon>R2C1</anon><anon>R2C2</anon><anon>R2C3</anon></data>
             <data><anon>R3C1</anon><anon>R3C2</anon><anon>R3C3</anon></data>
           </opt>

           {
             'head' => [
                         [ 'Col 1', 'Col 2', 'Col 3' ]
                       ],
             'data' => [
                         [ 'R1C1', 'R1C2', 'R1C3' ],
                         [ 'R2C1', 'R2C2', 'R2C3' ],
                         [ 'R3C1', 'R3C2', 'R3C3' ]
                       ]
           }

       Anonymous  arrays can be nested to arbitrary levels and as a special case, if the surrounding tags for an
       XML document contain only an anonymous array the arrayref will be returned directly rather than the usual
       hashref:

           <opt>
             <anon><anon>Col 1</anon><anon>Col 2</anon></anon>
             <anon><anon>R1C1</anon><anon>R1C2</anon></anon>
             <anon><anon>R2C1</anon><anon>R2C2</anon></anon>
           </opt>

           [
             [ 'Col 1', 'Col 2' ],
             [ 'R1C1', 'R1C2' ],
             [ 'R2C1', 'R2C2' ]
           ]

       Elements which only contain text content will simply be represented as a scalar.  Where  an  element  has
       both  attributes  and text content, the element will be represented as a hashref with the text content in
       the 'content' key (see the "ContentKey" option):

         <opt>
           <one>first</one>
           <two attr="value">second</two>
         </opt>

         {
           'one' => 'first',
           'two' => { 'attr' => 'value', 'content' => 'second' }
         }

       Mixed content (elements which contain both text content and nested elements) will be not  be  represented
       in  a useful way - element order and significant whitespace will be lost.  If you need to work with mixed
       content, then XML::Simple is not the right tool for your job - check out the next section.

WHERE TO FROM HERE?

       XML::Simple is able to present a simple API because it makes some  assumptions  on  your  behalf.   These
       include:

       •   You're not interested in text content consisting only of whitespace

       •   You don't mind that when things get slurped into a hash the order is lost

       •   You don't want fine-grained control of the formatting of generated XML

       •   You would never use a hash key that was not a legal XML element name

       •   You don't need help converting between different encodings

       In  a serious XML project, you'll probably outgrow these assumptions fairly quickly.  This section of the
       document used to offer some advice on choosing a more powerful option.  That advice has  now  grown  into
       the 'Perl-XML FAQ' document which you can find at: <http://perl-xml.sourceforge.net/faq/>

       The  advice  in  the  FAQ  boils  down to a quick explanation of tree versus event based parsers and then
       recommends:

       For event based parsing, use SAX (do not set out to write any new code for XML::Parser's handler API - it
       is obsolete).

       For tree-based parsing, you could choose between the 'Perlish' approach of XML::Twig and  more  standards
       based DOM implementations - preferably one with XPath support such as XML::LibXML.

SEE ALSO

       XML::Simple requires either XML::Parser or XML::SAX.

       To generate documents with namespaces, XML::NamespaceSupport is required.

       The optional caching functions require Storable.

       Answers  to  Frequently  Asked  Questions  about  XML::Simple  are  bundled  with  this  distribution as:
       XML::Simple::FAQ

COPYRIGHT

       Copyright 1999-2004 Grant McLean <grantm@cpan.org>

       This library is free software; you can redistribute it and/or modify it under  the  same  terms  as  Perl
       itself.

perl v5.36.0                                       2022-12-12                                   XML::Simple(3pm)