XForms teleconference August 22, 2007

* Present

Charlie Wiecha, IBM
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Lars Opperman, Sun
Mark Birbeck, x-port
Nick van den Bleeken, Inventive Designers
Rafael Benito, SATEC
Roger Perez, SATEC
Steven Pemberton, CWI/W3C (chair)
Keith Wells, IBM
Mark Seaborne, DreamLabs

* Agenda

http://lists.w3.org/Archives/Public/public-forms/2007Aug/0061

* Previous Minutes

* Next FtF - Hosted by SATEC September 12 to 14, 2007

Attendance Questionnaire: http://www.w3.org/2002/09/wbs/34637/ftfsept2007/
Steven Pemberton: We have just enough to go ahead with it, as of today, but it will be a small turnout.

* XForms 1.1

http://lists.w3.org/Archives/Public/public-forms/2007Aug/0055

Steven Pemberton: John wants us to look at this. A few had sent comments.
Leigh Klotz: My comment was about input vs. textarea. We may not be buying ourselves any favors by trying to specify this. Also, polymorphic type binding, input vs. secret, accessibility, etc.
Steven Pemberton: Good point. What is the essential difference? textarea is always bound to string whereas input isn't?
Mark Birbeck: We've discussed this before. It's not clear there's very much you can say about controls because of various widgets, device independence. Can you say you must make it bigger? Do Kenneth and David make it bigger? Can I render select1 with two choices as a checkbox? There are so many things to account for.
Steven Pemberton: There is an essential difference between an input and textarea; when the control has focus, how does hitting return get interpreted. When a textarea has focus, return gets you a newline.
Mark Birbeck: I've been on lots of sites where control-enter or alt-enter is required. And what does that mean in a voice system?
Charlie Wiecha: Yes.
Leigh Klotz: Steven, maybe we need to say more about textarea instead of input, since textarea is the odd one. It must be bound to some text type.
Steven Pemberton: If we need to say anything it is more vague.
Mark Birbeck: I'm not sure we need to say more; it's like a hint. I see it as the same as input appearance=full if you want to get geeky.
Steven Pemberton: If I could summarize, it is the opinion of this working group that we don't want to say anything about how the controls work, but let the names suggest what they might be for.
Leigh Klotz: I think we say already stuff about textarea. It's just I don't think we need to add this.
Nick van: On the readonly property, we discussed this last call.
Steven Pemberton: Let wrap up input textarea. So we are of the opinion that this text shouldn't be there? Anybody object?

Resolution 2007-08-22.1: We do not accept the "return" change to input.

Nick van: If the model says the item is readonly, I don't think an action can change it. We said it was clear that it cannot be done and now we're changing it. If the model says it's readonly, as Mark Seaborne says, then the model designer says it is readonly then it's the responsibility of the model, and not the view.
Leigh Klotz: You're talking about setvalue?
Nick van: And insertions in readonly subtrees, and maybe submission that places its results inside a readonly subtree.The previous wording said that if a tree is readonly, no changes are allowed. The submission and insert aren't said explicitly.
Leigh Klotz: I just meant we can't replace subtrees in submission.
Nick van: We can in 1.1. http://lists.w3.org/Archives/Public/public-forms/2007Aug/0057.html http://lists.w3.org/Archives/Public/public-forms/2007Aug/0057.html
Steven Pemberton: You've convinced me? Mark Seaborne?
Mark Seaborne: It worries me that we say that some MIPs apply only to the UI, whereas other MIPs don't. We aren't saying you can override calculate. I think it raises the question that Nick said that lets you make a form control readonly without saying the model is readonly, but Mark Birbeck showed there seemed to be different views. It seems like you need a standalone model and a model for the UI.
Mark Birbeck: I agree. It's the logical level and the ability level to give someone a model. Maybe we have a MIP in the backplane model to enforce model-level readonly.
Nick van: If it's UI then it should live in the UI. You could have readonly vs. read-write with different controls.
Charlie Wiecha: You'd have to address that in the split; events that came off setvalue, etc.
Mark Birbeck: We discussed this in the transitional work, readonly attribute on input. Does it move to the model or only affect that control? It sounds like we've got the model MIP.
Steven Pemberton: The fact that they are called MIPs makes me think it affects the model. A change like this would take us back to last call.
Nick van: I think we need to wait for John and Erik.
Steven Pemberton: OK.
Charlie Wiecha: I'm more on the side of letting the actions change it because of the work to get there; I agree with it philosophically, though.
Nick van: [reads]
Charlie Wiecha: I think that's in the context of a control.
Steven Pemberton: That's in the model section.
Mark Seaborne: All the implementations I have tried don't allow setvalue.
Mark Birbeck: I would expect most implementations would have done it along those lines, via the accessor. Of course not on the DOM, you don't have that.
Steven Pemberton: OK.

