RE: Draft minutes for August 1, 2007

OK, I'll re-issue and remove the resolution.  You might want to change
the subject and re-send this rest of your to make sure it gets full
attention.

________________________________

From: John Boyer [mailto:boyerj@ca.ibm.com] 
Sent: Wednesday, August 01, 2007 10:13 AM
To: Klotz, Leigh
Cc: public-forms@w3.org; public-forms-request@w3.org
Subject: 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
<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
<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
<http://lists.w3.org/Archives/Public/public-forms/2007Jul/0122.html>
IRC supplement: http://www.w3.org/2007/07/25-forms-minutes.html
<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/0052.html>
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0080.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=67>
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=68
<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>
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>
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/0052.html>
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0080.html
<http://lists.w3.org/Archives/Public/public-forms/2007Jul/0080.html>
http://lists.w3.org/Archives/Public/public-forms/2007Jul/0074.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=70>
http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=71
<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
<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
<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
<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
<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
<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
<http://www.w3.org/2007/08/01-forms-minutes.html>  
* Meeting Ends