Re: The top 10 limitations of XSLT 1.0 (was RE: [xsl] RE: Designs for XSLT functions)

Subject: Re: The top 10 limitations of XSLT 1.0 (was RE: [xsl] RE: Designs for XSLT functions)
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Wed, 21 Feb 2001 10:06:08 +0000
Mike Kay wrote:
> (a) is a new requirement. In my first implementation of evaluate() I
> didn't allow variables, and they aren't strictly required, because
> you can substitute their values into the expression string instead,
> using concat(). I allow them because I was keeping variable names
> around at run-time anyway, e.g. for diagnostics. In defining a W3C
> spec for evaluate(), I would expect that to be a matter for debate.
> One option would be an SQL-like solution:
>
> evaluate("item[@code = '$1' and @desc = '$2']", $code, $desc)

If variables *aren't* allowed in evaluate(), then there's a real
requirement for some way of escaping quotes in XPaths.  If I have the
XPath:

  substring-before("Paul's...", "'")

Then to evaluate it I need to have:

  evaluate('substring-before("Paul's...", "'")')

which isn't valid.  Instead I need to pack the strings off into
variables and then do:

  evaluate('substring-before($string, $apos)')

or, as Mike suggests:

  evaluate('substring-before($1, $2)', "Paul's...", "'")

...unless there was a way to escape them with something like:

  evaluate('substring-before("Paul\'s...", "\'")')

Cheers,

Jeni

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



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


Current Thread