W3C Forms teleconference October 20, 2010

* Present

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]

* Agenda


* Previous Minutes


* XHTML+XForms Zip Location

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.

* Mailing lists for getting Help with XForms


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.

* Lyon

Teleconference times Meeting details Registration http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/

Uli Lissé: I cannot attend due to a family conflict.
Steven Pemberton: Anybody want video conferencing?
Uli Lissé: Maybe screen sharing.

* XBL2 and WebBL


Leigh Klotz: Any news?
Steven Pemberton: Perhaps at HCG this week but there is no news. Soon as I hear something I'll report.

* XForms and Deprecating DOM* Events in DOM3 Events

http://lists.w3.org/Archives/Public/public-forms/2010Mar/0049.html http://lists.w3.org/Archives/Public/public-forms/2010Feb/0000.html http://lists.w3.org/Archives/Public/public-forms/2010Sep/0018.html And new message from Steven Pemberton: http://lists.w3.org/Archives/Public/public-forms/2010Oct/0009.html

Steven Pemberton: I sent a last-call remark.

* Improved UI Events

http://lists.w3.org/Archives/Public/public-forms/2010Oct/0010.html Topic picked for n minute discussion.

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.

* Next Meeting

Nick van: I won't be at the next call I will be on vacation in France.
Steven Pemberton: I will be there.

* IRC Minutes


* Meeting Ends