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


* 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


* Meeting Ends