Re: [xsl] [exsl] Draft 0.1 - call for comments

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