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

[Francis Norton <francis@xxxxxxxxxxx>]

Hi Jeni,

Jeni Tennison wrote:
> 
> Hi Francis,
> 
> Thanks for your comments.  Just to address those that I disagree
> with... :)
> 
Delighted to see you picked up all the ones I didn't really care about
or didn't really understand ... :)

> > [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:
> 
OK, I think I understand now. If this is how exsl:reference-of is going
to be used, would it be more intuitive to call it exsl:add-node? Or
could it also be used in non-"add-node" ways?

I can live with or without both of these, though since I do a fair bit
of schema processing across documents, I can see advantages to
exsl:reference being executable in for-each elements rather than just
using Xpath patterns.

But multi-returns would fix it too.
> 
> 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).
> 
Yes - a nice distinction.

> 
> > [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.
> 
Ah, OK - not exactly a project-breaker, then! :)

> > [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.
> 
Looks like it's adding up to a pretty compelling case for a read-only
"xpathType()" function.

Francis.

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