XML::Simple(3)

🦋 XML::Simple(3) 🦋

okay bestie, buckle up 💅 this is XML::Simple — "An API for simple XML files" — and it's a whole journey. It's giving iconic-but-problematic. Let's get into it ✨

---

✨ SYNOPSIS ✨

FIRST THINGS FIRST, and I literally cannot say this loud enough:

PLEASE DO NOT USE THIS MODULE IN NEW CODE.

no like fr fr 🫶 but if you do ignore this warning and use it anyway (main character energy, respect), 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, like, the object oriented way (fancy 👑):

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 peek at "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. okay that's such a classic gotcha, iykyk 😭

---

💀 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 at 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 🙈)
• 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. no new toys, bestie, that ship has sailed ⛵

---

🌈 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 — and why? because no filename or XML string was passed as the first argument to XMLin(), so the name and location of the XML file will be inferred from name and location of the script 🧚✨ cute, right?

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. it's giving lifesaver, ngl 💖

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(). lowercase girlies rise 🙈

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). ok so the dash is basically the "do not perceive her" marker, love that for us 💅

⚠️ 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). literally it will just hand you broken XML with a smile and you'll find out later 💀

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:

Quick vibe check on the little difficulty labels first, because they’re literally your roadmap:

• 'important' — don’t use the module until you understand this one. No skipping, bestie.
• '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:

...so the data structure you end up with wraps the folded hashes under the parent element name that held all the repeated elements:

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

If there's more than one key attribute name you gotta hand them over in an arrayref, okay? XMLin() tries to match the attribute names in the order you supplied them (so order matters, bestie, pick wisely). And XMLout() uses the first attribute name you gave when it 'unfolds' a hash back into an array. 💅

Note 1: the default value for 'KeyAttr' is ['name', 'key', 'id']. If you don't want folding on input or unfolding on output, you MUST set this option to an empty list to switch the whole feature off. No cap.

Note 2: if you're gonna use this option, you should also enable the ForceArray option. Why? Because without 'ForceArray', a single nested element gets rolled up into a scalar instead of an array — and scalars don't get folded (only arrays get folded, periodt).

🔑 KeyAttr => { list } # in+out - important

Okay this is the alternative method, and honestly the preferred one — it gives you way more fine-grained control over which elements get folded and on which attributes. Like, 'KeyAttr => { package => 'id' }' makes any package elements fold on their 'id' attribute. And no other elements that happen to have an 'id' attribute get folded at all. Gatekeeping who folds — iconic behaviour tbh. ✨

Note: XMLin() will generate a warning (or a fatal error in "STRICT MODE" 😭) if you use this syntax and an element shows up that doesn't have the specified key attribute — e.g. a 'package' element without an 'id' attribute, to use the example above. You can suppress those warnings with the lexical no warnings; pragma or no warnings 'XML::Simple';.

Two more variations are possible if you prefix the attribute name with a + or a -:

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'
                        }
            }
}

So the + means the value of the key attribute gets copied rather than moved to the folded hash key. Keeping the original around — respectful. 🫶

A - prefix would give you this instead:

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

And like we said earlier, XMLout will ignore hash keys starting with a -. Bye bye felicia. 👋

🚫 NoAttr => 1 # in+out - handy

With XMLout(), the generated XML contains no attributes at all — every hash key/value gets represented as nested elements instead. With XMLin(), any attributes in the XML get straight up ignored. Nothing to see here. 🙈

🔤 NoEscape => 1 # out - seldom used

By default, XMLout() translates the characters '<', '>', '&' and '"' to '<', '>', '&' and '&quot' respectively. Use this option to suppress the escaping — presumably because you already escaped your data in some more sophisticated manner. You do you, babe. 💅

📏 NoIndent => 1 # out - seldom used

Set this to 1 to disable XMLout()'s default 'pretty printing' mode. With it on, all the XML output lands on one single line (unless your data has newlines in it, obviously) — which may be easier for downstream processing. Compact queen. 🎀

🔀 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, iykyk.

