W3C Forms teleconference August 15, 2007

* Present

Blake Jones, ViewPlus/DAISY
Charlie Wiecha, IBM
John Boyer, IBM (chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C
Mark Seaborne, DreamLabs
Keith Wells, IBM
Lars Opperman, Sun

* Agenda


* Previous Minutes

* XForms Conference at XML Conference

http://lists.w3.org/Archives/Public/public-forms/2007Jul/0055.html http://lists.w3.org/Archives/Public/public-forms/2007Jul/0036.html http://lists.w3.org/Archives/Public/public-forms/2007Jul/0024.html

John Boyer: I may be able to help with travel expenses for the speaker. We have 6 slot and 7 speakers. I sent ask.
Leigh Klotz: I sent a note to Steven and Sebastian about my action to come up with a process. I have some ideas, some maybe hair-brained, and I want to go over them first.
Charlie Wiecha: Maybe some of the could be turned into a panel.

* Need to review and incorporate Uli's changes


Action 2007-08-15.1: John Boyer to review and incorporate on Uli's changes http://lists.w3.org/Archives/Public/public-forms/2007Aug/0046.html

* Finish deliberation on choose()

http://lists.w3.org/Archives/Public/public-forms/2007Aug/0022.html http://lists.w3.org/Archives/Public/public-forms/2007Aug/0025.html

John Boyer: I think we can come to a resolution without Erik based on the mailing list. I'd like to ask for what Erik wants. Erik's basic proposal was that the type rationalization in the choose function be eliminated. We found that the revering to the nodeset version is insufficient; the object version is better. I found it compelling that we need a choose function, because we need to deprecate the if() function and encourage people to migrate over to the choose function because of the collision with the if construct in XPath 2.0. The choose without type rationalization seems to be the most forward-looking. Keeping it is better than getting rid of it; the object form trumps the nodeset form, and dropping the type rationalization makes sense. It answers multiple last call comments from Michael Kay and Erik.
Nick van den Bleeken: We aren't 100% compatible if we don't use type rationalization, because in XPath 2.0, only the true/false expression is evaluated.
John Boyer: We won't be 100% compatible, but we'll have to solve that problem when we move to XPath 2.0. Frankly it might mean that the choose function survives.
John Boyer: http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#fn-choose
John Boyer: The first sentence ("object version") resolves a last-call comment from Steven. The type rationalization is dropped by Erik's request. I added some notes as well.
Leigh Klotz: I think we ought to just go ahead and say what the issue is in the note.
Nick van den Bleeken: [irc] can't we deprecate if then? in xforms 1.1?
John Boyer: I want to make sure the deprecation language is OK with the group, but making the issue stronger is ok.
Steven Pemberton: [IRC] good idea. so there should be a comment in the section on if(). Oh! It is already deprecated
Mark Birbeck: choose() still refers to if.
Steven Pemberton: This function provides a replacement for the if() function that uses objects instead of strings.
Mark Birbeck: I've been in the past torqued out by all three of those arguments being evaluated; is there any merit of it being pointed out?
John Boyer: I can make another note there. I believe that's also a property of XPath 2.0, that function parameters get evaluated. That's probably why it's not a function.
Mark Birbeck: Yeah, it's an operator kind of thing.
Nick van den Bleeken: If you replace if with choose, then you have no string conversion, so we need another note.
John Boyer: Unless the context in which it was being used required a string. You need string around it. That may be unexpected for some people.

Action 2007-08-15.2: John Boyer to make wording changes in http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#fn-choose to amends notes, first sentence of description, and add notes as described in minutes and look for occurrences of if() throughout spec, including examples.

John Boyer: Is there anyone opposed to deprecating if, making choose return objects, and making the minor editorial changes to choose?

Resolution 2007-08-15.1: For XForms 1.1 we deprecate if, make choose return objects, and make the minor editorial changes to choose.

* Inserts and deletes should not re-initialize inner repeat indexes

http://lists.w3.org/Archives/Public/public-forms/2007Aug/0038.html http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/UI?id=21

John Boyer: Approve? Erratum or just 1.1?
John Boyer: For some strange reason we reset the inner repeat indices (my bias). I don't view inner repeats and their index information being any different than inner switches and the knowledge of what case they're on. My last call comment is that we should get rid of this behavior from insert and delete, and now it's apparent setindex as well. Erik's response was that he agreed and it was a better behavior overall, though he asks for better clarification than just modifying the three actions, for example on focus change. Also a comment in the repeat section on instance replacement. Down at the bottom of his email, I did comment that Erik's major concern was that he didn't want to have no way of doing the 1.0 behavior, so I suggested that to a large extent what people wanted out of the 1.0 behavior could be done with a DOMFocusIn, but if we wanted a repeat index change action, that isn't hard to do.
Leigh Klotz: I added scroll-first and scroll-last for implementing windowed paging view of, say, a corporate address book. Coupled with @if on actions, these could be useful pre-fetch.
John Boyer: Indeed the name scroll would be used in the events. How about switch? Will we be asked for events?
John Boyer: You get xforms-enabled don't you on groups?
Mark Birbeck: You get xforms-select and xforms-deselect. You can listen on the target and parent. If you have a select inside a repeat, doesn't it apply to the row?
John Boyer: Yes, except that with a switch, we have case as target of select. With repeat, we have an implicit root element called group, so people can't listen on that as it has no id. I suppose if you threw an action inside the repeat and listened for xforms-select, you get into the interesting waters of eventing in repeat. If you dispatch an event to the explicit group element and in a repeat element an action that listens to that element by default attributes it would attach to that implicit object. Events don't flow between the DOMs. If you do put an action handler as a child of repeat, that will also attach to the repeat element itself, when the document originally loads. When the subordinate DOMs are created for the runtime elements then it attaches there.
Mark Birbeck: I think it depends on whether the repeat is a parent, or along side in another tree.
John Boyer: The repeat is the parent in the original DOM.
Mark Birbeck: You don't get events processed inside instances, for example. ...
John Boyer: XML Events doesn't say anything about not processing the whole document. So if repeat and the instance are exceptions then we should say that. Then you wouldn't be able to listen on the repeat.
Leigh Klotz: That's similar to the basis of comments we got from Andrew Watt on XForms 1.0, that he felt that XPath required us to have the XPath expressions refer to the host document, and not the separate instance DOM. There's a parallel with what you're saying here on XML Events.
Mark Birbeck: You could load and then remove from the initial DOM tree.
John Boyer: I haven't had a problem with the event handler run on both the item and the repeat or the itemset, as long as the events don't flow between the two DOMs.
Mark Birbeck: The same is true with CSS. Subsumed into the parent, or retained.
Steven Pemberton: We defined XForms 1.0 to be DOM independent.
John Boyer: DOM Events wouldn't work, or I don't see how.
Mark Birbeck: I can't see how but we would have to define it.
John Boyer: We refer to XML Events 1.0 and it talks about how to propagate in a DOM, not across DOMs, nor does our spec. Therefore events don't move between DOMs.
Mark Birbeck: We also don't say that template expansion (repeat) says that it's done via DOM expansion.
John Boyer: To make the events in repeat work, it's clear to me that you have to expand into runtime object (I don't want to say DOM). We have this same issue without adding a new event. I said in this message that you can put a DOMFocusIn handler inside the repeat and any form control inside the repeat item will get it, and it will bubble up to the implicit group. The only hiccup was that some implementers said that if you clicked in the group but outside the form controls that the repeat item index would change but you get no DOMFocusIn. To me it's a little questionable about whether you need DOMFocusIn.
Leigh Klotz: So you listen for DOMFocusIn and then examine the index?
John Boyer: Yes. So the overall question is whether we can get rid of the repeat index re-initialization and we've got all the machinery we need to do that. Erik's not here but we've got his email. I want to ask the group. Are there any objections to getting rid of this repeat index reinitialization?
Joern Turner: [IRC] +1
Mark Birbeck: No. As long as authors know. They can work around it if they want with DOMFocusIn.
John Boyer: OK, so no objections.

