You might have run into this scenario if you work with XML files that contain sensitive data: You run into a problem, perhaps a bug, with your favorite XML processing tool. You need to send the vendor an example of a file that triggers the bug. You can't just send random XML files because you presume it's the special makeup of your sample files that is causing the problem. You need a way to cleanse the files of sensitive data, while you retain the specific structural characteristics of the file so it still serves as a good example of the problem. You can do so with a few XSLT tricks, and this article shows how.

Eliminating content

Listing 1 (kill-content.xslt) is an XSLT script that eliminates all text nodes and attribute values, leaving essentially a skeleton of the node structure.

                <?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>

  <xsl:template match="node()">
    <xsl:copy>
      <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@*">
    <xsl:attribute namespace="{namespace-uri()}" name="{name()}"/>
  </xsl:template>

  <xsl:template match="text()"/>

</xsl:stylesheet>

As with many useful scripts this builds on the identity transform, as you can see from the first template. The second template copies all attributes to the output, except that it ignores the attribute value. The third template suppresses all text nodes. All other node types, including elements, are handled by the first template, which copies their basic structure to the output. Listing 2 is an example of a file to be processed.

                <?xml version="1.0" encoding="iso-8859-1"?>
<patients>
  <patient id='ep' admitted="2003-06-10">
    <name>Ezra Pound</name>
    <address>
      <street>45 Usura Place</street>
      <city>Hailey</city>
      <province>ID</province>
    </address>
    <condition>ore infectus</condition>
  </patient>
  <patient id='tse' admitted="2003-06-20">
    <name>Thomas Eliot</name>
    <address>
      <street>3 Prufrock Lane</street>
      <city>Stamford</city>
      <province>CT</province>
    </address>
    <condition>Sartor resartus</condition>
  </patient>
  <patient id="co" admitted="2004-11-15">
    <name>Christopher Okigbo</name>
    <address>
      <street>7 Heaven's Gate</street>
      <city>Idoto</city>
      <province>Anambra</province>
    </address>
    <condition>caeli porta quaerit</condition>
  </patient>
</patients>

When you apply the XSLT script from Listing 1 to the XML sample in Listing 2, you get XML along the lines of the following (ignoring the XML declaration).

<patients><patient id="" admitted=""><name/><address><street/><city/>...

You can see how the basic element and attribute structure remains, but devoid of content.

Shooting blanks

If complete removal of the character data is too extreme and you want to preserve at least the length of each node, a variation on Listing 1 might be useful. The XSLT script in Listing 3 replaces all character data with a node of the same length comprising only spaces.

                <?xml version="1.0" encoding="utf-8"?>
<xsl:transform version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:x="http://ns.ogbuji.net/articles"
>

  <x:wsbuffer xml:space="preserve">                        </x:wsbuffer>
  <xsl:variable name="wsbuf" select="string(document('')/*/x:wsbuffer)"/>

  <xsl:template match="node()">
    <xsl:copy>
      <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@*">
    <xsl:attribute namespace="{namespace-uri()}" name="{name()}">
      <xsl:value-of select="translate(., ., $wsbuf)"/>
    </xsl:attribute>
  </xsl:template>

  <xsl:template match="text()">
    <xsl:value-of select="translate(., ., $wsbuf)"/>
  </xsl:template>

</xsl:transform>

The key bit is the top-level extension element x:wsbuffer which provides a stock of blank character content to be used in the replacement operation. I kept the run of spaces short, for formatting reasons, but you might want to add many more blanks to the element because all character data nodes in the original data are replaced by an equivalent length of spaces up to a maximum which is the number of characters in x:wsbuffer. The xml:space attribute is to prevent XSLT processors from stripping the whitespace within x:wsbuffer. You can actually use any contents for x:wsbuffer and it will be used as the stock replacement text for character data. If you do use any non-whitespace characters for this purpose, you don't need the xml:space attribute.

The variable wsbuf is set up with the replacement text by introspection into the XSLT document (using the special meaning of document('')). The rest of the transform is similar to Listing 1, except that rather than suppress content, it replaces each character with the one of equivalent position from wsbuf. As it stands in Listing 1, the result is that all output content is blank. You can experiment with the contents of x:wsbuffer if you want to alter the output.

When you apply the XSLT script in Listing 3 to the XML in Listing 2, you get XML along the lines of the following.

<patients>   <patient id="  " admitted="          ">     <name>          </name>...

Back to top

Wrap up

In this article, you learned how to modify XML documents so the basic structure stays the same, but you eliminate or modify the content so sensitive information is not leaked. The techniques presented do have some limitations, mostly due to the limitations in XSLT itself. Most notably, if part of the problem situation you try to communicate involves the nature of character data itself (for example, a bug handling character entities) you lose the key information if you use variations of the samples shown here. Remember that XSLT also loses some information in XML files, such as the top declarations, entity references and CDATA sections. If these are key to the problem in question you will not be able to use XSLT to cleanse the files. I have seen many cases where these scripts are quite sufficient, so these are techniques well worth learning. You can control character data even more closely if you're willing to use EXSLT extensions (See resources).

Resources

Learn

• Unfamiliar with XSLT? Dig into these tutorials and article from developerWorks:
  • "Get started with XPath," by Bertrand Portier (May 2004)
  • "Investigating XSLT: The XML transformation language," by LindaMay Patterson (August 2001)
  • "Create multi-purpose Web content with XSLT," by Nicholas Chase (March 2003)
  
  
• EXSLT: Learn about a library of useful and widely supported extension functions for XSLT. EXSLT has some facilities that make managing lookup tables easier. A good place to start is "EXSLT by example" (developerWorks, February 2003).
  
  
• developerWorks XML zone: Find more XML resources here, including articles, tutorials, tips, and standards. For a complete list of XML tips to date, check out the tips summary page.
  
  
• IBM Certified Solution Developer -- XML and related technologies: Learn how to get certified.
  
  

Get products and technologies

• 4XSLT, part of 4Suite: Experiment with the code samples and the stylesheet processor (which the author co-develops) used to test the examples.
  
  

About the author

Uche Ogbuji is a consultant and co-founder of Fourthought Inc., a software vendor and consultancy specializing in XML solutions for enterprise knowledge management. Fourthought develops 4Suite, an open source platform for XML, RDF, and knowledge-management applications. Mr. Ogbuji is also a lead developer of the Versa RDF query language. He is a computer engineer and writer born in Nigeria, living and working in Boulder, Colorado, USA. You can find more about Mr. Ogbuji at his Weblog Copia or contact him at uche@ogbuji.net.

Rate this article

Comments

Back to top

Table of contents

• Eliminating content
• Shooting blanks
• Wrap up
• Resources
• About the author
• Comments