Reaching a conclusion about choose()

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