RE: Regular expression functions (Was: Re: [xsl] comments on December F&O draft)

["Hunsberger, Peter" <Peter dot Hunsberger at stjude dot org>]

> There are a couple of issues that would need to be worked out with it,
> though. What happens if you have a regular expression that involved
> two instances of the named subexpression at the same level:
> 
>   <matcher name="two-numbers" regexp=":fancy-number:\w:fancy-number:">
>     ...
>   </matcher>
> 
> You need to have separate indexes to indicate which one you're talking
> about, plus some kind of syntax to pull out submatches within the
> named subexpression. Borrowing from XPath syntax (which might be a bad
> idea), you might have:
>
>   fancy-number[2]/*[2]
> 
> to indicate the second subexpression of the second fancy-number
> subexpression in the matched string.
> 
> Actually, that syntax isn't all that bad - you can imagine the matcher
> actually builds up a tree structure based on the subexpression
> matches (you need 'anonymous' elements for unnamed subexpressions, but
> you should be able to get away with that using elements in some
> restricted namespace or something)...

If a "matcher" explicitly returns a tree structure you could view it as
sending the results to the output document.  Thus, wrapping it in a variable
would allow you to manipulate the results in a natural  (XSL at least) way:

	<xsl:variable name="gunk">
	  	<xsl:apply-templates
select-regexp=":fancy-number:\w:fancy-number:" />
	</xsl:variable>
	<xsl:value-of select="$gunk[2]/*[2]"/>

(The template might actually be doing a "match-regexp", but to keep things
concise let's pretend the example is complete :-).

This seems to minimize the need to invent new stuff? Adding a similar form
of regexp qualifier/attribute to copy and copy-of would seem to handle all
general cases, no?

Peter Hunsberger


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list