W3C Forms teleconference August 8, 2007

* Present

Blake Jones, ViewPlus Technologies/DAISY
Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Nick van den Bleeken, Inventive Designers
Roger Perez, SATEC
Uli Lissi, DreamLabs
Kenneth Sklander, PicoForms
Keith Wells, IBM

* Agenda


* Previous Minutes

http://lists.w3.org/Archives/Public/public-forms/2007Aug/0012.html http://www.w3.org/2007/08/01-forms-minutes.html

* 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: Does anyone have program funding to help defray travel and hotel costs for the keynote speaker?
Charlie Wiecha: Should we assume the proposals are accepted, or do we need pruning?
John Boyer: Good point; we had seven submission and six slots plus a keynote, so we need to pick six of the seven. I haven't tried to organize anything yet. The only thoughts I've had so far is that we should go for variety; I haven't looked at the submissions yet, but if anyone wants so, they should. Is anyone who isn't a submitter make an assessment. Who would that be? Probably Leigh, Nick
Nick van: [IRC] I don't think I can do it.
Lars Opperman: I am here.
Leigh Klotz: We have to pick one paper not to present. If there's nothing obvious, then maybe we should do it by lot.
Charlie Wiecha: Yes, we could ask if anyone wants to withdraw.
Leigh Klotz: Another possibility is for two presenters from the same organization to combine.
John Boyer: Leigh, can you do this?
Leigh Klotz: I'll come up with a process for choosing.

Action 2007-08-8.1: Leigh Klotz to propose XForms day program committee paper choice process.

* Need to review and incorporate Uli's changes


John Boyer: These are the changes for "homogeneous collections."

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


