W3C home > Mailing lists > Public > xsl-editors@w3.org > July to September 1999

RE: empty string as empty node-set: why not?

From: Mike Brown <mbrown@netignite.com>
Date: Wed, 15 Sep 1999 15:09:40 -0600
Message-ID: <8D96EDA0AC04D31197B400A0C96C148001CCD1@ossex1.ossinc.net>
To: "'James Clark'" <jjc@jclark.com>
Cc: "'xsl-editors@w3.org'" <xsl-editors@w3.org>
>> 1. A default value for the parameter can be fudged to be an empty
>> node-set...
>> 
>>         <xsl:param name="foo" select="/nonexistent/path"/>
>> 
>
>This was discussed at an XSL WG meeting, and it was pointed out that
>
>  select="/.."
>
>is a simple way to get a node-set that is guaranteed to be empty.  We
>felt this was enough for XSLT v1.

Thank you for taking the time to consider this issue.

If I may humbly point something out, the XPath 1.0 Working Draft of Aug 13,
1999 does not appear to clarify how empty node-sets are handled, and the
reader is left to deduce that it's not an error to produce a location path
that selects nodes "outside" the tree.

Perhaps it could be added to the description of a location path that if any
part of a location path fails to match any nodes, that it is not an error
and the path simply matches an empty node-set. To deliberately match an
empty node-set, the location path /.. or from-parent::/ should be used.

Or perhaps "empty node-set" could be defined in terms of how it may be
produced.


Anyway, I also conveyed that the disallowed conversion of any other object
to a node-set would be less problematic if one had a function that would
test or determine an object's data type. I'm suggesting a simple
IsBoolean(), IsNodeSet(), IsNumber() kind of thing. 

Perhaps all of my comments should have been directed at
www-xpath-comments@w3.org before 2 September 1999. Ah, well. Thanks again
for the "/.." tip.
Received on Wednesday, 15 September 1999 17:09:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:49 GMT