This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Implementing XPointer Resolution With saxon:evaluate()
Hi Eliot,
> Now I have my indirection function working as intended.
Cool :)
> One thing I have a question about is how to generate an empty node
> list. I am currently doing this:
>
> <func:result select="fcommon:node-set()"/>
The standard way to generate an empty node set is:
<func:result select="/.." />
This gives you the parent of the root node, but the root node hasn't
got a parent, so you get an empty node set. You can have fun
(depending on your definition of the word) thinking up other paths
with guaranteed-empty results, such as:
/@*
or:
@*/*
or:
*[1][2]
and so on...
> Which works using Saxon's built-in implementation of node-set(), but
> I didn't see anything in the definition of node-set() on the EXSLT
> site that unambiguously justifies this behavior in that it doesn't
> say what the behavior is when the object parameter is omitted. Given
> that an empty result returns a null string, I could easily see
> implementors making ommitted objects result in a node set consisting
> of a single text node representing an empty string. Am I being too
> paranoid or is node-set() underspecified on the EXSLT docs?
I guess it is implicit on the site, but I was intending that when you
have a function signature like:
exsl:node-set(object)
it means that the argument is required and that it's an error if it's
missing. If it were:
exsl:node-set(object?)
then the argument would be optional and we'd have to say what happens
when you don't provide it, but it ain't, so I don't think we do.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list