Re: [exsl] Draft 0.1 - call for comments
Thanks so much for the brilliant work, Jeni. An excellent document. Here are my few comments. "Issue: Namespace - what namespace should be used for these extension elements/functions? Possibility: http://xmlns.opentechnology.org/xslt-extensions/common" I'll set up a RDDL page for this namespace this week. "<exsl:function name = QName> <!-- Content: (xsl:param*, (xsl:variable | xsl:if | xsl:choose | xsl:message)*, (exsl:return, xsl:fallback?)? --> </exsl:function>" Looks as if "exsl:return" beat out "exsl:result". Yuck. Oh well, maybe I can come up with a brilliant argument to sway the electorate. "Issue: RTF error - should generating result nodes be an unrecoverable error? " I like it as you have it now: error or ignore the nodes. "Issue: xsl:for-each - should xsl:for-each be allowed within exsl:function outside variable-binding elements? It would ease the return of node sets created (a) from other documents or (b) involving sorting the node set in other than document order. This is achievable by building an RTF with IDs referring to the relevant nodes instead. " I think for-each should be allowed for the reasons you suggest. "Issue: Argument error - should trying to pass more arguments than there are xsl:param elements be considered an error? Should it be an unrecoverable error? " Yes, I think it should be an unrecoverable error. "Issue: exsl:return name - should exsl:return be called exsl:result instead?" No points for guessing what I think. "Issue: exsl:reference-of - should it be possible to return node sets by building them up gradually through an extension element such as exsl:reference-of? It would ease the return of multiple nodes from a function. This is achievable by building an RTF with IDs pointing to the relevant nodes instead." I've been watching the reference-of discussion with interest. There would be no problem implementing this for 4XSLT, but value vs reference semantics is such a variable matter between languages that I wonder whether it's impractical for some implementers. "Issue: Dynamic calls - should there be a way to dynamically determine the name of the function being called?" Using separate arguments Steve and Andrew have convinced me that we should defer this feature. "Issue: Type tests - should this specification define functions to test the type of values passed as parameters? Several XPath functions allow an argument to be either a string or a node set, but treating a string as a node set will cause an error and there's no way to detect whether a variable value is actually a string or a node set." Oh boy. Pet peeve of mine. I don't think there should be type tests. I'm of the strong opinion that it is a mistake that so many languages provide special status to data type among factors in program correctness. As for the reference function implementations, great stuff. -- Uche Ogbuji Principal Consultant uche.ogbuji@xxxxxxxxxxxxxxx +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python 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