Empty node-set matching, and object type testing (fwd)

-----Original Message-----
From: Mike Brown 
Sent: Wednesday, September 15, 1999 2:10 PM
To: 'James Clark'
Cc: 'xsl-editors@w3.org'
Subject: RE: empty string as empty node-set: why not?


>> 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:21:02 UTC