Forms WG FtF at TPAC, Lyon, Day 4 -- 05 Nov 2010

The Wiki Spec

<Steven> Steven: Nick and I declare the Wiki Spec formally open! We think we fixed the last missing ids/broken links (though we do need to move the images to a sub-dir yet)

<Steven> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki

<Steven> Here is the transformed version:

<Steven> 02http://www.w3.org/MarkUp/Forms/Test/XForms1.2/Overview.html01

<Steven> So Alain, that's good news.

<Steven> I will be speaking at XML Holland soon on 'XML Applications' and he is speaking there too, so I'll try and talk with him more

<Steven> Here is a diff between the TR spec and the transformed spec http://www.w3.org/2007/10/htmldiff?doc1=http://www.w3.org/TR/xforms11/&doc2=http://www.w3.org/MarkUp/Forms/Test/XForms1.2/Overview.html

<Steven> which seems to suggest there are some missing bits. I will investigate

<Steven> no do have a code yet

<Steven> no do have a zakim :-)

<John_Boyer> zakim is still having problems detecting when people join

<John_Boyer> Steven, are you guys on the call yet?

<Steven> No John

<ebruchez> can't seem to be able to call in

<Steven> I have to leave, buses were not around this morning, so I am fearful for getting to the station

<Steven> on time

<klotz> * Topic Non-eventable and other thoughts

<John_Boyer> scribe: John_Boyer

<klotz> http://lists.w3.org/Archives/Public/public-forms/2010Nov/0007.html

<klotz> Erik: Summarizes message.

<nick> klotz: there are only two cases:

<nick> 1) don't do events don't be able to style it

<nick> 2) be able to style it and get events

<scribe> scribe: klotz

Leigh: Is that all? Just two cases?

Erik: And when non-relevant but presented you want it not to be interacted with.

John: Backward compatibility is the best reason to have non-relevant items presented but events are off.

Leigh: So for non-relevant case we still have four cases.

Erik: Arguably the controls are there in switch for layout purposes.

John: THe main use for no-event/no-present is the UI lifecycle discussion.

Erik: We can define the lifecycle however we want as long a it's consistent.
... We might need a new event or new context-info in enabled and disabled, to figure out that the control is becoming disabled or it's going away or it doesn't dispatch events.
... If, in effect, not being presentable ... it could mean the form engine has to keep it for eventing purposes, or we're back to non-presentable means it doesn't get events so it doesnt' exist.
... It seems to me we can cover the non-selected case as not visible to the user, by virtue of the UI behavior of the switch/case combination.
... It doesn't mean they aren't presented at all. You could visualize the presented case in front of a stack.
... Yesterday, we said you might want non-selected cases to be sized.

Leigh: You could say there are two options for switch: either the non-presented cases aren't presentable and don't get events, or they are presentable, styled not to be visible normally, and do receive events, but you can override the style.

Erik: Let's take an example of a repeat in a case. If the repeat is alive and you're laying out the control, then you can size the case that has the case rectangle. I dont'; know if you imply that you could do more, like showing non-selected cases.

Leigh: I think John said that's a use case he has.

Erik: That would be compatible.
... I think we don't need a complicated system with eventable and presentable.

Leigh: I think I originally proposed "presented" and "eventable" but it gradually changed.

