[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: [exsl] Draft 0.1 - call for comments

Subject: Re: [exsl] Draft 0.1 - call for comments
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Thu, 1 Mar 2001 10:19:40 +0000
Re:  [exsl] Draft 0.1 - call for comments
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.