Re: [xsl] Implementing XPointer Resolution With saxon:evaluate()

Subject: Re: [xsl] Implementing XPointer Resolution With saxon:evaluate()
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Wed, 14 Aug 2002 15:55:49 +0100
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


Current Thread