Re: [xsl] Transitive closure for XPath

[Jeni Tennison <mail@xxxxxxxxxxxxxxxx>]

Hi Christian,

>> Cute. Presumably as well as
>> closure(/closure/node[1], id(@child))
>> you could have
>> closure(/closure/node[1], key("myKey", @child))
>> You need delayed evaluation of parameters. Is this straightforward in
>> other XSLT engines?
>
> That's the one thing that is a bit worrying, the repeated and
> delayed evaluation of the same parameter. It was straightfoward
> enough in Xalan (although I had to override the default method,
> which evaluates the parameters before passing them to the function).
> I have not even attempted to understand the implications of this for
> optimised queries.
>
> I am not an expert in XPath details, so I wonder how feasible it
> would be to disguise this as an axis:
> /*/node[1]/closure::id(./@child) ? A function is definitely much
> easier to implement though.

I'm fairly sure that it's pretty hard-wired into XPath that you always
evaluate the arguments of a function, and pass to the function the
result of that evaluation.

If you consider the model of things like saxon:evaluate() or other
functions that involve the dynamic evaluation of an XPath, you should
either pass in the XPath-to-be-dynamically-evaluated as a new special
type (like saxon:expression()) or, possibly, as a string.

So if you want to stick to the way that XPath currently works, then
perhaps you should define closure() as:

  node-set closure(node-set, string)

which would make the above examples:

  closure(/closure/node[1], 'id(@child)')
  closure(/closure/node[1], 'key("myKey", @child)')

It would be up to the application to interpret the second argument
string as an XPath, in the context of each of the nodes that's
traversed.

Just a couple of other things - on the page explaining closure(), you
say that you *need* to get this list of 'descendants' within an XPath,
but don't say why. It would be good to see the XSLT context in which
you're using it.

And the other thing is that if you'd like to submit this as a function
to EXSLT, that would be great - you don't indicate what namespace
you're using at the moment, but we've been intending to add a 'EXSLT -
Dynamic' module, and this would be a good function to have within it,
or perhaps in a different module if you think there's a better fit.
If you don't know about EXSLT, have a look at http://www.exslt.org/.

Cheers,

Jeni

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



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