Nick van: On the next, the repeat object, what does "confined" mean with regard to capture and bubble.
Steven Pemberton: One is not empowered to prevent them from starting at the root.
Nick van: He creates a lot of small DOMs for each repeated item, in a separate DOM. I don't like that. Chiba has only one DOM.
Leigh Klotz: Chiba has two DOMs; many implementations have that. Browser vendors have for a long time had a "shadow" or presentation DOM.
Joern Turner: [IRC] yes
Nick van: Chiba unrolls the repeat in both.
Leigh Klotz: Yes, but that's a choice; it still has two DOMs. I don't know if we want to specify that here, but it's not true that Chiba has one DOM.
Mark Birbeck: This extends that shadow to repeat. It's supposing a certain style, an XBL style, which I like, but it's supposing it.
Charlie Wiecha: ...
Nick van: ...
Steven Pemberton: I'm not sure I like the wording.
Leigh Klotz: We've had a thorn in our side about repeat, not mixing well with the schema of host languages (tables, li, etc). It may be that when we decide to specify this better, we should do it in a way (perhaps more XSLT-like) that plays better with host languages. That would be post 1.1.
Mark Birbeck: Many of the AJAX frameworks have templating structures that work in a more procedural way.
Leigh Klotz: When it's time to specify repeat at this level, we might want to specify it in a way that works better.

Steven Pemberton: Next.
Nick van: I don't think it's necessary to have separate DOMs for repeat.

Nick van: Next, John changed core form controls. Now he says in xforms-readonly and xforms-read-write that group isn't a target. Is that correct?
Steven Pemberton: Do you know why he makes that change?
Nick van: He made a distinction between core form controls and form controls terminology. I always though that the events went to group.
Joern Turner: I'm not sure that's the case.
Charlie Wiecha: Is that only for readonly?
Nick van: Yes, but I'm most concerned about readonly.
Leigh Klotz: There are use cases for xforms-enabled and xforms-disabled for group but as Joern pointed out it wasn't clear.
Charlie Wiecha: We discussed those in Raleigh and there's an erratum.
Steven Pemberton: Then this change is wrong.
Nick van: This is for readonly though.
Steven Pemberton: We think this text needs to be changed. If we have use cases for these events, they should go to the elements.
Joern Turner: I would also say we have important use cases in more complex forms; you often need to use relevance for groups. I'm not so sure about required. That feels to me to be more useful for simple controls to have on each item one by one; it might be a convenience for authors to say that the whole group contains required controls; I'm undecided. Relevance is an important use case.
Nick van: Relevance is corrected; it's readonly and required. I think the readonly one is useful. Required I'm not sure.
Steven Pemberton: Let's wait for John to come back.

* Forms Joint Task Force with HTML WG

http://lists.w3.org/Archives/Public/public-forms/2007Jun/0070.html

Steven Pemberton: We have three members here, Nick, Mark and Sebastian.
Nick van: I haven't done anything yet; I'm not sure if we're supposed to.
Mark Birbeck: I haven't heard anything yet; I think they needed 3 names but I haven't heard back.
Steven Pemberton: It has been created and it has an email list; the next step is to create a charter. I'd understood that a draft charter had been sent. The members are not aware of it.
Nick van: Do you know what's in the charter?
Steven Pemberton: I thought it was the HTML and Forms WG charters that refer to this. I'll look for Dan Connolly's email.

* inputmode modifier tokens

http://lists.w3.org/Archives/Public/www-forms-editor/2007Aug/0007

Steven Pemberton: This was raised for XHTML Basic 1.1. inputmode has modifier, such as digits. Does the modifier need something to modify, or do we assume a default. If I say inputmode=digits do I need to say latin-digits or whatever? Does anybody implement inputmode in this group? I take that to mean no. I'm hoping everybody here is happy that we say that inputmode=digits it means the default script for the user agent. Does anybody object to that? I propose this as an erratum for XForms 1.0 and following languages.

Resolution 2007-08-22.2: We issue an erratum for XForms 1.0 and later editions that there is a default script for inputmode and that modifiers such as digits apply to the default.

Action 2007-08-22.1: Steven Pemberton to propose text for an erratum for XForms 1.0 and text for XForms 1.1 that there is a default script for inputmode and that modifiers such as digits apply to the default.

* The context attr should apply even if @bind used

http://lists.w3.org/Archives/Public/www-forms/2007Aug/0001.html

Steven Pemberton: My gut feeling is that it should be the bind, and not the outer ref. I see the bind as replacing the ref. The origin is talking about what the bind is talking about and not what the ref is talking about. Does anybody have an opinion on this. Both Orbeon and Sidewinder say...Mark?
Mark Birbeck: I will check on my implementation and find out why.
Steven Pemberton: And we should wait for Erik as well. But what do you expect?
Mark Birbeck: What's the behavior if ref is there?
Steven Pemberton: You can have a ref on the insert. Surely it would work according to the ref.
Mark Birbeck: This makes my point that it's too complicated.
Steven Pemberton: I don't hear any discussion.

Action 2007-08-22.2: Mark Birbeck to report his position on http://lists.w3.org/Archives/Public/www-forms/2007Aug/0001.html

* IRC Minutes

http://www.w3.org/2007/08/22-forms-minutes.html

* Meeting Ends