• Actually, the sorting is alphabetical BUT the 'key' attribute or element names (as in 'KeyAttr') sort first. Also, when a hash of hashes gets 'unfolded', the elements are sorted alphabetically by the value of the key field. The more you know. ⭐

🧼 NormaliseSpace => 0 | 1 | 2 # in - handy

This one controls how whitespace in text content gets handled. The recognised values 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. Rules are rules.
• 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's more natural for you. Either spelling slays. 🌸

🌈 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() returns element names and attribute names exactly as they appear in the XML. Setting this option to 1 makes every element and attribute name expand to include its 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 at all. If your data contains expanded names, you should set this option to 1 — otherwise XMLout will emit XML that is not well formed, and we don't want that messy energy. 😭

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 to have 'high' (non-ASCII) characters in your Perl data structure converted to numeric entities (eg: €) in the XML output. Three levels, bestie:

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

Default XMLout() behaviour is to return the XML as a string. But if you want the XML written to a file, just hand over the filename using the 'OutputFile' option. Easy.

This option also accepts an IO handle object — especially useful in Perl 5.8.0 and later when you want output using an encoding other than UTF-8, like:

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

Note: XML::Simple does not require the object you pass to OutputFile to inherit from IO::Handle — it simply assumes the object supports a print method. Vibes-based duck typing, honestly. 🦋

⚙️ 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. And do NOT use this option to set the ProtocolEncoding — that's just plain wrong, fix the XML instead. 🚩

This option lets you 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 is named 'opt'. This option lets you specify an alternative name. Main character rename moment. 👑

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 won't be 'well formed' and therefore couldn't be read back in by XMLin(). Nevertheless, the option has been found useful in certain circumstances — chaotic but occasionally correct. 💀

🔎 SearchPath => [ list ] # in - handy

If you pass XMLin() a filename, but that filename includes no directory component, you can use this option to specify which directories should be searched to locate the file. Like, you might search first in the user's home directory, then in a global directory such as /etc. Detective work 🔍✨

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

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

🚨 StrictMode => 1 | 0 # in+out seldom used

This option lets you turn "STRICT MODE" on or off for a particular call — regardless of whether it was enabled back when XML::Simple was loaded. Flip the switch, bestie. 🔥

🕳️ SuppressEmpty => 1 | '' | undef # in+out - handy

This option controls what XMLin() does with empty elements (no attributes and no content). Default behaviour: they get represented as empty hashes. Setting this option to a true value (eg: 1) causes empty elements to be skipped altogether. Setting it to 'undef' or the empty string makes empty elements be represented as the undefined value or the empty string respectively. Those last two are a lil easier to test for in your code than a hash with no keys — trust. 🙈

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

💎 ValueAttr => [ names ] # in - handy

Use this option for 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' }
}

Flattened and gorgeous. 🎀

Note: this form of the ValueAttr option is not compatible with XMLout() — since the attribute name is discarded at parse time, the original XML can't be reconstructed. It's gone. Poof. 😭 That data is not coming back, so know that going in.

• ValueAttr => { element => attribute, ... } # in+out - handy — this is the preferred form of the ValueAttr option, and it wants you to specify both the element name and the attribute name. It's safer (slay), and it also lets XMLout() reconstruct the original XML. Iconic.

Note: you probably don't want to use this option and the NoAttr option at the same time. Just… don't, bestie. 💅

• Variables => { name => value } # in - handy — this one lets variables inside the XML get expanded when the file is read. But heads up: 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} that shows up in an attribute value or in the text content of an element. If name matches a key in the supplied hashref, ${name} gets 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 lets variables be defined in the XML. A variable definition is an element with an attribute called attr_name (the value of the VarAttr option). The value of the attribute gets used as the variable name, and the text content of the element gets used as the value. A variable defined 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, just 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. iykyk 💅

🎀 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. No cap.

