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

Considering all points of view expressed on this issue over time, I agree.

It seems best overall and thinking forward to let choose() take and return 
objects, and not to rationalize the return type based on the input types.

I'm convinced, and Kenneth said he could live with it, and you're 
convinced, so perhaps if we can get Leigh's to comment if he could either 
be convinced or at least live with this, then we could ask the WG for a 
resolution next week.

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





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
08/08/2007 06:37 AM
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,

Thanks for detailing the initial reason we wanted choose(). The way I
see it, the initial XForms 1.0 if() function was defined too
restrictively and choose() is an attempt at doing if() the right way
(including a slightly less dangerous name).

With that perspective, we should consider the XPath 2.0 way the
standard to aim at. Even if we happened to dislike XPath 2.0 or its
"if" construct, it is there to stay and it had probably seven years of
effort on it, so we should still aim at a convergence with it.

I realize that we can't do *exactly* what XSLT 2.0 does. But the issue
of lazy vs. immediate function argument evaluation is a minor one in
my opinion: unless you use XPath function which have side effects (and
I don't think we have any in XForms, so these would have to be
implementation-specific functions), whether you do one or the other
won't make any difference for the author except maybe wrt performance,
although in that case so many factors are involved depending on the
XPath implementation that I wouldn't even count that.

The four XPath 1.0 types *can* make it unmodified through the choose()
function, so I don't see why we wouldn't do it and instead limit what
choose() supports. By keeping choose() with object parameters and not
rationalizing the arguments, we get as close as possible to XSLT 2.0.

So save for getting rid of choose() altogether, this remains my
preferred solution.

-Erik

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


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