Reverting to nodeset version of choose(), was Re: Reaching a conclusion about choose()

Hi Erik,

Much of Michael Kay's response characterizes what the WG is doing as 
"departing from XPath 1.0" and "unilaterally extending the XPath language 
[in an unintended way]".  I respectfully disagree with this assessment. 
Applications of XPath 1.0 are allowed to add functions, and those 
functions can do anything they like with their parameters, including 
treating them *in the same way* that XPath 1.0 operators treat their 
parameters.  Frankly, operators are generally regarded in language theory 
as syntax sugar for two-parameter functions, so it is quite mystifying 
that there might be such a reaction to an actual function behaving the way 
the operators of the language do.

Avoiding characterizations, I think it is more useful to focus on 
technical examples such as the one that Michael raised.  Frankly, it is an 
instance of the issue we discussed on the telecon, but it is useful to see 
it written down as it reifies the subtlety of difference that the type 
rationalization makes. 

As you know the current XForms application of XPath 1.0 does not offer 
variable bindings, so I adjusted Michael's example to fit with XForms. 
Here is the XPath expression under consideration:

XPath Expression: e[f/@x = choose(@x, @x, 0)]

If we eliminate the type rationalization, then this selects the elements e 
that meet one of two criteria:

1) e has attribute x and has any child f with an attribute x whose *string
* value matches e/@x
2) e has no attribute x and has a child f with an attribute x whose *
numeric* value is 0

If we keep the type rationalization, then the above XPath Expression 
selects the elements e that meet one of two criteria:

1) e has attribute x and has any child f with an attribute x whose *
numeric* value matches e/@x
2) e has no attribute x and has a child f with an attribute x whose *
numeric* value is "0"

Michael points out that the latter approach is problematic on point 1 
because the predicate will only return true (i.e. select nodes e) if e/@x 
is numeric.  The screw case he identified occurs when "f" is substituted 
by an expressions that includes the context node e.  In this case we would 
have

expr/@x = choose(@x, @x, 0)

The left hand side, expr/@x, would include e/@x but the result of the 
equality comparison with the result of choose() would be false even though 
choose is logically returning e/@x.  This is because both are being 
converted to a number, and if e/@x does not contain a number, then you end 
up asking for the result of NaN = NaN.  In its wisdom, the IEEE apparently 
decided that NaN isn't equal to anything, not even itself. 

The counter to this screw case is to simply point out that the form author 
clearly intends for the attributes in question to be treated as numbers, 
and the type rationalization consistently treats the nodes as numbers.  It 
seems slightly more appropriate to me that the XPath should not be 
selecting nodes when the content used to select the nodes is in error, but 
frankly it also seems as though it does not really matter since the 
end-user will likely have schema validation errors to deal with anyway, 
which seemingly makes academic the discussion about which nodes are 
selected.

However, if the screw case is not palatable, then I would remind everyone 
that the choose() function did not have this problem in its original 
formulation, which was based on nodesets rather than objects.  The 
function was added to overcome the limitation in XForms 1.0 that we could 
not select between nodesets.  It was later proposed that choose() should 
operate over objects instead because there was no good reason to limit it 
to only nodesets. The above screw case is a reason, and may even be a good 
one to switch back to the nodeset formulation of choose().

Put another way, the problem here could be seen as "Problem: choose() is 
doing type rationalization" or it could be seen as "Problem: Because 
choose() operates on objects now, people will use choose() when they 
should have used if()".

To wit, consider the following variation on the XPath expression above:

XPath Expression #2: e[f/@x = if(@x, @x, 0)]

Which does the following:

1) e has attribute x and has any child f with an attribute x whose *string
* value matches e/@x
2) e has no attribute x and has a child f with an attribute x whose *
string* value is 0

And also consider this variation:

XPath Expression #3: e[f/@x = number(if(@x, @x, 0))]

Which does the following:

1) e has attribute x and has any child f with an attribute x whose *
numeric* value matches e/@x
2) e has no attribute x and has a child f with an attribute x whose *
numeric* value is 0

The point of XPath Expressions #2 and #3 is to show that we can do both of 
the reasonable things that might be desired of the x attributes-- treat 
them as strings or treat them as numbers.  The only thing we can't do is 
try to treat them as numbers sometimes and strings sometimes.  Yet, XForms 
offers no way to provide variable datatypes for nodes!

At best, the object version of choose() adds a feature of little or no 
value, and at worst it adds a screw case and/or a controversial feature. 

By comparison, the nodeset version of choose() avoids the screw case, the 
controversy and solves the actual limitation we set out to solve without 
encouraging authors to use it when if() would be more appropriate.   The 
restriction to nodeset parameters and return type also only eliminates 
capabilities whose value was not demonstrated (remember, it was only 
claimed that there was no reason not to have the capabilities).  As such, 
I would recommend we consider reverting to the version of choose that 
takes and returns nodesets.

Cheers,
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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
08/02/2007 09:01 AM
Please respond to
ebruchez@orbeon.com


To
"Forms WG (new)" <public-forms@w3.org>
cc

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/