Erik Bruchez, Orben
John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair)
Uli Lissé, DreamLabs
Alain Couthures, Agence XML [arrived late]
Steven Pemberton: Where is the zip
file? It wasn't in that directory.
John Boyer: I'll let you know. They're
in 2010. It's not linked in to the page.
Leigh Klotz: I'll answer the person
who posted to public-forms with this link.
Leigh Klotz: How did that message get
through? Perhaps posting is open to any W3C member?
Steven Pemberton: I don't know.
Uli Lissé: I cannot attend
due to a family conflict.
Steven Pemberton: Anybody want video
conferencing?
Uli Lissé: Maybe screen
sharing.
Leigh Klotz: Any news?
Steven Pemberton: Perhaps at HCG this
week but there is no news. Soon as I hear something I'll
report.
Steven Pemberton: I sent a last-call remark.
Leigh Klotz: Did we want to time
bound this?
Steven Pemberton: If there is another
topic to discuss after.
Leigh Klotz: The next topic is
planning for next week's discussion.
Steven Pemberton: OK. Let's just
start.
Erik Bruchez: Almost one year ago
at the Xerox F2F we made progress on this discussion. Some things
we agreed on but some not yet. However, at the Cambridge F2F a few
months later in March of this year, when we discussed
xforms-enabled and xforms-disabled, and non-existent controls being
non-relevant and vice-versa, we realized we couldn't decide whether
relevance was identical to visibility. We spent a day on this, on
and off, and there was a lot of brainstorming, use-cases, and
historical discussion of relevance (which wasn't clear). We still
haven't resolved that question. We haven't said relevance is equal
to existence; agreeing on that concept seems to be important for
the next step, which is revising the UI events so we can then
define a clear lifecycle for controls: non-existence, becoming
readonly/read-write, and eventually becoming non-relevant again. So
for relevance and visibility, does anyone have new thoughts or
agreement?
Steven Pemberton: To follow up, it
wasn't just visibility, but also existence?
Erik Bruchez: Exactly.
John Boyer: We have xforms-disabled
and xforms-enabled CSS properties of a UI control that are mapped
to whether it is relevant or not. We can style a non-relevant
thing. We use that quite a bit.
Leigh Klotz: They're enabled and
disabled, not xforms-*.
Steven Pemberton: We map them to
relevance.
Erik Bruchez: ... So we did have that
concern, that some want to style non-relevant controls. The
question is not so much about styling, but what happens if
something is not relevant and not styled as being non-visible. The
proposal I had made initially was entirely equating relevance with
existence. One benefit is that things become simple and you get a
clear lifecycle. But the point was made by Steven and others that
initially relevance meant visibility, but in XForms 1.1 it became
closer to existence: hidden cases being non-relevant and not
reacting, for example. Those were clearly concrete steps taken to
make relevance closer to disabled-ness than in XForms 1.0. So where
do we go from here?
Steven Pemberton: Can we address
the use cases through a different methodology? It's fairly typical
to show things are disabled rather than making them disappear.
There are cases where you want to make it invisible.
Erik Bruchez: We went through the
options. We have controls that used to have a value but then
no-longer accessible; is the content still there and updates? So do
we have two types of relevance? XForms authors commonly use
groups/@ref to control visibility; is that non-relevance or
non-visibility?
John Boyer: We have another problem on
top of group-relevance meaning styling or existence. We have the
same thing with switch. We want switches to act like they're there,
as in wizards: they exist but aren't pertinent yet.
Erik Bruchez: We have the same use
cases. Also we'd like to have validity events dispatched to those
controls.
John Boyer: XForms 1.1 has a medium
place, perhaps not happy, where non-relevance was ...
Alain Couthures: [joins]
John Boyer: We could pull them
apart.
Steven Pemberton: Relevance on the
data and existence on the controls.
John Boyer: I don't know what they are
or how to name it.
Leigh Klotz: I think you named it
pertinence.
Erik Bruchez: That's confusing. If the
data is used in the submission that's relevance. In the UI that's
visibility and existence. So we have three notions: relevance,
visibility, and existence. Existence might be used for the
specification of control lifecycle and might not be exposed or
controlled through a property to a form author.
Steven Pemberton: Isn't the existence
problem only really important to server-side implementations?
Erik Bruchez: I think it doesn't
matter where the implementation is.
Steven Pemberton: I don't understand
why we care. If the UI experience does what you intended then I
don't understand why I would care about existence or not.
Erik Bruchez: The idea was to define a
lifecycle for a control that is clear. Clearly when a control is
first springing to life, it used to be non-existent, and then it
gets bound to data and events can be dispatched. Next step, when a
new repeat iteration is created, where the markup for the forms and
the controls are distinct, there is one set of markup for the
iteration but it's a template or description of what's going to
happen. You'll have at runtime the task for the implementation to
decide what objects are present, and you do that in your
implementation language. When you add iterations you have new
"concrete controls" which spring to life and which can be removed
when the iteration disappears. So even after creation of the page,
the lifecycle includes creation and destruction of controls.
Depending on whether a control exists or not, it's going to do
things or not, including: reading instance data and dispatching
events.
Steven Pemberton: There is an
intrinsic difference between controls in repeat and controls bound
or not: there is either really data or not. The binding remains
there and a piece of the tree is excluded from event propagation
when the data bound is non-relevant, but it still exists in some
way or other.
Erik Bruchez: Not in our
implementation for example.
Steven Pemberton: So is this an
implementation decision? When we say you can style with
enabled/disabled can we say it's not true in all implementations
and be done with it?
Erik Bruchez: Our implementation is
described in the control lifecycle and that could apply to any
implementation. We equate non-relevance to non-existence. When you
say there is an intrinsic difference between repeat content and
binding content, that's not clear to me. You can have an
implementation like ours where there is no intrinsic difference and
existence is visibility. It's a choice we can make and clarify and
it's not tied to the client or server implementation.
Steven Pemberton: It's still an
implementation decision.
Erik Bruchez: No it's an
interpretation of the specification. It governs what you can do
with non-relevant controls and it's not made clear by the
specification right now.
Steven Pemberton: How would the user
experience change?
Erik Bruchez: If you go the route
where a non-relevant control is non-existent, it cannot update its
values and you cannot dispatch events to it. From a form author's
point of view it is invisible.
Alain Couthures: Do you have a test
case?
Steven Pemberton: One that
distinguishes between the two?
Erik Bruchez: I don't have one ready
but... it started because the way that XForms specifies event
dispatch wasn't acceptable to me and was based on marking nodes in
instances. If relevance changes we marked the node and then later
check during refresh. There were cases where a control could go
from relevant to non-relevant and not receive an event. To fix this
we decided that controls needed internal, implementation-dependent
state that keeps current value and current relevance so that when
those properties change refresh can reliably dispatch an event.
That's the rationale for this. We did that proposal and we
implemented it and presented it to the WG for discussion. The only
place we got stuck was the question of interpreting relevance and
existence. It matters for the purpose of dispatching events. You
need proper semantics for MIPs (validity for example) to track
them.
Steven Pemberton: So where
further?
Erik Bruchez: I think I should have
started with that initial rationale. It's not relevance in XForms
1.1 that drives it, but the idea of UI events not being defined in
a way that's usable beyond simple cases. In the last two f2f
discussions when we discussed that, there was agreement that those
problems could arise. There is an easy solution and that's not in
question. But in order to describe it you need to be clear on the
life cycle of the control: for example one decision would be in
repeat a control is created and destroyed, but other controls are
always in existence. In our implementation we took a different
approach and prune non-relevant controls, but for controls not
being bound to a node we took the approach that they are not
there.
Steven Pemberton: In the Backplane
XG we discovered that SMIL (multi-media) has a similar problem.
They have trees which don't receive events. That's why they don't
use DOM3 events. They make tree bits relevant at particular moments
in time. So we're not the only people who have this problem. In a
way it's a failing of DOM events that it doesn't account for this.
So my question is this: Is the problem because we say too much in
the spec: we're too prescriptive about how it has to work rather
than worrying about how it works for the user.
Erik Bruchez: My apologies to the
designer, but I believe the marking algorithm doesn't work. We
don't implement it any more and it's not equivalent. So in that
sense it says too much. So if we remove that from the spec I'd be
happy with that, but then we still have to say something about the
when UI events are dispatched and I'd like to say that: A control
has a lifecycle, and it starts to exist. If it's readonly and then
goes read-write between two refreshes, it gets the event. But it's
also required to say that if the control stops existing (if there
is such as concept) we equated that with relevance and then
dispatch an xforms-disabled event. Then there are no UI events
until it gets an xforms-enabled, then it gets change events again.
This is a purely external way to describe it and there is something
that happens to transition between existence and non-existence. It
seems clear to me to form authors who event handler to a tree: they
should know when they will get events. It seems reasonable to
specify it.
Nick van: In a repeat with paging,
what does it mean when you control is bound to a new node? Is it
disabled and enabled or is it rebound? We have to be clear about
all these cases.
Steven Pemberton: This sounds like
a promising approach; I understand what you mean by lifecycle: you
specify what must happen but not how. If it's disabled, if it's
enabled...
John Boyer: It's a little problematic
because you have to prescribe when the events happen because
actions can hook to events and you have interoperability
problems.
Erik Bruchez: The initial goal is to
make this clear and more interoperable. I agree with Steven that
the algorithm is very specific but doesn't do what we want. I would
like it to say that when something changes you dispatch the event,
but we should go the extra step to say exactly when those UI events
are dispatched to answer your question. It's not a huge problem,
and we just got side-tracked on existence and relevance. That would
be good for the WG to resolve existence, relevance, and
visibility.
Steven Pemberton: I think I hear
progress here. We've run out of time but I am glad we had this
discussion. I suggest that we plan for implementing this and
working out steps at the F2F. Do you think the proposal you sent is
a sufficient basis, Erik?
Erik Bruchez: For me, obviously.
Steven Pemberton: I'll have to study
it.
Nick van: I won't be at the next
call I will be on vacation in France.
Steven Pemberton: I will be there.