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
http://lists.w3.org/Archives/Public/public-forms/2009Mar/0038.html
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.
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.
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.
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.
John Boyer: Please take a look at the agenda and comment on some of the tests that we listed as broken:
Question about how to update test 11.9.4.b
Test 6.1.3.b is broken
John Boyer: We need someone to re-write this test.
Lazy authoring tests are broken
John Boyer: I submitted updated tests; please comment.