Re: Draft minutes for August 1, 2007

Hi Leigh,

Thanks for asking.  I would not have said we resolved not to change it. 
However, we did not resolve to change the choose function to remove the 
type conversion content, so that text stays as-is for now. 

My comment at the end of the telecon was that I was not hearing consensus 
to make the change in that there was only one person in favor of the 
change, and four expressed opinions that it should be left as it is. 
Regardless of final outcome, there was a good airing of technical issues 
and good rationales were presented on both sides of the issue.

1) Keeping the type conversion content in choose() 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) Removing the type conversion content in choose() 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...

We should be able to revisit this issue soon as it appears in LC comments 
from Erik, so that gives a bit of time for Erik to present some additional 
information now that the issue has been thoroughly discussed once by the 
WG.

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





"Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com> 
Sent by: public-forms-request@w3.org
08/01/2007 09:07 AM

To
public-forms@w3.org
cc

Subject
Draft minutes for August 1, 2007






Please start new threads for discussion.
Please respond with corrections.

John, we ended rather quickly so please look at the resolution on the 
choose function and let me know if we resolved that or if we said we 
were going to wait to resolve it next meeting.

W3C Forms teleconference August 1, 2007
* Present
Kenneth Sklander, PicoForms
Blake Jones, ViewPlus Technologies/DAISY
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Mark Seaborne, PicoForms
Nick van den Bleeken, Inventive Designers
Roger Perez, Satec
Uli Lisse, DreamLabs
* Agenda
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0139.html 
Previous minutes
XForms Day
ast Call Issues Needing Approval of Proposed Resolution:
Group 1
Group 2
IRC Minutes
Meeting Ends
* Previous minutes:
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0122.html IRC 
supplement: http://www.w3.org/2007/07/25-forms-minutes.html 
* XForms Day
John Boyer: We have a tentative keynote speaker but will have to wait a 
week or so for confirmation.
* ast Call Issues Needing Approval of Proposed Resolution:
John Boyer: I've sent these out and we'll discuss them here.
* Group 1
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0052.html 
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0080.html 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=67 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=68 
John Boyer: Steven asks that we go with one keyword per hashing algorithm 
for hmac and digest.
Erik Bruchez: I had a quick look. I'm not sure why we would choose some 
other representation (lowercase or without dashes), as those are the 
official names. So we should have the name in the respective specs.
John Boyer: So for SHA it is "SHA-###" and for MD5 it's just "MD5".
Erik Bruchez: If we do something else we should have a reason.
John Boyer: Opinions for or against?
Leigh Klotz: Sounds great.
Resolution 2007-08-1.1: We modify and accept 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=67 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=67 to use the 
official names only (upper case and with hyphens where used).
Action 2007-08-1.1: John Boyer to fix 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=67 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=67 to use the 
official names only (upper case and with hyphens where used).
* Group 2
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0052.html 
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0080.html 
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0074.html 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=70 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=71 
John Boyer: Steven says, "Don't start examples off with an error case." 
Highly editorial, I imagine. Someone wrote in a comment on why the first 
example returns zero. I thought someone explained a rationale.
Nick van: [IRC] it was me ;) seconds("P1Y2M") returns 0 and not NaN 
because the input is a valid duration but. the seconds function doesn't 
takes months and years into account.
Kenneth Sklander: Any non-duration is a NaN.
John Boyer: Steven didn't understand why seconds("P1Y2M") returned a 0. 
The seconds function doesn't take months and years into account. It sounds 
like he wants the second example first; also it doesn't show an 
explanation of what it returns. So it's just editorial.
Roger Perez: [IRC] Rafael sent an email about this issue giving and 
additional sample: seconds("P1Y2M3DT10H30M1.5S") returns 297001.5
Action 2007-08-1.2: For 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=70 John Boyer 
to swap example order and add explanation. Also do the same for the months 
function.
John Boyer: For 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=71 Steven wants 
choose to return objects rather than strings. 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=71
Erik Bruchez: I think that's not directly this issue. The issue was that 
the specification for the function specifies the type of the objects 
returned by saying it depends on the two types of the input parameter; I 
found this funny. I'm not sure I see the need; if you consider any xpath 
function, the static return type is determined by the prototype of the 
function. I think if you have to infer return types it's not quite an 
XPath engine. I don't think we have that in XPath.
John Boyer: So it's really the second sentence, if the two are not the 
same, you treat as if it were comparison.
Erik Bruchez: I imagine if you pass an int and a string, and compare them, 
it would convert the string to an int. The function would then choose the 
second option. It seems funny to make these requirements for hypothetical 
optimizations.
John Boyer: Steven wants a second note that says it returns objects, but 
you seem to want to strike the second sentence and say it returns an 
object.
Kenneth Sklander: I think it's a bad idea. It's not a hypothetical 
optimization; it's very real. I don't see the problem with it; it's very 
clear.
Erik Bruchez: If I do choose(b, 1, abc) then it will return NaN.
Kenneth Sklander: It will do the same as XPath comparison. It will convert 
the integer to a string.
Erik Bruchez: OK choose(b, 1, abc). I expect abc but in this case I 
convert abc to integer.
Kenneth Sklander: That's incorrect. It converts the number to a string.
Erik Bruchez: OK but if I choose to return the first parameter, then I 
return integer.
Leigh Klotz: Returning only strings isn't good for nodesets, so we need to 
keep choose.
Kenneth Sklander: Right.
Erik Bruchez: I'd like to look at XPath 2.0. The if function is not a 
string function. So it's more like the choose function we're trying to 
introduce. I'd like to see what they do. They return either one value or 
the other, without type conversion. To me, that makes perfect sense. I'm 
not sure specifying the behavior brings anything useful, and the XPath 2 
if function doesn't do it.
Nick van: [IRC] http://www.w3.org/TR/xpath20/#doc-xpath-IfExpr
John Boyer: So the author can write their own choose function to return a 
string or a number but if they want to force the value to be a string they 
can wrap it with string(). The optimization would run if the types are the 
same.
Erik Bruchez: We would be preventing different types from happening if we 
did it. This is contrary to the XPath 2.0 if().
Nick van: [IRC] "Conditional expressions have a special rule for 
propagating dynamic errors. If the effective value of the test expression 
is true, the conditional expression ignores (does not raise) any dynamic 
errors encountered in the else-expression. In this case, since the 
else-expression can have no observable effect, it need not be evaluated. 
Similarly, if the effective value of the test expression is false, the 
conditional expression ignores any dynamic errors encountered"
Nick van: [IRC] do we need to specify this for our choose function?
John Boyer: We can't do that in XPath 1.0.
Erik Bruchez: In the choose function, we have to evaluate both parameters 
to get the type.
Nick van: You have to evaluate them anyway in XPath 1.0.
Erik Bruchez: In Saxon, functions receive expressions as arguments.
John Boyer: If you have choose(true, a, b) then it's possible that only 
the second parameter would be evaluated?
Kenneth Sklander: Not in XPath 1.0. It's in section 3.2.
John Boyer: It XPath 2.0 we have an issue with dependencies.
Kenneth Sklander: It's known. We'll have to tackle that when we switch to 
XPath 2.0.
Erik Bruchez: In 3.2 of XPath 1.0...it seems to be the case...I think 
you're right. What if the function doesn't need the parameter? Would it be 
acceptable for an XPath 1.0 engine not to evaluate, if there are no 
side-effects.
Nick van: Dynamic exceptions won't be thrown.
Erik Bruchez: In XPath 2.0 it would be perfectly acceptable. OK so back to 
the types.
John Boyer: We have three parameters. Kenneth, can you give us an idea of 
what happens if we drop the type rationalization? If the author makes them 
the same, can you still do the optimization?
Kenneth Sklander: Not exactly the same, but there is no argument for not 
rationalizing them. I haven't heard any argument for a use case that 
rationalizes them. They have to be rationalized for use.
Erik Bruchez: If I don't know anything about the choose function, I might 
be surprised if it didn't convert arguments in a way I didn't expect. But 
the counterargument is that that happens in XPath. The second argument is 
that in XPath 2.0 the if function is a mix of of choose and if.
Leigh Klotz: Are there places where it converts to lose information?
Kenneth Sklander: It's going to be converted where used.
John Boyer: The id function takes an object. It can provide it different 
ways. You can get either a nodeset or a string. The premature 
rationalization in choose might interfere with it.
Kenneth Sklander: You can return a nodeset with one or more nodes. Anyway, 
I have no strong feelings one way or another. I do like it the way it is.
Erik Bruchez: How does rationalization work if you have a nodeset vs a 
node?
Kenneth Sklander: As far as I know XPath 1.0 doesn't have a node. Only 
nodesets.
Erik Bruchez: If you compare a node to a nodeset what does that do?
Kenneth Sklander: If any node in one nodeset is in another nodeset then it 
return true.
Erik Bruchez: So there are nodesets on both sides.
Kenneth Sklander: We have four types in XPath 1.0, nodeset, boolean, 
string, and integer.
Erik Bruchez: So a nodeset would be perfectly fine.
Leigh Klotz: What XPath 1.0 functions are polymorphic?
John Boyer: The id function.
Kenneth Sklander: So can always analyze id inputs to find out. It's only 
extension functions. You only need one to analyze the id function. If we 
introduce choose...
John Boyer: With static typing you can analyze choose at compile time.
Kenneth Sklander: I cannot think of any example where you cannot do the 
analysis statically right now.
John Boyer: I see that right now there is no function in XPath 1.0 you 
cannot statically analyze.
Kenneth Sklander: In XPath 2.0 it's a new game.
Erik Bruchez: In XPath 2.0 we already have an if function that doesn't 
work the way XForms does. We're now adding a new choose function, but if 
we have a conversion of types useful for certain types of optimizations, 
you have to have some types converted at runtime that wouldn't in XPath 
2.0. So it's yet a different selection mechanism.
Kenneth Sklander: It's not just for optimization; for example, authoring 
tools with completion, at design time. You would have to run the form to 
find that you have an error. So it's not just a runtime optimization. John 
is right that we can convert implicitly and optimize sometimes at runtime 
but it's not just runtime. So let's leverage XPath 1.0 while we use it.
Erik Bruchez: If you determine by static analysis (string, int) then you 
can go further and detect it statically at design time. If the user uses 
the string function around the parameters, then it's easier.
Kenneth Sklander: I think it's better to have static typing, but I have no 
really strong feeling about choose. Maybe we should just decide something.
John Boyer: Sounds like it's a no-brainer to accept Steven's issue here, 
but we have 4 who say it's not a good idea, one saying it's a very good 
idea. It doesn't sound like a strong consensus to change the spec, though 
we haven't gotten to that issue here. It sounds like I don't need to do 
both changes at the same time, right now, so I'll take the action item to 
resolve 71.
Action 2007-08-1.3: For 
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=71 John Boyer 
to add a note saying this is the object version of if.
John Boyer: A fairly strong case would be made that this would be the 
first thing we've added to XPath 1.0 that cannot be statically analyzed. 
It's not as XPath 2.0 compliant; it's still something that XPath 2.0 can 
do, and it's consistent with XPath 2.0.
Leigh Klotz: XPath 2.0 has the complete if function anyway.
John Boyer: So we'll have to deprecate our own anyway.
Resolution 2007-08-1.2: We do not change the choose function definition to 
remove the type conversion step.
* IRC Minutes
http://www.w3.org/2007/08/01-forms-minutes.html 
* Meeting Ends