Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Thu, 1 Mar 2001 10:19:40 +0000 |
Hi Uche, > 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. I don't think that there's been a strong argument for exsl:return either, and I don't think anyone's positively objected to exsl:result, so I'll change it in the next version and see if anyone objects. > "Issue: RTF error - should generating result nodes be an > unrecoverable error? " > > I like it as you have it now: error or ignore the nodes. What do you think about David C.'s suggestion of having RTFs returned unless there's an exsl:result element in amongst the nodes that are generated, in which case the select attribute of the first exsl:result element is used as the return value? > "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. Just to note that I wondered whether those involved in the Oasis conformance initiative would have any opinion on whether it's a sin to introduce new recoverable errors given that it's so hard to judge conformance with just the ones that are in the XSLT Rec. already. > "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. Yes, I've been convinced as well. > "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. But then in a later email it sounded as if you agreed to: >> Something like: >> >> Function: string exsl:object-type(object) >> >> The exsl:object-type function returns a string giving the type of the >> object passed as the argument. The possible object types are: >> 'string', 'number', 'boolean', 'node-set' or 'RTF'. >> >> [Note: The description would change in version 1.1 (matching XSLT 1.1) >> to: >> >> The exsl:object-type function returns a string giving the type of the >> object passed as the argument. The possible object types are: >> 'string', 'number', 'boolean', 'node-set' or 'external'.] > > I find this much more compelling than a built-in system of > typeconstraints. Have I interpreted you correctly? You wouldn't object to an exsl:object-type function? Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ 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, Uche Ogbuji | Thread | Re: [xsl] [exsl] Draft 0.1 - call f, Uche Ogbuji |
Re: [xsl] XPath for all of an eleme, Jeni Tennison | Date | Re: [xsl] XPath for all of an eleme, Francis Norton |
Month |