John Boyer: Approve? Erratum or just 1.1? The insert and delete actions in XForms 1.0 have a strange behavior that when a new row (repeat-item) is added or deleted, obviously the index of the repeat is updated; there is an extra step that says that any nested repeat indices are re-initialized. I believe this is part of the "cruft" of not understanding what repeat mean, the difference between the objects being repeated and the runtime items. As explained to me, at the time, there was a belief that there was only one inner repeat object, just as there was only one switch object. This leads to messy business throughout the spec. It's clear now that when you have a nested repeat, there is a runtime object for each nested repeat for each row. And the same way that switches for different cases.
Kenneth Sklander: In principle I agree; the one issue I have is what happens if you reference the id from the index function? Otherwise I agree with everything you said about that issue.
John Boyer: In XForms 1.0 and 1.1 [ http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#idref-resolve] there is a special section that addresses that question.
Kenneth Sklander: Yes.
John Boyer: So I'd say that's how.
Kenneth Sklander: So if we adopt that same thing for index function?
John Boyer: We already have; that's what section four is talking about.
Kenneth Sklander: OK.
John Boyer: It says it's applicable to all actions that use an id.
Kenneth Sklander: But index is not an action.
John Boyer: It's applicable to setindex, and likewise in the the third paragraph, it also says the instance function and the index function as well.
Kenneth Sklander: OK. And the built-in id function in XPath?
John Boyer: I think the id function escapes because it is always referring to instance data, which is never within a repeat.
Kenneth Sklander: Right. Is the instance function used in a repeat?
John Boyer: I don't know why that's there offhand.
Kenneth Sklander: Really it's only the index function that references something in the UI, right? Yes.
John Boyer: You have to consider both where the invocation is happening and what is referenced.
Kenneth Sklander: What happens when the DOM is exposed via getElementByID? You should return the correct element.
John Boyer: I would agree that our DOM is actually not that mature. Really the only thing that we give access to from the XForms processor in section 7
Kenneth Sklander: Is the model
John Boyer: And the instance function. It's broken for separate reasons; but the issue here is about repeat index updates. So the question I put to everyone is: Is there anyone who is unsatisfied with the following: http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-insert step 8. The yellow changes aren't the issue nor are the first and second red ones, it's the third red one. The following text is removed "and the index of any repeat nested within an updated repeat is re-initialized to the startindex of the nested repeat. If the startindex is less than 1 the index is set to 1. If the startindex is greater than the size of the homogeneous collection, then the index is set to the size of the homogeneous collection." There is the same language in the delete section.
John Boyer: If you insert, any nested inner repeats, there indices remain in the states they were in.
Erik Bruchez: Or would it be implementation dependent?
John Boyer: That's a good question. I put a note saying it did not change. So I didn't. But it is a note.
Erik Bruchez: Suppose you had two different indices and the user switches between company 1 and company 2 without clicking on an employee; the user will change the index of the current company. With the new behavior, we'll have the index of the employee not changing.
John Boyer: These changes only occur if you insert or change a node; if you switch focus, there is already no change to indices of inner repeat.
Erik Bruchez: We don't specify anything in that case.
John Boyer: I guess. We don't say that they should change, so it seems that they shouldn't. Particularly not if you're counting on it.
Erik Bruchez: It's not crucial; especially if it's not specified. If you change a parent index through user interaction and specify that the user indices don't change, then it's kind of related, because it changes the parent index.
John Boyer: I see your point, and in 9.3.7 I've missed the one in setindex, which also re-initializes.
Erik Bruchez: We have insert, delete, setindex, user interaction, and the tricky case of instance replacement. Maybe we should centralize the behavior separately.
John Boyer: That is the third part of my issue #21. The description of repeat index changing doesn't seem to belong in insert/delete, but in repeat.
John Boyer: ...
John Boyer: Parts 1 and 2 asked for removal on insert and delete; now that I look at it I would ask the same on setindex. When you mutate the index of an outer repeat, that shouldn't have any impact on the inner repeat indices.
Leigh Klotz: Given the change we're making the change to allow non-homogeneous repeats, does it matter?
John Boyer: ...
Erik Bruchez: I'm not sure I understand why this is a problem from a non-homogeneous repeat.
Leigh Klotz: ...
John Boyer: ...
Erik Bruchez: When an inner repeat is not focused, we don't have any way to access it.
John Boyer: You can setindex of outer repeat to each value.
Erik Bruchez: So you can then read it in that case. Good point. But I'm not very concerned. The user won't see the index unless the form author does what John said to expose it. I never had a use case for this. When you switch the outer repeat index from to 1 to 2, what if you want the user to see the nested index set to 1. Can you still do it? But I don't have a use case.
Nick van: What happens with indices in repeats that are not in the active row when you do inserts on active rows?
John Boyer: That's a great question. In delete, only if the index changed as a result of the deletion would the inner repeat indices changed. So it was kooky.
Erik Bruchez: I think Nick's question is different. I have a nested repeat and three iterations of the outer repeat. Somewhere I store the three iterations. Do I delete it if I remove that information?
John Boyer: My interpretation is that you are allowed to discard it. For each inner repeat that is actually generated you get a runtime object that is supposed to represent the entire row of the outer repeat. That object is responsible for all UI objects in that row including the inner repeat. It contains the context, the context node. It generates a bunch of UI controls such as the inner repeat on that row. When you delete that outer row, you delete that object and all the inner controls including the runtime objects for the inner repeats.
Erik Bruchez: I think that would make sense. Now when you go from 2 to 3, the outer repeat index is now 3. What is the index of the new inner repeat? Startindex? Must be within bounds.
John Boyer: I think there could be better wording around it, but whenever you create it (UI init or mid-life) they behave as they do when you initialize them.
Erik Bruchez: ...delete and insert...
John Boyer: That's challenging if you delete and row and insert a row, because you have to check that row to make sure it's the same, by happenstance, in special homogeneous collection cases.
Erik Bruchez: You could have index 3 point to employees and in the same repeat, it could point to the 3rd office in the building, in non-homogeneous collections.
John Boyer: OK. Does everybody feel pretty comfortable with getting rid of the inner repeat re-initialization that's happening in the spec?
Erik Bruchez: I still have this little issue that when the outer index changes through user interaction, would means would you have to reset the inner index. In insert, you are in an action and can do a setindex. If it is through a user interaction, we have no event for catching the index changed.
John Boyer: The setindex action case?
Erik Bruchez: The user interactively changing the index of an outer repeat.
John Boyer: So you go to a new row, and the user clicks on that row, you would expect that by virtue of clicking there that it would re-initialize the focus of the repeat on the same row.
Erik Bruchez: Not if you click on a text area; some implementations may only react to form controls and that's not a problem.
John Boyer: When you click into the text area that changes the index of the outer repeat. You want the inner repeat to be re-initialized?
Erik Bruchez: That would be the idea.
John Boyer: Why?
Erik Bruchez: It's just a possibility; I don't have the use case. That's the behavior we had in XForms 1.0.
John Boyer: When you change index of outer repeat, do you did an explicit setindex?
Erik Bruchez: That's exactly the idea.
John Boyer: And that resets the index of every inner repeat on every row?
Erik Bruchez: Not in XForms 1.0 because you have only one index for the repeat. Now you need multiple ones; that is what you are trying to change.
John Boyer: Actually, in XForms 1.0TE and maybe in SE, we don't have the case that there is only one runtime object for any UI control that is repeated. If a UI control is repeated, it gets a runtime object for each copy.
Erik Bruchez: I agree with that. But in many user implementations, if I see three employees, I don't necessarily see which one has the focus; you can't have two at the same time. Even with the changes you propose now, it's still an option to have a single control have an indicator; we are just talking about how to store the focus information. It's not a user focus. The keystrokes will not be directed to invisible controls.
John Boyer: The index is not the focus. It is an additional piece of information.
Erik Bruchez: Sure. But if we reinitialize the inner repeats then it is as if you had only one piece of information.
John Boyer: Yes, that's what I'm trying to fix. We don't have it for switch anymore.
Erik Bruchez: I think it is good to define how switch in repeat works. But what if you want to stay compatible with what you had before?
John Boyer: ...
Erik Bruchez: ...
John Boyer: So could we tolerate this as an 1.0 erratum? We said switch works in repeat in 1.0, with every switch on every row getting its own case. As a matter of consistency, every repeat on every row gets its own index.
Erik Bruchez: You can't toggle a case through the UI without clicking,
Kenneth Sklander: [departs]
Leigh Klotz: You can do it through submission response and toggle.
Erik Bruchez: It always requires the toggle. But with setindex you can do it without clicking around.
John Boyer: I can use a repeat with an xpath predicate that looks like a switch and it wouldn't act like that.
Leigh Klotz: Do you actually do this evil thing?
John Boyer: No
Leigh Klotz: Just asking.

John Boyer: I'm surprised this took this much time. Do we want to keep the ones in setindex? Just update them on the target row? Please send mail on this so we can get it done by next week.

* IRC Minutes


* Meeting Ends