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 Thursday, 2 August 2007 16:01:45 UTC