W3C Forms teleconference March 18, 2009

* Present

Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Paul Butcher, WebBackplane
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Charlie Wiecha, IBM

* Agenda


* Previous minutes

* Backplane


Charlie Wiecha: We're going to demo a financial services website with data about stocks, personal transactions, etc. We can experiemnt with tabular and graph XForms widgets, all done in the Ubiquity framework. I started on repackaging the SVG code from IBM's Emerging Technoloy group. It will be a custom control widget for custom control. What markup would you suggest? repeat for wedges and outputs? Didn't we discuss this? select and select1 to interact with?
Charlie Wiecha: Jack Janssen is working on his SMIL implementation, for time sheets. Steven is proposing work with Mark on packaging of maps and tiles using XForms to show a flexible way of having tile providers communicate. We're showing data and view aspects. Steven?
Steven Pemberton: I think you've got it.
Leigh Klotz: Wasn't there a proposal for adding child elements to select to do switch and case? That might be some discussion to read.
John Boyer: That was a 2.0-ish feature. The repeat is an interesting idea.
Charlie Wiecha: There's not much structure shown. It's a question how to specify the data.
John Boyer: It's a group with a ref; you need a repeat.
Charlie Wiecha: You need a repeat-value to show the data. It's like a repeat and data value for map pinpoints.
Steven Pemberton: He got data from another site (Doppler, who's close) and then put stuff on top of the map.
Charlie Wiecha: I got the tax example and it comes up. The filtering is a little better in SVG in Firefox than in Webkit. The reflections are nice in Firefox. I'll post it in a day or two.

* XForms for HTML

Leigh Klotz: For last week's item, where am I supposed to find the RNG schema for adding to the validator.
John Boyer: I think you should ask Sam Ruby.

Action 2009-03-18.1: Leigh Klotz to contact Sam Ruby about HTML RNG Schema for adding XForms for HTML validation.

* Next FtF

John Boyer: London, Amsterdam?
Steven Pemberton: The invitation to Amsterdam is still open and it depends on Mark's position with London.
Paul Butcher: I don't know his position but I can find out.

Action 2009-03-18.2: Paul Butcher to find out Mark Birbeck's position on F2F in London for next week.

Charlie Wiecha: I volunteered to coordinate space from IBM for London.
John Boyer: You were going to ask about now. The 8th-10th.
Charlie Wiecha: So it's within the three-month window. I'll ask now.

* Submissions and RRRR

http://lists.w3.org/Archives/Public/public-forms/2009Mar/0007.html http://lists.w3.org/Archives/Public/public-forms/2009Mar/0012.html

John Boyer: People are finding that multiple sequential web service calls have inefficiencies. The UI refresh is absent from the pre-submission check. We needed to check rebuild/recalculate/revalidate, which we added to support action sequences of setvalue/setvalue/setvalue/send so that if the setvalue needed did a calculate to run it would run before the submission of the data; similarly, if constraints were violated, we wanted to make sure that he the values of the constraint MIPs could be calculated so the validity of the nodes could be assessed. Then we had to handle insert/delete so we did the rebuild.
John Boyer: On the othe side of submission, when we get the results back, we say we do the rebuild/recalculate/revalidate without dispatching the events, so they are not cancellable. One reason we don't just do the deferred update flag is that submission is by default asynchronous, so the action sequence will end before the submission is processed. So you aren't in the action sequence any more when it comes back, unless you're doing synchronous submission. So we could switch to deferred updates if you're doing synchronous submission. But for the lion's share (in my opinion) it doesn't help with asynchronous, because you'll get RRRR after each chained submission (chained from submit-done).
Erik Bruchez: My concern was about consistency; performance is a concern, but consistency is more import. Consider synchronous submission, because that's what we do and it may be easier to understand. It may have no change to data, replace data, or replace text nodes in the instance (replace=all doesn't apply here). It's equivalent to an xforms-insert or a setvalue (with replace=text). We already have some specific actions that we take when we do an insert or setvalue with regard to the flags (RRR for insert, RR for setvalue). I think it should be the same for synchronous submission. So I argue for removing the current text which says you must do the actions away right away and instead say you should set flags. You just have to learn the logic of those flags once and not think that with submission it should be different.
John Boyer: That's a neat way of looking at it, where a replace instance submission should replace a node as if by insert; you might even end up with an xforms-insert event, which would be kind of cool. Text should behave like setvalue. Those actions do RRRR or just RRR. But as you pointed out, for chaining, the refresh is not a problem for successive synchronous submissions, because they check RRR at they beginning of the next submission. In the asynchronous case, having "this behaves as if it were a setvalue" it's like we say our UI bindings act like setvalue, which sets the flag. The UI control is like an outermost action handler and runs the deferred updates. That's the same thing that would happen for result processing for asynchronous submission. It's not within another handler so those actions would run. Then we would have correct behavior in both cases. We wouldn't have optimized chaining of asynchronous submissions, which is another problem.
John Boyer: So where do these things live; in XForms 1.2?
Leigh Klotz: Is this only in submission reponse or prior to submission?
John Boyer: Erik's part was the submission response. How to suppress the execution of updates in chaining asynchronous submissions I don't understanding.
Leigh Klotz: I just wanted to make sure that when Erik said that authors should understand flags that this applies to the submission response, but submission send has additional semantics and we still want to make sure that it guarantees that the constraints aren't violated.
John Boyer: Right, we're talking about just the back end. The second chained asynchronous submission will check the flags and avoid refresh.
Leigh Klotz: That would be possible with a manual refresh?
John Boyer: Yes. You'd have to do a manual xforms-refresh.
Leigh Klotz: Yes, for example the asynchronous work that we did with PicoForms and the chat application showing how to use a loop of submissions triggered by submit-done to keep an instance in sync with data on the server. We did an example with a chat application.
John Boyer: And you'd need an xforms-refresh there, or the refresh would occur via the flag after the toplevel action completes.
Leigh Klotz: So a send button or incremental=true would be the end of the toplevel action?
John Boyer: Yes.
John Boyer: To suppress the additional r/r/r in the asynchronous case you'd need extra markup. Is that reasonable? Is any of this 1.1 or is it all 1.2?
Erik Bruchez: The minimum way of specifying this would be to modify the local text in submission and say that instead of doing actions right away, you just set the flags. That would be a minor change. If you want to modify it more heavily to re-word it in terms of xforms-insert and setvalue that might take more.
John Boyer: That might be easier from the start; the xforms-insert event would be the only notable change. And we don't have to say any more text about flag processing (asynchronous, run them yourself, but synchronous, just set).
Erik Bruchez: I'm biased because we already implement things that way. I'd like to see it sooner than 1.2 if possible and consistent with 1.1 process.
Leigh Klotz: Is this implementation feedback? It can't be feedback on asynchronous submission because Erik doesn't implement that.
John Boyer: In the synchronous submission case, if you had two in a row, the first sets the RRR flag and the second takes action on RRR but not refresh. So that's an improvement. Then at the sequence RRRR.
Leigh Klotz: Are the flags 1.0 or 1.1? What's the difference that Erik's commenting on.
John Boyer: In 1.1 the issue over 1.0 is simply synchronous vs asynchronous submission. Erik has made XForms more consistent.
Leigh Klotz: What is the XForms 1.1 feature that Erik is commenting on? If it's a 1.0 feature then it will be harder to argue that this is implement feedback.
Erik Bruchez: Unless I'm mistaken, the flags are new in 1.1. I believe in 1.0 we said "right away." I think the flags are new in 1.1.
John Boyer: The flags are 1.0 Third Edition, I think. I don't understand the point.
Leigh Klotz: What feature is it that is updated in 1.1 that Erik is providing implementation feedback on?
John Boyer: It's the submission result processing. We're now saying that
Erik Bruchez: One thing is the synchronous vs asynchronous distinction. So the flags that were in the distinction could be it.
Leigh Klotz: But you don't implement asynchronous submission so I'm not sure how this can be feedback on it.
Erik Bruchez: The spec wasn't clear in 1.0 about synchronous vs asynchronous.
John Boyer: Actually you have to ask for synchronous submission in 1.1 if you want it. In 1.0 you didn't.
Erik Bruchez: Leigh are you saying that if you can't rationalize it, then we can't put it in?
Leigh Klotz: I'm saying the contrapositive which is that if we can show this is 1.1 PR feedback it's easy to get in. Otherwise we have to decide whether to put it in or whether to wait for 1.1 SE. So far I haven't heard the clear statement about what the is 1.1 feature you're providing back on.

