johkar <nosendjunk@m...> writes:

> To me, the inner translate function below would find any instance of
> square brackets with a single space separating them and replace it
> with a single underscore but that doesn't seem to be what is
> happening.  Do the square brackets have some sort of
> significance...like a regular expression?  I didn't think so since
> they were quoted.  I think the original developer's intent was to
> replace spaces with underscores so that the element name syntax would
> be valid XML.

The second argument to translate() is interpreted as a set of
characters, not as an expression.  The first argument is scanned
character by character, and each character is tested to see if it
appears anywhere in the second argument.  If it does not appear in the
second argument, it's copied to the output string without change.  If
it does appear in the second argument at position N, then it's
replaced in the output by the character at position N of the third
argument.  If the third argument is less than N characters long, 
the character is omitted from the output.

This behavior will be familiar to some people from analogous 
functions and operations in Snobol, Spitbol, Rexx, and
IBM 360 assembler, as well as (I think) some other languages.

> However if the XML contains:
>
> <rate>FCTR[   ]2</rate>   it transforms into  <FCTR2>0.04200</FCTR2>
> without any underscore at all.
>
> <xsl:variable name="tag" select="translate(translate(rateCode/text
> (),'[ ]','_'),'.','__')"/>
> <xsl:element name="{$tag}">
>    <xsl:value-of select="rateTag/text()"/>
> </xsl:element>
>
> Any insight into this would be appreciated.

The inner call, to 

    translate(rateCode/text(),'[ ]','_')

should translate left square bracket to underscore and omit any
blanks or right square brackets.  In your example, the element is
named rate, not rateCode, which means we cannot tell what the 
first argument of the inner call to translate() is.  If the
XML actually contains <rateCode>FCTR[   ]2</rateCode>, then I 
would expect the call to produce "FCTR_2".  The outer call is then

    translate("FCTR_2",'.','__')

and since no full stops appear in the first argument, the result
would be FCTR_2.  This is what you say you expected, but the 
reasoning is rather different.

If there is a rateCode element in the vicinity, then the result
will depend on its content.

Are you sure you transcribed both the input and the XSLT 
correctly here?

hth

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************