After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 334493 - --param does not have root context
--param does not have root context
Status: RESOLVED FIXED
Product: libxslt
Classification: Platform
Component: general
git master
Other Solaris
: Normal minor
: ---
Assigned To: kbuchcik
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2006-03-14 01:48 UTC by jdenny
Modified: 2006-08-10 09:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description jdenny 2006-03-14 01:48:49 UTC
I tried this on Solaris 10 with a libxslt CVS snapshot.  The most recent commit listed in the ChangeLog was Fri Mar 10 12:49:18 CET 2006.

Given this XML:

  <doc>Success</doc>

And this XSLT:

  <xsl:transform
    version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  >

  <xsl:param name="top-level" select="doc" />

  <xsl:template match="/">
    <xsl:value-of select="$top-level" />
  </xsl:template>

  </xsl:transform>

I expected these command lines to have the same `Success' output:

  xsltproc test.xsl test.xml
  xsltproc --param top-level /doc test.xsl test.xml
  xsltproc --param top-level doc test.xsl test.xml

However, the last one does not.

I found this thread, which seems to agree with my expectations:

  http://mail.gnome.org/archives/xslt/2001-June/msg00014.html
Comment 1 kbuchcik 2006-06-27 09:16:14 UTC
I think it is questionable that the processor allows an external
parameter to be treated as an XPath expression at all.

Normally, to convert a string to an expression you use the
EXSLT function dyn:evaluate():
http://www.exslt.org/dyn/functions/evaluate/index.html
Comment 2 jdenny 2006-06-27 17:08:58 UTC
(In reply to comment #1)
> I think it is questionable that the processor allows an external
> parameter to be treated as an XPath expression at all.

Are you saying that `--param' should be deprecated?
Comment 3 kbuchcik 2006-06-27 17:31:39 UTC
No, since it's too late to change such a behaviour in xsltproc.

This is only an observation of the semantics of "--param",
rather than a comment related to the actual issue here.
It's misleading to have an option with a straightforward
name like "--param", which does something rather orthogonal w.r.t the
XSLT 1.0 spec.
If I have this global parameter:
<xsl:param name="foo" select="/"/>
then the _value_ of this parameter would be the document node.
With the current "--param" mechanism, one does _not_ set the
_value_ of the parameter, but substitutes the value of the
@select attribute, which isn't something one would expect.
It would be interesting to know if any of the other XSLT
processors also supports such a mechanism - I wouldn't
be surprised if not.
Comment 4 kbuchcik 2006-06-27 17:32:54 UTC
Hmm, but if you mean "deprecated" in the sense of "it's there,
but better not use it", then yes.
Comment 5 kbuchcik 2006-06-29 14:03:08 UTC
However, I'm going to fix this.
In xsltNewTransformContext() the ctxt->xpathCtxt->node needs to
be set to the given document node.

Note that the XPath expressions provided with "--param" are also
not namespace aware, since there's no mechanism to register
namespaces for the expressions. A "--param /my:foo" will
result in an error, since the namespace prefix is not bound to
a namespace.

I think a safe way of using "--param" would be when the result
is not a node set; e.g. expressions like "1" (a number) or
"string-length('foo')" (a number) or "'my text'" (a string).
Comment 6 kbuchcik 2006-07-14 16:30:17 UTC
Hope this is fixed now in CVS HEAD. Please report if this works for
you, since I had not the time to test it.
Comment 7 kbuchcik 2006-08-10 09:44:35 UTC
OK, I tested this and it works now.