Erik Bruchez: For XForms 1.0 TE, did we have a CR phase? We didn't have reports.
John Boyer: Right.
Steven Pemberton: For PER the changes didn't make any changes to implementation requirements.
Erik Bruchez: So that's a double-edged sword.
John Boyer: The note of update flags existed in 1.0 first edition, and we described it as flags in 1.0 SE. Submission result processing in XForms 1.0 first edition has already been corrected in these PERSs. It says the results are processed and we do xforms-model-construct. Through subsequent edits we changed that from dispatching the event to RRR. Relative to 1.0, 1.1 is quite different. The submission processing by doing RRR is the 1.1 feature.
Erik Bruchez: But it's a 1.1 SE or TE feature.
John Boyer: Which didn't require implementation reports.
Erik Bruchez: That's one reason we're discussing this now. The test suites as well are showing problems.
Leigh Klotz: Maybe we should discuss whether to accept this anyway or not.
John Boyer: Actually, we've met the criteria you set; this is the first time there are implementation reports since the change. Submission has changed since then.
Leigh Klotz: So by the zero-crossing theorem it must have changed between 1.0 and 1.1.
John Boyer: Right.
Erik Bruchez: It just happens that now we're trying to fix it.
Leigh Klotz: If that's the case we might as well do all of what Erik suggests instead of the minimal change.
John Boyer: The issue of how to suppress it is a 1.2 feature.
Leigh Klotz: Can you do it with an event handler and cancel it?
John Boyer: No, because a setvalue doesn't have an event and xforms-insert is a notification event. The refresh will be held for synchronous submissions. In the asynchronous submission chaining case, we're still getting the full RRR between each pair of submissions, so we still have that as a separate problem.
Leigh Klotz: I thought you'd only get the processing signalled by the insert.
John Boyer: The insert sets the flags and you get the rebuild.
Leigh Klotz: I believe that Kenneth has said that Picoforms doesn't do a full rebuild after an insertion. So if we re-define submission response in terms of insertion then that should happen naturally.
Erik Bruchez: The flags are a poor-man's constraint system.
John Boyer: If a tree falls in the forest, it's OK to optimize because nobody can tell.
Leigh Klotz: If rebuild is arbitrarily fast, then aren't you just getting consistency problems?
John Boyer: It's not only rebuild but also revalidate, recalculate, and refresh and they're processed when the outermost action handler.
Leigh Klotz: Do you have an idea of how you want to fix this in the future so that we can make sure we're not breaking that?
John Boyer: Maybe some attributes on submission that says not to set the flags?
Leigh Klotz: How about on any action?
John Boyer: The submission response handling happens after the action is done, asynchronously. We don't have to design it here.
Leigh Klotz: It sounds like attributes on submission or on a new child element of submission that is life-after-submit.
John Boyer: Right. So it's for later. If you chain synchronous submissions you get some savings.
Leigh Klotz: One case is multiplying the price of rice in China by the temperature in Tokyo; that's synchronous and we don't care about showing intermediate states. In asynchronous chained submission you want the app to be interactive between submissions so you need the full RRR. So it sounds reasonable to me: use chained synchronous submission if you don't want people poking at the state in between, and the RRR is obviously easily optimized then, but it's not so easily optimized out in the asynchronous case because it could be days between operations.
John Boyer: It's not the full RRR because the processor can't know it's chaining submissions. But the refresh certainly.