• 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. (Yes, the original says cache_read_dbm() both times — we're keeping it exactly as written, bestie.)

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 🎷

ok so starting in version 1.08_01, XML::Simple rolled up with SAX support — and specifically SAX2, bestie. very demure, very mindful. ✨

So here's the vibe of a typical SAX app: an XML parser (aka a SAX "driver") module reads your XML doc and spits out SAX events — start of element, character data, end of element, that whole situation — and then a "handler" module picks those events up and pulls out the data you actually want. This simple lil model unlocks some genuinely iconic possibilities:

• Apps written against the SAX API can pull data out of huge XML documents with none of the memory overhead that a DOM or tree API drags around. no cap, your RAM stays unbothered. 💖
• The SAX API means plug-and-play swapping of parser modules — you don't have to rewrite your code to match some new module's API. And there are a bunch of SAX parsers out there, ranging from "extremely portable" all the way to "blazing performance". pick your fighter. 🔥
• A SAX "filter" module can be both a handler (receiving data) and a generator (passing modified data downstream to the next handler). Filters can be chained together into "pipelines". it's giving assembly line but make it cute. 🎀
• One filter module could split a data stream and send data off to two or more downstream handlers. multitasking queen. 👑
• Generating SAX events is not the exclusive preserve of XML parsing modules, btw. for example, a module might pull data out of a relational database using DBI and hand it off to a SAX pipeline for filtering and formatting. slay.

XML::Simple can sit at either end of a SAX pipeline. 🦋

Like — you can take a data structure in the form of a hashref and push 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);

And you can also park XML::Simple at the opposite end of the pipeline so you get to enjoy 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 also build a filter by using an XML::Simple object as a handler and setting its DataHandler option to point at a routine that 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. iykyk 💅

---

🌍 ENVIRONMENT 🌍

If you genuinely do not care which parser module XML::Simple uses, then skip this whole section, bestie. seriously. it looks way more complicated than it actually is. 🙈

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

You can dictate which parser module gets used by setting either the environment variable 'XML_SIMPLE_PREFERRED_PARSER' or the package variable $XML::Simple::PREFERRED_PARSER to contain the module name. Here are the rules, and yes there are five of them, stay with me:

• 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's assumed to be the name of a SAX parser module and gets 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 extremely clear on the whole non-compliant-documents situation. An error in parsing any single element (for example a missing end tag) must cause the whole document to be rejected. no partial credit, no mercy. XML::Simple will die with an appropriate message if it encounters a parsing error.

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

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

Note: there's a common misconception that using 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. fr fr, don't worry about it. 🧚

---

🌸 EXAMPLES 🌸

When XMLin() reads this very simple piece of XML:

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

it returns this data structure:

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

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

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

Or this one (although — see the '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 get transformed (folded) from an array into a hash keyed on the value of that attribute (see the "KeyAttr" option) — this is the glow-up right here:

<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. plot twist. 🌈

<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 that 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 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, bestie. 💜

🌈 WHERE TO FROM HERE? 🌈

okay so here's the thing — XML::Simple can serve you such a simple API because it's out here making a bunch of assumptions on your behalf, like a bestie ordering for you at a restaurant 😌💅. the assumptions are:

• you're not interested in text content that consists only of whitespace 🫧
• you don't mind that when things get slurped into a hash, the order is just... gone 😭 (it's giving "no thoughts, head empty")
• you don't want fine-grained control over the formatting of the XML that gets generated 🎀
• you would never use a hash key that wasn't a legal XML element name 👑
• you don't need any help converting between different encodings 🌸

in a serious XML project you'll probably outgrow these assumptions pretty quickly ngl. this section of the document used to offer some advice on choosing a more powerful option, but that advice has now grown up, gotten its own apartment, and become the 'Perl-XML FAQ' document, which you can find at:

<http://perl-xml.sourceforge.net/faq/>

the advice in the FAQ basically boils down to a quick explanation of tree-based vs event-based parsers, and then it recommends:

• for event based parsing — use SAX. and like, do not set out to write any new code for XML::Parser's handler API, it is obsolete 💀 fr fr.
• 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 — pick your fighter 🫶
• 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.

---

and that's the whole page, bestie 🎀 this iconic little doc shipped with perl v5.42.0, dated 2018-03-18 (you know the one — XML::Simple(3), iykyk 😌), and now you're all caught up. go forth and parse, no cap 💅✨🦋