I gather that XSLT 2.0 will support regular expression matching and thus you
will be able to duplicate the PPL function you described.
--
Charles Knell
cknell(_at_)onebox(_dot_)com - email
-----Original Message-----
From: Peter Flynn <peter(_at_)silmaril(_dot_)ie>
Sent: 04 May 2003 12:16:23 +0100
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Comparing comma seperated string in XSLT
On Sun, 2003-05-04 at 01:41, Girish Savadatti wrote:
Hello,
I am passing a parameter to XSLT which is comma
seperated value. e.g. depts = 1,2,3,4,5
XML source is
<metaData>
<docTitle>FooBar News</docTitle>
<url>FooBar.html</url>
<departments>22,2,23,236</departments>
</metaData>
Here any one deparment from depts string matches in
departments element then I want to to display this
News on the page.
i.e. use string tokenizer on depts string get one
department and then do contains on <departments>
Is it possible to do using XSLT?
Mike Brown has posted useful links for this on using substring-before
and substring-after with recursion.
Whenever I see a question of this type, I am reminded of the function
in PPL (the 4GL inside the P-Stat package)
[IF ANY (expr1) IN (expr2), action...]
where <exprn> could be anything from a couple of variable names to an
arbitrarily complex expression containing -- in this case -- string-
split operations. This provides a feature of rather high productivity
as it replaces a quite large amount of user code each time, although
the implicit nested loop is linearly expensive for large numbers of
values generated by the expressions.
Is there a policy for XSLT >1.1 on what level of function-bloat
people are likely to tolerate? I'm not suggesting this particular one
should be included, but I'm interested to know what people feel is
a good way to measure what should go in and what should not.
///Peter
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list