This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Transitive closure for XPath
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: Re: [xsl] Transitive closure for XPath
- From: "Christian Nentwich" <c dot nentwich at cs dot ucl dot ac dot uk>
- Date: Thu, 19 Apr 2001 22:09:39 +0100
- Organization: University College London
- References: <3ADEFCFC.93E83537@cs.ucl.ac.uk> <3ADF217E.66DA3772@redrice.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
> 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.
> (Of course I'd like to rename it to expand-o-graph() since that's how I
> visualise its operation)
Yes, or bounded avalanche operator :)
Christian
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list