This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: The top 10 limitations of XSLT 1.0 (was RE: RE: Designs for XSLT functions)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: The top 10 limitations of XSLT 1.0 (was RE: [xsl] RE: Designs for XSLT functions)
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Wed, 21 Feb 2001 10:06:08 +0000
- Organization: Jeni Tennison Consulting Ltd
- References: <000201c09be9$7dd88140$923c3c3e@oemcomputer>
- Reply-To: xsl-list at lists dot mulberrytech dot com
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