On Fri, Oct 24, 2003 at 09:57:18AM -0400, Saverio Perugini wrote:
On Fri, 24 Oct 2003, Daniel Veillard wrote:
haha, no libxslt implements only XSLT-1.0 + (most) EXSLT extensions
the name of the libxml2 library doesn't come from XPath2 or XSLT2 really :-)
The fact that it implements match="*[name()=$keyword]" is simply an
oversight,
it doesn't change anything to my implementation which "forgot" to check
that restriction, it's a bug actually, sorry if this led to some confusion
Are you stating that "*[name()=$keyword]" worked for me as the value of
a match attribute of xsl:template, using libxslt, quite literally "by
accident" (i.e., because the processor doesn't check this constraint)?
yes,
If so, are there any side effects which may manifest as bugs elsewhere
in the stylesheet by taking this terse approach? Do you recommend
abandoning this approach?
yes and yes.
If you want XSLT2 features use an XSLT2 processor (Saxon).
The problem is that code has not been tested because it is not
supposed to work. I don't know what are the restrictions applying
to the use of variables in template matche rules in XSLT2, what
libxslt is doing is that it probably looks for the current
in-scope value of that variable or parameter, this may or may
not be the XSLT2 semantic, I simply don't know, I didn't look at
that spec for implementation.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(_at_)veillard(_dot_)com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ |
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list