Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments From: Francis Norton <francis@xxxxxxxxxxx> Date: Mon, 26 Feb 2001 12:13:47 +0000 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [exsl] Draft 0.1 - call f, Jeni Tennison | Thread | Re: [xsl] [exsl] Draft 0.1 - call f, Jeni Tennison |
[xsl] Re: [exsl] Re: Draft 0.1 - ca, Dimitre Novatchev | Date | RE: [xsl] [exsl] Re: Draft 0.1 - ca, Kevin Jones |
Month |