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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format