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, where it would be a prefixed
function, and can be implemented in a way that satisfies the design

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


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.


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
> 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
> the function can dynamically decide the return type based on the value

> of the first parameter and the types of the second and third
> A) This is consistent with XPath 2.0, which is forward looking
> B) A run-time optimization can still be achieved when the author
> 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
> 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
> and XForms 2.x/XPath 2.0 development will be much more far reaching
> 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
> 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
> increased authoring flexibility in this case because the authoring 
> flexibility does not apply to very many real cases within the XPath
> 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
> 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
> 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:  
> Blog:

Orbeon Forms - Web Forms for the Enterprise Done the Right Way

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