When transforming a payload from one form to another it’s often necessary to map various fields. An example of this may be as simple as mapping from a country code to the full name of said country, i.e. AUS to Australia.

There several ways to achieve this, some more flexible than others.

To use the example of country code mapping, here’s the input data that we’re required to map/transform:

<countries>
    <country>AUS</country>
    <country>BRA</country>
    <country>GRC</country>
    <country>JPN</country>
    <country>GBR</country>
</countries>

External mapping file

First up is referring to an external file that contains the relevant mapping and using XPATH grab the correct value.

For an external mapping file we simply include the relevant path to the mapping file, but this could just as easily be an URL from the web, either of:

<xsl:variable name="countryList">../xml/countrylist.xml</xsl:variable>

or

<xsl:variable name="countryList">http://s3.amazonaws.com/thecuriousdev.com/countrylist.xml</xsl:variable>

This file simply consists of both the code and name for each country, i.e.

<?xml version="1.0" encoding="UTF-8"?>
<countries>
    <country>
        <name>Afghanistan</name>
        <code>AFG</code>
    </country>
    <country>
        <name>Albania</name>
        <code>ALB</code>
    </country>
    ...
    <country>
        <name>Zambia</name>
        <code>ZMB</code>
    </country>
    <country>
        <name>Zimbabwe</name>
        <code>ZWE</code>
    </country>
</countries>

Performing the mapping is as easy as loading the external file with the document function and then extract the appropriate value with an XPATH:

<xsl:value-of select="document($countryList)/countries/country[code=$country]/name"/>

Full template is here.

Local mapping variable

Sometimes it may not be desirable to have an external mapping file, so an embedded variable with the relevant mappings could be included in the XSL itself.

This is the same data as in the external mapping file from above, only it’s now in a variable:

<xsl:variable name="countryList">
            <countries>
                <country>
                    <name>Afghanistan</name>
                    <code>AFG</code>
                </country>
                <country>
                    <name>Albania</name>
                    <code>ALB</code>
                </country>
                ...
                <country>
                    <name>Zambia</name>
                    <code>ZMB</code>
                </country>
                <country>
                    <name>Zimbabwe</name>
                    <code>ZWE</code>
                </country>
            </countries>
        </xsl:variable>

It’s not possible to simply call an XPATH on this variable due to a limitation in XSLT 1.0, it returns an all but unusable “fragmented nodeset” but with a widely supported extension it’s very easy.

Typcically I use the default XSLT Processor in Java (generally known as JAXP) which my take is it was a port of Xalan-J at some point. For JAXP, the extended functions are included so enabling the extended libraries is as easy as including the namespace in the opening tag of the XSL file:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:exsl="http://exslt.org/common" extension-element-prefixes="exsl">

With that enabled, we can then simply pass the countryList variable through the exsl:node-set() function to produce a useful node-set that can be XPATH’d.

<xsl:value-of select="exsl:node-set($countryList)/countries/country[code=$country]/name"/>

Full template is here.

Local string mapping variable

In a recent piece of work I did there was a constraint where it was not possible to have external resources, nor use extension functions, so both the previously discussed options were ruled out. What this left was good ole string manipulation, what I term “string bashing”. Essentially we simply include a string variable made up of key/value properties that we then substring to extract the relevant data as needed for the mapping.

I wrote a separate simple XSL to produce this key/value string, which we just include in our template:

<xsl:variable name="countryList">
            ;AFG=Afghanistan;ALB=Albania;DZA=Algeria;AND=Andorra;AGO=Angola;ATG=Antigua and Barbuda;ARG=Argentina;ARM=Armenia;AUS=Australia;AUT=Austria;AZE=Azerbaijan;BHS=Bahamas
            ...
        </xsl:variable>

Then with a compact but powerful call we can grab the desired value:

<xsl:value-of select="substring-before(substring-after($countryList, concat(';',$countryCode,'=')),';')"/>

The result of this is just the same as the first two mapping options discussed above, it just doesn’t have the simplicity of being able to use an XPATH.

Full template is here.

So there are three ways to do mapping with XSL, there are likely others, generally I prefer the first option with an external mapping file as that gives us the best option for re-use elsewhere, but that is not always possible.