[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Regular expression functions (Was: Re: comments on
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|