Re: [xsl] analyze-string gotcha/reminder

[Ihe Onwuka <ihe.onwuka@xxxxxxxxx>]

On Tue, Nov 20, 2012 at 1:35 PM, John Lumley <John.Lumley@xxxxxxxxxxxxxx> wrote:
> On 18/11/2012 18:42, Andrew Welch wrote:
>>
>> 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>
>
> A useful technique I've found with a multi-case xsl:analyze-string is to use
> a set of variables for each of the regex alternatives and then join them for
> a composite alternative expression, viz:
>
> <xsl:variable name="r1">\d+</xsl:variable>
> <xsl:variable name="r2">[A-Za-z]+</xsl:variable>
> ....
> <xsl:analyse-string select="." regex="{string-join(($r1,$r2),'|')}">
>   <xsl:matching-substring>
>     <xsl:choose>
>       <xsl:when test="matches(.,$r1)">It's a number</xsl:when>
>       <xsl:when test="matches(.,$r2)">A word this time....</xsl:when>
> .......
> This has three advantages:
> i) you only define each case once,
> ii) dealing with entities such as quotes is much easier and
> iii) it's much clearer what the alternatives are.
>
> The only minor niggle is with embedded bracketed substructures '(...)' where
> the numbering to access them, regex-group(n), depends upon the position in
> the composite sequence.
>

hmmm but if the Gods had meant us to do this would they have invented flag="x"?