Re: [xsl] [exsl] Draft 0.1 - call for comments

[Jeni Tennison <mail at jenitennison dot com>]

Hi Francis,

Thanks for your comments.  Just to address those that I disagree
with... :)

> [Issue: exsl:reference-of] damn - I didn't follow this one either -
> is it not also possible to create node-sets?
>
> [Issue: Multiple exsl:return error] Why can't the values of multiple
> exsl:return elements simply be unioned together as a node set?

These are fairly similar, but not quite the same.  The first allows
you to gradually build up node sets within a variable value.  For
example:

  <xsl:variable name="first-five-alphabetical">
     <xsl:for-each select="$nodes">
        <xsl:sort />
        <xsl:if test="position() &gt;= 1 and position() &lt;= 5">
           <exsl:reference-of select="." />
        </xsl:if>
     </xsl:for-each>
  </xsl:variable>

That you could then return with:

  <exsl:return select="$first-five-alphabetical" />

The question David C. raised with regard to this is "if we need it
here, why haven't we needed it before?"  There are more declarative
ways of doing the above, including:

  <exsl:return select="$nodes[sort:position($nodes) &gt;= 1 and
                              sort:position($nodes) &lt;= 5]" />

Having multiple exsl:return values being unioned together is roughly
similar except that you don't have the intermediate variable:

  <xsl:for-each select="$nodes">
     <xsl:sort />
     <xsl:if test="position() &gt;= 1 and position() &lt;= 5">
        <exsl:return select="." />
     </xsl:if>
  </xsl:for-each>

One problem with this is that it may be confusing for people who are
used to 'return' actually returning from a function (perhaps a reason
for calling it exsl:result rather than exsl:return if this
functionality is permitted).

As before, there are other ways of doing the above, including
recursive ones, so it is not absolutely required.
  
> [Issue: exsl:node-set name] um, what's wrong with node-set()?
> Compatible with existing implementation - or so compatible it might
> be confusing?

Nothing's wrong with exsl:node-set().  Some implementations use
nodeset() or NodeSet() or various other things instead, that's all.

> [Issue: Type tests] well, if we're going to add any type
> functionality, having it in this read-only area,for XPath 1.0 data
> types only, would cause the least baggage. Is the string / node-set
> decidability problem sufficiently hard to work round to justify
> this?

I was thinking about things like the 'other document' functions at the
end of Appendix B.  The document() function's first argument can be a
string or a node set, but with the 'other document' functions it has
to be a node set to get the desired behaviour, and there's no way to
test whether the right type of argument has been passed or not, nor to
fail with a nice error message if it isn't.

So the work around is to restrict the types that are acceptable to the
function, which is fair enough, just might be a little confusing in
these kinds of functions.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list