W3C Forms teleconference March 10, 2010

* Present

Steven Pemberton, CWI/W3C
Nick van den Bleeken, Inventive Designers
Leigh Klotz, Xerox
Uli Lissé, DreamLabs
Erik Bruchez, Orbeon
Charlie Wiecha, IBM

* Agenda


* Previous Minutes


* Upcoming telecons

* Next FtF

Next F2F in Boston in conjunction with AC Meeting, March 24-26, 2010 http://www.w3.org/MarkUp/Forms/wiki/FtF_2010_03_24_Agenda

Steven Pemberton: So four or five people there and two remotely.

* New members

Nick van: Is Innovimax jouining? http://www.w3.org/2002/09/wbs/33280/forms2010/results
Steven Pemberton: He's one of the organizers of XML Prague.

* Action Item Review

Nick van: I will review action items for next week.

* XForms 1.1 Test Suite issues

* xforms:bind and @ref

http://lists.w3.org/Archives/Public/public-forms/2010Mar/0003.html http://lists.w3.org/Archives/Public/public-forms/2010Feb/0042.html

Steven Pemberton: So you're saying the name is already not enough.
Erik Bruchez: Yes, with @bind on a control, it's clear that the element already has to know whether it is @ref or @nodeset. An implementor can already decide whether to consume a single binding or a nodeset binding. If we have only one attribute, that has other benefits; it's confusing to use the funny name @nodeset on bind.
Steven Pemberton: That's quite a convincing argument. If we took an existing XForm and applied the change so that ref meant nodeset but in certain cases it would be a single node, would that change the behavior of any existing forms?
Erik Bruchez: ref isn't allowed where nodeset is.
Steven Pemberton: If we deprecated nodeset and applied the semantics, is there any place where an existing xform wouldn't work?
Erik Bruchez: I don't see any except if an implementation already supported @ref and already the single-node rule via generic code. It might be that such an implementation would handle repeat/@ref differently; but as a new feature, implementors would have to implement the new behavior. We'd have to ask implementors; it might not be a problem.
Erik Bruchez: We could enable it only for XForms 1.2.
Steven Pemberton: If it doesn't break existing content...
Charlie Wiecha: I can imagine implementations that decide to send value-change events based on the presence of a ref attribute; if you use that on a repeat you'd get events based on the first node.
Steven Pemberton: Erik's suggestion is that that doesn't happen.
Charlie Wiecha: It may be fortuitous that it doesn't happen by virtue of implementors choices.
Steven Pemberton: I'm assuming you're applying MIP events only if the first node is used.
Erik Bruchez: It depends on how we introduce the change; we were thinking of a better way of explaining how and when MIP events are dispatched. This is only an issue with repeat, not itemset and bind.
Charlie Wiecha: If we're embedded in ODF or Dojo, the model processor wouldn't be able to make those decision.
Steven Pemberton: Mark Birbeck has said we should have xhtml:p/@ref.
Charlie Wiecha: Same for me. The model processor doesn't know about the Dojo widgets.
Erik Bruchez: How do you fix bind? It's broken.
Charlie Wiecha: Yes. But I'm not sure that adding @ref is the fix instead of looking at bind. Is there a way for a model processor to make this determination?
Erik Bruchez: If you need two attributes then bind would be deprecated; bind-nodeset and bind-ref.
Leigh Klotz: If you need two attributes, John suggested a second one which controls the behavior, defaulted for xforms controls.
Erik Bruchez: I don't see what the benefits are; for authors can just use one attribute, @ref, and we don't have to revisit bind.
Charlie Wiecha: It works great for xforms controls but it buys us orthogonality.
Erik Bruchez: A control has some kind of runtime; I don't know about p/@ref. It isn't going to be a major feature of XForms. I've never had the problem. I use xf:output. If it's a real control, something that integrates with Dojo, that's a real use case, but it has to have some kind of implementation (JavaScript, you name it) for init, reading data, writing data, and so on. In that case the control can make the decision about single node or nodeset. That's my point. There's no need for external knowledge.
Charlie Wiecha: That's the question; is there any need at the external level. The real case with ODF is xforms without having to define internal APIs. Is there a need at a markup level to have this clarified?
Erik Bruchez: That's the exact question. So far I don't see the need; even if there was a need in some cases, I'd rather go for the simplicity and making life simpler for authors instead of implementors.
Steven Pemberton: I absolutely agree with that sentiment, but we should try to anticipate the problems that Charlie is talking about, because those elements might be future XForms elements, and ODF integration is a good example; we should try to cover all use cases.
Nick van: It's only for value-changed we don't want for complex content. You already get readonly. For complex content in the future you want value-changed.
Erik Bruchez: You need the control to know about the content. That's an argument for the control knowing, not external.
Erik Bruchez: One thing we had in XForms 1.1 is that all MIP and value-changed events are determined through the marking algorithm. I think that's broken. This proposal is for the control to determine when the value has changed, looking at its previous value. Same for readonly-readwrite, to dispatch its own events. The form author sees the controls, not the implementation. I see only benefits for the control to read its bindings and decide when to dispatch.

