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

[Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>]

Hi Marc,

>> > instance). It would be handy if the regular expressions could be held
>> > in (global) variables because then they could be defined in content
>> > (with CDATA sections) rather than in an attribute. However, that would
>> > run up against the dynamic regular expression problem that David and I
>> > talked about yesterday. I don't think it'll be too big a problem,
>> > though - the regular expressions in XSLT are likely to be a lot
>> > smaller than these, and not include tags (hopefully!).
>
> could you clarify on this 'dynamic regular expression' some?

Sure. Say you have a bunch of news stories, each with a description,
and you want to provide a stylesheet that enables the user to search
these news stories and returns those that contain some keyword. The
keyword would be a global parameter.

In XSLT you could do:

  story[contains(description, $keyword)]

and you'd get all the story elements that contain the $keyword in
their description.

Now imagine you want to do this with regular expressions, so that you
could check that the keyword was a whole word rather than just a part
of a word. If the keyword was "bus" then you'd want a regular
expression that was something like:

  \Wbus\W

The regular expression needs to be constructed dynamically, based on
the value of the $keyword function, and you need something like:

  story[test-regexp(description, concat('\W', $keyword, '\W'))]

I think this is a big requirement for regular expression use in XSLT.
There are a couple of ways of handling this:

You could have functions like the above, but David doesn't think this
is particularly useful if you're going to actually do something with
the results of the match, and I agree with him.

You could have an 'match' instruction that used an attribute value
template, something like:

  <xsl:for-each-match select="description" regexp="\W{$keyword}\W">
    ...
  </xsl:for-each-match>

You could feasibly have top-level elements that worked in a similar
way, but they would only have access to global variables (which might
be an issue if the $keyword was actually constructed via some parsing
or something).

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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