Re: [xsl] analyze-string gotcha/reminder

[Ihe Onwuka <ihe.onwuka@xxxxxxxxx>]

On Sun, Nov 18, 2012 at 6:42 PM, Andrew Welch <andrew.j.welch@xxxxxxxxx> wrote:
>> So I had to double up my curly braces.
>
> Yep, or the usual way is to put the regex in the content of a variable
> with as="xs:string":
>
> <xsl:variable name="regex" as="xs:string"> no need to worry about
> anything here </xsl:variable>
>

I've come to the view that this is just problem displacement

This just gave me another WTF moment

	       <xsl:if test="matches($line,$regex)">
                 <spanning>
    		   <xsl:analyze-string select="$line" regex="$regex">
                     <xsl:matching-substring>		
       		       <period><xsl:value-of
select="regex-group(2)"/></period>
                     </xsl:matching-substring>
                   </xsl:analyze-string>
                 </spanning>
               </xsl:if> 		

I was getting empty <spanning/> elements in the output, when the
intent of the <xsl:if> was to prevent that. I was using a variable in
preference to repeating the regex in matches and analyze-string.

So when that happens is the first thing that leaps to mind that you
need to enclose the $regex in analyze-string in curly braces?. I'm
saying this because my brain assumes a natural symmetry between the
the two statements which led to that mistake. Yes I know they are
different languages - one is XPath and one XSLT but they are commonly
used together.

So a policy of always putting the regex in a variable means you have
to remember to put curly braces around it in  analyze-string ALL the
time, including when you've just used the variable in an immediately
preceding  expression where you didn't have to do that.

The same presumption of symmetry led me to write

	       <xsl:variable name="regex" as="xs:string" select="'(\D|^)
	
               (\d{4})
		              		
(\D|$)'"/>
	       <xsl:if test="matches($line,$regex,flags='x')">
                 <spanning>
    		   <xsl:analyze-string select="$line" regex="{$regex}" flags="x"

which is of course wrong.

Further woebetide you if you ever reuse $regex in a less proximate
location to its definition and forget to put in the flags option.