This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] Draft 0.1 - call for comments
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