Nobody REALLY Asked Me, But...
by John E. Simpson | Pages: 1, 2

An answer, Part 1

Related Reading XPath and XPointer Locating Content in XML Documents By John E. Simpson Read Online--Safari

I want to cover an answer to James's question in two parts. The first part attempts to address some of the limitations of last year's answer -- allowing for characters beyond the basic 52 Roman-alphabet characters. (As always when I present code fragments here, understand that whitespace such as newlines and indenting are included for presentation purposes only. If your own source documents are "prettied up" this way, be sure to strip out the extraneous whitespace before submitting them to the XSLT stylesheet solution below.)

As a reminder, at the heart of the earlier ROT-13 solution were a series of calls to the XPath translate() function. Each looked something like this:

   translate([string to encode],
     
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz",
     
"NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm")

What this does is process the input string (an element/attribute name, in last year's piece), replacing each occurrence of a character in the second argument with the corresponding character in the third: A with N, b with o, and so on.

There's no limit to the lengths of those second and third arguments. Thus, we can extend them to include, say, digits and punctuation marks, as in the following (additions in boldface, and please disregard the line breaks forced by this page's layout):

   translate([string to encode],
     
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz01234567890,./;[]\
~!@#$%^&*()+`-={}|"<>?',

     
'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm
56789012345*()+`-={}|"<>?,./;[]\
~!@#$%^&')

Some comments about this modification -- first, I haven't attempted to substitute digits for letters, or punctuation marks for either; this would almost certainly end up producing a non-well-formed result tree. For the same reason, in the portions of the second and third arguments which pertain to punctuation, I've used entity references (such as &) instead of markup-significant literal characters (such as &). (The apostrophe causes special problems in this case, by the way, because of its appearance in an attribute value; I've simply excluded it from both the "translate from" and "translate to" arguments.) I've omitted the underscore and colon from both the second and third arguments, because I don't want to foul up the well-formedness of the result tree in any document whose source tree includes those characters in element or attribute names. Finally, note that I've included a space as a "character" to be encoded (it appears before the tilde, ~, in the second and third arguments). This will help obscure the breaks between words in the source tree. (All spaces in the source tree will be replaced with right curly braces; conversely, all hyphens will be replaced with spaces.)

An answer, Part 2

Last year's question dealt only with encoding element and attribute names. James wants to encode content, too. Let's start by setting up a named template, which can be invoked for encoding both the markup names and the content (attribute values and text nodes). Keeping the translate() function in a named template like this eliminates the need to repeat that ungainly-looking function call every time we need it:

   <xsl:template name="rotencode">
      <xsl:param name="cleartext"/>
         <xsl:value-of select="translate($cleartext,
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz01234567890,./;[]\
~!@#$%^&amp;*()+`-={}|&quot;&lt;&gt;?','NOPQRSTUVWXYZABCDEFGHIJKLM
     nopqrstuvwxyzabcdefghijklm56789012345*()+`-={}|&quot;&lt;&gt;?,./;[]\
~!@#$%^&amp;')"/>
   </xsl:template>

This named template takes one parameter, called cleartext. Whenever a template in the stylesheet invokes the named template, it will pass by way of this parameter the string to be encoded.

For processing elements and their attributes, we now need one template rule. Note the three calls to the rotencode template rule (above) -- one for element names, one for attribute names, and one for attribute values:

   <xsl:template match="*">
      <!-- Assign a variable for the ROT-13 version of the
element's name -->
      <xsl:variable name="rot13_elem">
         <xsl:call-template name="rotencode">
            <xsl:with-param name="cleartext"
select="name()"/>
         </xsl:call-template></xsl:variable>
      <!-- Use the above calculated name as the NEW element's
name -->
      <xsl:element name="{$rot13_elem}">
         <!-- Process each attribute for this element...
-->
         <xsl:for-each select="@*">
            <!-- Set up another variable for the ROT-13
attribute name -->
            <xsl:variable name="rot13_attr">
               <xsl:call-template name="rotencode">
                  <xsl:with-param name="cleartext"
select="name()"/>
               </xsl:call-template>
            </xsl:variable>
            <!-- Create the attribute with the new name...
-->
            <xsl:attribute name="{$rot13_attr}">
               <!-- ...and encode its value, as well.
-->
               <xsl:call-template name="rotencode">
                  <xsl:with-param name="cleartext"
select="."/>
              
</xsl:call-template></xsl:attribute>
         </xsl:for-each>
         <!-- Process all children (elements and text) of the
element -->
         <xsl:apply-templates/>
      </xsl:element>
   </xsl:template>

We also need a whole new template rule for processing all text nodes. This overrides XSLT's default handling of such nodes, which is simply to copy them straight to the source tree, unchanged:

   <xsl:template match="text()">
      <xsl:call-template name="rotencode">
         <xsl:with-param name="cleartext"
select="."/>
      </xsl:call-template>
   </xsl:template>

When you apply this stylesheet to the sample "invoice" document, the XSLT processor produces a result tree which looks as follows:

   <vaibvpr vai_ahz="N755651635568">
      <phfgbzre_ahz>0283680</phfgbzre_ahz>
      <cnlzrag glcr="ivfn" pneq_ahz="6789012345"/>
      <vgrzf>
         <vgrz vgrz_ahz="543298">
            <dhnagvgl>6</dhnagvgl>
            <havg_cevpr
pheerapl="HFQ">67(40</havg_cevpr>
         </vgrz>
         <vgrz vgrz_ahz="876377">
            <dhnagvgl>9</dhnagvgl>
            <havg_cevpr
pheerapl="HFQ">340(40</havg_cevpr>
         </vgrz>
      </vgrzf>
   </vaibvpr>

A more document-like, less data-like document might be something like:

   <excerpt author="T.S. Eliot">I should have been
a pair of ragged claws</excerpt>

This translates, using the improved algorithm, to:

   <rkprecg
nhgube="G(F({Ryvbg">V{fubhyq{unir{orra{n{cnve{bs{enttrq{pynjf</rkprecg>

As I said in last August's column, this may be pretty effective at stopping a casual reader of the document. But naturally, it falls down as soon as the reader recognizes the document's ROT-13 nature, because she can fairly easily build a "de-ROT-13" routine to turn the document back into its cleartext form.

	Also in XML Q&A From English to Dutch? Trickledown Namespaces? From XML to SMIL From One String to Many Getting in Touch with XML Contacts

Incidentally, continuing to discuss all this as "ROT-13" encoding is a little misleading. That name derived from the fact that 26 letters could be rotated 13 places to produce a simply coded result. What we've now got rotates 52 letters (including lower- and uppercase variants), 10 digits, and 30 punctuation characters. Thus, this form of the encoding might better be referred to as something like ROT-46, or maybe ROT-26,5,15. If you're interested in pursuing this further on your own, you could rotate the characters an arbitrary number of places -- perhaps driven by a global parameter whose value is passed in from outside the stylesheet.

Next month, once again, it's back to the world of real questions faced by real readers. And thanks, as always, for keeping those questions coming.

---

---

2. Will not work on all XML...
   2002-08-30 01:28:30 Martin Rowlinson
4. Do NOT mistake this for security
   2002-08-29 18:11:16 Jason May