Resolution 2007-08-15.2: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/UI?id=21 we accept.

Action 2007-08-15.3: For http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/UI?id=21 John Boyer and http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/UI?id=21 John Boyer to implement spec changes and paste 0038 into issue 21.

* Problem with definition of readonly (1.0 and 1.1)

http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/MIPs?id=176 http://lists.w3.org/Archives/Public/www-forms/2007Aug/0000.html

John Boyer: If a node is readonly, it says we don't allow changes. Then it says we don't allow value changes. Then you look at DOM access in section 7 (inappropriately placed) and we give unrestricted access. There's also xforms-insert and xforms-delete, xforms-setvalue. What do other implementers do, does ref imply respect for readonly?
Mark Birbeck: We have the model protect the value and controls don't reflect the readonly. It should be styled but we haven't done it.
John Boyer: The model protects it, but what about calculate and what about actions? calculate makes it readonly by default.
Mark Birbeck: I believe it's a mistake to allow ways to change readonly values. Kenneth and David have no getinstance.
John Boyer: There's two different paths. One is that readonly is part of a set of MIPs and the model is the property broker that are consumed by views and that actions as part of the controller can do whatever they want. Or, we can say that actions must respect the readonly MIP, but we'd need to do something about our current DOM interface.
Mark Birbeck: It's a candidate for 1.2 work.
John Boyer: The upgraded DOM interface. But right now it's just that it's unclear what readonly applies to. What do other implementers do? Can you insert and delete into readonly or does readonly only protect leaf nodes?
Mark Birbeck: Hmmm.
John Boyer: Let's not go over this time.
Leigh Klotz: http://lists.w3.org/Archives/Member/w3c-forms/2002JulSep/0277.html is the set of messages that led us to making calculate readonly.
John Boyer: Or that calculate defaults to readonly now.
Charlie Wiecha: ...
Lars Opperman: Or could we say that calculate is the exclusive way of modifying a readonly node.
John Boyer: Or that readonly is a piece of information for the views, as relevance.
Lars Opperman: An access modifier for an object.
Leigh Klotz: You also have to allow instance replacement readonly so it can't be a sole exception.
John Boyer: I think actions should be able to modify nodes and readonly subtrees. Please talk next week or defer to the F2F.

* IRC Minutes

* Meeting Ends