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

Hi Erik,

I realize it's probably a rhetorical question, but the rhetorical answer 
is that we wouldn't have to add a numbers only decision function in XForms 
1.2 because we already have it:

number(if(), ..., ...))

We also already have the boolean version:

boolean-from-string(if(..., ..., ...))

The point I made is that the only thing missing is that a nodeset does not 
survive the conversion from nodeset to string result that is performed by 
if().  So we needed another function for that one thing.

It is not possible to make an XPath 1.0 function that does exactly what 
XPath 2.0's if construct does.  One reason is that XPath 2.0 branches and 
does not execute the portion of the if that isn't needed, which the 
function version does not do.  In fact, this is probably one reason why 
even XPath 2.0 did not define decision logic in a function.

However, I think you should be arguing that choose() should not be limited 
to just nodesets because it could help to solve the forward compatibility 
problem we have that 'if' is not an allowed function name in XPath 2.0, so 
if one wants to write content that can survive in both XForms 1.1 
processors that use XPath 1.0 and more advanced implementations like yours 
that already use XPath 2.0, then one should be able to use the choose() 
function instead of if().

Now, using choose() to replace if() does not require removal of the type 
rationalization, but it is a decent reason why going back to nodeset only 
is perhaps too restrictive.  And it even gives us a reason to start liking 
the choose() function. 

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/07/2007 03:19 PM
Please respond to
ebruchez@orbeon.com


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

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







John & all,

I appreciate all the elaboration below. But in the end it comes down
to this: we had in XForms 1.0 an if() function that took only
strings. We are now adding a choose() function in XPath 1.1 which
takes only nodesets. To be sarcastic, will we be adding in XForms 1.2
yet another function that takes only numbers?

It seems to me that there is no reason why a single function cannot
take all the types available. I have said already that I don't
particularly like this choose() function, but if we must have it, then
let it be generic and take objects so that it can handle all the XPath
1.0 types. That's what the XPath 2.0 if... then... else does, and then
migrating from XForms 1.1 choose() to XPath 2.0 if... then... else will
be easy for form authors.

-Erik

John Boyer wrote:
 >
 > 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/
 >
 >


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