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

empty string as empty node-set: why not?

From: Mike Brown <mbrown@netignite.com>
Date: Fri, 20 Aug 1999 10:05:30 -0600
Message-ID: <8D96EDA0AC04D31197B400A0C96C148001CC5E@ossex1.ossinc.net>
To: "'xsl-editors@w3.org'" <xsl-editors@w3.org>
To whom it may concern,

Per section 11.2 of the XSLT draft, "If the variable-binding element has
empty content and does not have a select attribute, then the value of the
variable is an empty string."

So, if I were to do this:

	<xsl:call-template name="do_something">
		<!-- not passing a parameter "foo" -->
	</xsl:call-template>

	<xsl:template name="do_something">
	    <xsl:param name="foo"/>
	    <!-- I wish $foo were a node-set -->
	    <xsl:if test="$foo/SomeChildren">I see SomeChildren</xsl:if>
	</xsl:template>

...I would be committing a crime because $foo is a string at this point (an
empty string), not a node-set, and nothing can be converted to a node-set,
per section 3.3 of the XPath draft.

I can work around this a couple of ways:

1. A default value for the parameter can be fudged to be an empty
node-set...

	<xsl:param name="foo" select="/nonexistent/path"/>

This is ugly and /nonexistent/path could conceivably return a non-empty
node-set, unless one imposes a restriction on source trees to never contain
nodes that would match that pattern.

2. One can test for $foo to be true, which will not be the case if it is an
empty string.

	<xsl:if test="$foo">
		<xsl:if test="$foo/@SomeAttribute">
			<!-- do something here -->
		</xsl:if>
	</xsl:if>

Similarly, if the XSL processor is nice enough to not bother with the second
part of an 'and' expression when the first part is false, a shorter form can
be used:

	<xsl:if test="$foo and $foo/@SomeAttribute">
		<!-- do something here -->
	</xsl:if>

I think I can understand why one would avoid converting a non-empty string
to a node-set when evaluating an expression, but is there an argument
against conversion of an empty string to an empty node-set? (That is, using
the example above, under current thinking, $foo/@SomeAttribute is a valid
expression if $foo is an empty node-set, but not if $foo is an empty string.
Could an exception be made so that $foo will be treated as an empty node-set
in such a situation?)

Also, is there a reason why there is no obvious mechanism for testing
whether something is one of the five major data types?

Thanks,
Mike
Received on Friday, 20 August 1999 12:05:52 GMT

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