John Boyer: Is anyone uncomfortable with changing submission response to say it's expressed in terms of insert and setvalue?
Steven Pemberton: [irc] I'm OK with it
Leigh Klotz: It it insert or insert and delete?
Paul Butcher: Insert at root?
John Boyer: With target it's insert and delete.
Erik Bruchez: If you insert an attribute it's an insert and a delete.
John Boyer: One way we could ensure that we get absolutely minimal effective change here is to say that, as Erik says, we specify behaves and say it's consistent with insert/delete or setvalue settings, the main difference being that you wouldn't receive an xforms-insert event. But my gut feel is that the receiving the insert event is better.
Leigh Klotz: So if there is no delete then the old data is still there.
John Boyer: So you get a delete then an insert, except with the root which as Paul points out gets replaced. So anyone who does listeners will have a better time of it.
Leigh Klotz: I think we should consider doing the whole thing we want now rather than point fixes. What does Erik does do with the events?
Erik Bruchez: We don't dispatch the events but we do call the same code. There are two sides: as a form author, you'd expect the events for insert and delete; however, if those events reflect the fact that something was inserted or deleted. But we don't use insert and delete elsewhere.
Leigh Klotz: We do with select/copy.
Erik Bruchez: But we don't say we use insert and delete there.
John Boyer: We do say that there.
Erik Bruchez: So for consistency then we should.
Leigh Klotz: In select/copy does it dispatch the event?
John Boyer: I'm pretty sure that it dispatches the events.
Leigh Klotz: I think that's our answer then.
Erik Bruchez: I don't see where the reference to insert is. I see, "as if an insert action has occurred." It hadn't registered that we should also dispatch. That part could benefit from being slightly clearer then. It doesn't imply that the whole of the insert processing should take place.
John Boyer: You're talking about the copy element.
Leigh Klotz: I'm all for making them do the same thing.
John Boyer: It's the same with the delete case.
Leigh Klotz: I don't know which is right, but "as if" sounds like it means without the actual action.
John Boyer: "as if" sounds to me like it drags along the whole thing.
Leigh Klotz: You could say "is done" rather than "as if."
Erik Bruchez: If we agree that the intent was that xforms-insert and xforms-delete we leveraged, I believe ti should be the same, including dispatching teh events.
John Boyer: So I should correct or massage this wording as well.
Leigh Klotz: I think that since Erik changed his understanding after talking to you, if you just write down what you said to him, then others will benefit when reading it.

John Boyer: How about "copy action does its work "as if" by an insert action or a delete action, meaning that insert or delete action is the way in which the data mutation is achieved, so you don't just get more or fewer nodes, but you get the drag along of the insert or delete action processing"
Leigh Klotz: How about "copy action does its work by dispatching an insert or delete action."
John Boyer: Not "dispatching" but "executing" and submission result will say the same thing.
John Boyer: OK. That sounds like an action item.

Action 2009-03-18.3: John Boyer to update select/copy case, xforms submission result, and UI setvalue controls to make it clear that setvalue, xforms-insert and xforms-delete are executed rather than "as if" they are executed.

* Tests

John Boyer: Please take a look at the agenda and comment on some of the tests that we listed as broken:

* IRC Log


* Meeting Ends