RE: Reaching a conclusion about choose()

Maybe we shouldn't be doing choose at all then, and instead focus on
XPath 2.0 for XForms 1.2.
We can leave choose to exforms.org, where it would be a prefixed
function, and can be implemented in a way that satisfies the design
constraints.
Leigh. 

-----Original Message-----
From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
On Behalf Of Erik Bruchez
Sent: Thursday, August 02, 2007 9:02 AM
To: Forms WG (new)
Subject: Re: Reaching a conclusion about choose()


All,

I forwarded today Mike Kay's thoughts on this matter to the list. At 
this point I have to say that his response does not encourage me to 
support a decision in favor of doing the conversion.

-Erik

John Boyer wrote:
> 
> Hi all,
> 
> On the telecon today, we hada  good airing of the technical issues 
> regarding whether or not to remove text from the description of the 
> choose() function which says that it rationalizes the return type
based 
> on the types of the second and third arguments.  To review, here were 
> the two possible outcomes (i.e. proposed resoltuions):
> 
> 1) Keep the type conversion content in choose(), which is good because

> then it the function is statically typed at compile time.  
> 
> A) This is consistent with XPath 1.0, upon which XForms 1.1 is based,
> B) The static typing allows a run-time optimization
> C) The static typing simplifies design experience
> 
> 2) Remove the type conversion content in choose(), which is good
because 
> the function can dynamically decide the return type based on the value

> of the first parameter and the types of the second and third
parameters.
> 
> A) This is consistent with XPath 2.0, which is forward looking
> B) A run-time optimization can still be achieved when the author
coerces 
> the types to be the same
> C) The dynamic typing increases authoring flexibility when the return 
> value of choose is passed as a parameter to a function that accepts 
> object as a parameter.
> 
> For part A, proposed resolution #1 above is more appropriate for
XForms 
> 1.1 because being inconsistent with the technology on which you are 
> based trumps being inconsistent with a technology upon which a future 
> version of the language (which will even be in another namespace, will

> be based).  The inconsistencies between XForms 1.x/XPath 1.0
development 
> and XForms 2.x/XPath 2.0 development will be much more far reaching
than 
> a minor difference in how the choose() function operates in the major 
> revision of the language.
> 
> For part B, it's not clear that the optimization makes a huge
difference 
> in most forms, so it does not seem to matter much whether one gets it 
> automatically (#1) or when the author coerces the types (#2).
> 
> For part C, the simplified design experience is more important than
the 
> increased authoring flexibility in this case because the authoring 
> flexibility does not apply to very many real cases within the XPath
1.0 
> and XForms 1.x function set.  The only functions we have that take 
> objects as parameters are choose() and id(), so it seems like very 
> special cases indeed that could benefit from the authoring
flexibility.
> 
> Given all of the above, the next step really is to ask Erik if he can 
> "live with" the decision to retain the type rationalization text in
the 
> choose function specification.  A communication of not being able to 
> live with it should of course take the form of presenting some kind of

> sample form that that does not seem highly contrived or "very special"

> use case as this is what would cause some of those with the expressed 
> opinions to change their minds...
> 
> Let's get this discussed on the mailing list please as a Erik's LC 
> comment on this issue should be coming up for discussion soon.
> 
> Thanks,
> John M. Boyer, Ph.D.
> STSM: Lotus Forms Architect and Researcher
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com  
> 
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> 


-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Tuesday, 7 August 2007 18:56:15 UTC