Erik: I think we need presented (value updates, events) and not presented (dead, don't do anything, can't lay out, can't do events). An implementation would have the option of not creating subtrees.

John: Presented vs presentable. The reason it became presentable is to avoid confusion between delivery of controls to the render engine as distinct from what the render engine does, as there was a lot of confusion.

Leigh: I meant to separate the two: the author has the ability to control visibility, and the author can control whether events are received. I think the host language should control styling.

Erik: ...

Leigh: I think we need to decide what to do about visible but not getting events and not updating.

John: No, it always updates (MVC). It just doesn't interact.

Nick: I think that's strange.

John: The UI events are specified now imperfectly and aren't what the state of the UI should be so the UI update implementation isn't based on events. Eventing is a hook we give authors.
... The UI reflects the state of the model and the form author has no control over that.

Erik: There are two axes: What is desirable, and backward compatibility. Leigh said it might not only be backward compatibility. If it is only backward compatibility and we re-define UI events, it will likely add compatibility or maybe versioning.

John: If we're substantially re-defining how UI events work, we can tell people how they work and stop doing what they did in the past, it's too hard to move all their forms.

Nick: WIth context info you could write an automatic tool to use if enabled.

Leigh: So an attribute that controls events to non-relevant items?
... So we have could have an attribute with a few values.

Erik: relevance level, with the extreme case which we implement now (not relevant = dead), then full mode (gets events), and then intermediate (xforms 1.1 says now). That could be the default in 1.1 mode. Or you could have separate attributes.

Nick: Do we need the difference with events? It's a hack to do the condition.

John: Without an attribute there's no easy way to control it at the different levels of the UI. You'd have to put it on each event handler.

Nick: You could cancel the event.

John: Every event.

Nick: At a certain level.

John: Catch in capture phase, for every event, and do as form author.

Leigh: Erik agreed that different versions of XForms have different defaults. Steven asked for us not to make many incompatible changes in 1.2. I'd prefer a single attribute over two attributes.

John: I don't mind a change if it's easy to control.

Nick: YOu could have a default value on the model.

Erik: If we have an attribute to control this it could be purely view, not the model. I supose you could have a default on the first model. But in general, it would be on an individual control, a group. I think where we're heading now as we don't need a new MIP unless we want to control this dynamically. It's pretty simple. If I were to say that relevanceMode="dead' then that should match what our implementation does. For switch/case we already support

non-relevant cases there or not.

Leigh: How do you control that option?

Erik: We put it in for compatibility and use an attribute to turn on xforms behavior.

Nick: Maybe we can just put it on a toplevel group instead of model for default.

<ebruchez> relevance="full | events | none"

John: There is a convenience and no sweat to put it at the model.

irrelevance = "full | events | none"

Nick: Default model or every model?

John: It could go on any model.

Nick: That's better for embedded model load.

John: If you unload the default model?

Nick: So you can control the controls for the newly-loaded model.

Leigh: For transparent encapsulation.

John: What happens if you unload the default model?

Leigh: That's why I said you couldn't unload things you didn't load.

John: I thought we ended up with unloading anything.

Leigh: Let's fix it then.

John: I'll edit the wiki.

Nick: It's like load target in Orbeon but there's no inheritance, only siblings.

Erik, calling the attribute relevance is misleading.

Erik: We talk about non-relevance. That's not good either.

Leigh: So we're stuck without a name.

<ebruchez> “There are only two hard things in Computer Science: cache invalidation and naming things”.

http://portal.acm.org/citation.cfm?id=639994

bogons="all"

<ebruchez> nonrelevance

absence

absence="fonder"

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/Load_Embedding

germane

Leigh: Let's name it later.

Erik: Any concerns?

Leigh: Let's make it not be dynamic.

pertinence

Erik: It should be easily for this mode for eventing.

available="all|events|none"

Erik: We might need another event or two

Leigh: Or context info.

Erik: If you insert a new repeat iteration, in the UI events proposal I made I said existence=relevance right after it exists it gets the xforms-enabled because it's bound to existence. And when repeat iteration is removed it's xforms-disabled. And when initially created. You could imagine the same in subforms. SInce we are no longer equating relevance with existence it's probably a bad idea to use xforms-enabled and xforms-disabled.

Leigh: Wouldn't newly created form controls be relevant if they are marked as existing only if relevant?
... When is a non-relevant form control created?

John: group/repeat and group binds to a non-relevant node and triggers outside the group contain insert or delete actions. data gets added and the repeat inside the group binds to the nodeset.
... So they are created and then turn non-relevant. That could be two events. I don't have a problem with that. The problem is disabled and destroyed association.

Erik: We could say created non-relevant.

John: I agree. Create and destroy events would be better.

Erik: I agree.
... That's all I was saying.

Leigh: We've tentatively decided we need a new attribute on form controls with a default on each model, with a TBD name and three values, which is static, and new events for form controls to indicate their creation and destruction.

John: We might want an easy way for form authors to suppress certain events. There are two reasons for events: for form authors to hook and for implementations to use. If I don't care about events the implementation would have the option of not dispatching the events unless it was required by the implementation.

Erik: If you don't have any handlers, you aren't interested in the event. We have a simple test: we don't dispatch xforms-value-changed if you have none.

John: We do that too.

Erik: In practice, we use lots of events.
... We maintain an error list and listen on every event.
... So we remove information about controls when they are destroyed.

John: But not readonly.

Erik: Yes, but it's not dispatched as often as create events.
... Or a facility to register stuff dynamically.
... The attribute controls the behavior of non-relevant form controls: all, events-only, or absent.
... events-only are suppressed, as in XForms 1.1.

Leigh: That explains both the feature and why we need a new name.

Nick: Should I add this to the UI events page?

EriK: that's fine with me.

Leigh: Thank you Nick.

<scribe> ACTION: Nick van den Bleeken to add <input suppress-when-non-relevant="events|all|nothing"> to new ui events page. [recorded in http://www.w3.org/2010/11/05-forms-minutes.html#action01]

<trackbot> Created ACTION-646 - Van den Bleeken to add <input suppress-when-non-relevant="events|all|nothing"> to new ui events page. [on Nick Van Den Bleeken - due 2010-11-12].

<nick> rssagent, pointer

* Topic Wrap Up

Leigh: Thank you all.

thanks john.

<John_Boyer> scribe: John_Boyer

- DRAFT -

Forms WG FtF at TPAC, Lyon, Day 4

05 Nov 2010

Attendees

Contents

The Wiki Spec

Summary of Action Items

Scribe.perl diagnostic output