Steven Pemberton: I keep swapping between the two. First you see it one way, then the other. I'm definitely a supporter of using ref everywhere.

Erik Bruchez: ..
Steven Pemberton: Why not just use [1] if you want to bind to the first instead of using a single node.
Erik Bruchez: ...
Steven Pemberton: OK for bind. But do you want the nodeset delivered or is it ambiguous.
Nick van: Where would it be ambiguous?
Steven Pemberton: Only on elements in other namespaces.
Erik Bruchez: I'm looking for a concrete example. If you add your own controls, you have to specify how the controls consume bindings. That's no problem. If it's a repeating control, it consumes a nodeset. Otherwise, just a first node. Is it that it doesn't look as declarative? I don't see the philosophical difference.
Steven Pemberton: Maybe you're right; as you said, bind has this problem already. So we have ref and bind that work the same way. You don't have to say anything special about bind.
Erik Bruchez: I don't think that's a problem. If I have xforms:input/@ref="..." with a 1000 nodes. XPath expressions in Saxon are iterators; so if you consume one item, just iterate once.

Leigh Klotz: What about using select, as we heard from Mikko Honkala early on.
Steven Pemberton: I'm not sure what changing the name would be.
Leigh Klotz: We're talking about changing the name.
Steven Pemberton: I would propose that we make ref and nodeset still work everywhere. So I would be reluctant to change it, in order to keep compatibility of at all possible. If we were starting from zero, I'd say we should consider it, but we now have forms, so I'm not in favor of changing select.
Charlie Wiecha: It's not the name issue; it's single vs multiple binding and whether we want the control in charge.
Steven Pemberton: I'm not sure we should make a resolution until we have more people. But I'd like to take a straw poll. Is anybody opposed to adopting "ref" as the generic word for selecting?
Leigh Klotz: We haven't discussed the repeat attributes. Does that make a difference?
Erik Bruchez: We should change repeat-nodeset to repeat-ref.
Nick van: Or repeat.
Charlie Wiecha: To answer your question Steven, I'm not there yet.
Steven Pemberton: repeat-bind, repeat-number, ...
Charlie Wiecha: I want to push more on the idea that the form control is in charge and see if that leads to complex content...
Erik Bruchez: We can do ref, we can leave it as is, or we can do something else. I'd like to see the alternative and how it works with bind. We have a pretty clear idea of the semantic of ref in those places, but I don't see the impact of the alternatives.
Steven Pemberton: I see another possibility; leaving ref and nodeset as they are, and adding select, as Leigh points out, to use select everywhere. That would be a new behavior going forward.
Erik Bruchez: I'm not sure it would answer Charlie's concern. The unified attribute would be the way forward.
Nick van: [irc] If we change something I support having ref everywhere, and another solution should be as easy for the author as ref everywhere (or another attribute name everywhere)
Erik Bruchez: It would be called "select" instead of "ref" but it wouldn't address Charlie's question.
Charlie Wiecha: I agree.
Steven Pemberton: How do you resolve your misgivings?
Charlie Wiecha: Do we have an agenda item for putting the control in charge? I'm concerned about the modularity of the model and view; Erik's proposing another way of still doing that, which is where control is more in charge than the model. There may be implications to discuss.
Nick van: We discussed improving UI events. In my opinion, these events aren't the ones that model uses to communicate to the UI. The model can use its own events and the UI can use its own events for authors.
Steven Pemberton: I've added it to the F2F agenda.

Leigh Klotz: I've tracked down the discussions before and you can read them. We shouldn't repeat the mistakes of the past.

* F2F Hotels

Charlie Wiecha: I've posted the hotels list.

* Next Meeting

Steven Pemberton: The next meeting is an hour earlier for Europeans.

* IRC Minutes


* Meeting Ends