W3C Forms teleconference May 20, 2009

* Present

Erik Bruchez, Orbeon
John Boyer, IBM (Chair)
Kenneth Sklander, Picoforms
Leigh Klotz, Xerox (minutes)
Steven Pemeberton CWI/W3C
Charlie Wiecha, IBM
Nick van den Bleeken, Inventive Designers
Mark Birbeck, WebBackplane

* Agenda


* Previous Minutes

* Next FtF


John Boyer: Since it's fully virtual, how should we schedule it?
Charlie Wiecha: I liked the rolling idea.
John Boyer: How about those in Europe? Originally it was a Virtual Day on June 4th, then June 8th-10th together. Virtual days are really only 5 hours. So do we do 3 or 4 virtual days?
Steven Pemeberton: It's hard to stay on the phone that long.
John Boyer: Doing three virtual days in a row doesn't help. I think Erik responded about the 6AM Pacific Time issue as well.
John Boyer: If we did these every week, how does that play against the telecon?
Steven Pemeberton: In XHTML2, we use one hour of the telecon for the small issues, and use FtF time for one focus (issue or specification).
John Boyer: How are people's times on Wednesdays after this call? It's not great for me, as I couldn't do the full length, but ... do we want to have the weekly call Wednesdays and FtF on Thursday?
Charlie Wiecha: I would say Friday.
Steven Pemeberton: That's a joke, right? It would be evening here. Monday is out. TWR is OK for me, with some clashes, but not Friday.
John Boyer: So Thursday?
Steven Pemeberton: Works for me. What time would you start
John Boyer: 1400-1600 UTC, then an hour break, then 1700-1900 UTC.
Steven Pemeberton: That would work well with me.
Leigh Klotz: For how many days?
John Boyer: If we wanted the same number of hours, we'd have to do six of those. We'lve lose people in vacations. So June 4th, 11th, 18th, 25th, and July 2nd.
John Boyer: Or we could do 5 hours, 1300UTC (6AM PDT), June 4th through July 2nd, giving us the same days.
Charlie Wiecha: Or go later an hour rather than early.
Steven Pemeberton: The original proposal goes to 9PM so this would be 10PM.
Charlie Wiecha: Would people prefer the later option?
John Boyer: Can you live with it, Steven?
Steven Pemeberton: Sure.
John Boyer: So June 4th, 11th, 18th, 25th and July 2nd, 1400-1600 UTC, then an hour break, then 1700-2000 UTC.
Steven Pemeberton: We decided for the 18th for an XHTML FtF, so I couldn't participate.
John Boyer: If we put off the 18th...
Leigh Klotz: Steven's probably not the only person who will miss one, and he'll probably be available on IRC anyway.
Steven Pemeberton: Right.
John Boyer: So we'll have a regular Wednesday call then FtF days on Thursdays.

Resolution 2009-05-20.1: Virtual FtF days for 2009: June 4th, 11th, 18th, 25th and July 2nd; 1400-1600 UTC, then an hour break, then 1700-2000 UTC.

John Boyer: Next, question, do we need a registration page?
Leigh Klotz: Isn't there usually a vacation registration page?
John Boyer: For July and August, but not June. So we could extend it.
Leigh Klotz: It's probably a better match to use the vacation page.
Steven Pemeberton: Good point.
John Boyer: So on Wednesday we can have an agenda planned.
Steven Pemeberton: I get an action item to create the form?

Action 2009-05-20.1: Steven Pemeberton to create vacation form for June, July and August, which will double as virtual F2F regrets page.


* XForms 1.1 Completion

John Boyer: I'd like to get to PR soon. Nick and Uli are away this week. I'm not sure if there are actions for them or me.
Erik Bruchez: I don't think so.
Charlie Wiecha: No.
John Boyer: I changed the target dispatch attributes. The dispatch action also had a target child element. I understood the action to rename the child element as well. I updated the schema and the specification. The word target appears in a lot of places (event targeting).
John Boyer: I thought we could look at the test suite, as we don't have Nick, but I did a quick search but there are 40 affected tests and about half a dozen are submission related. The other 30 something are dispatch. All need to be changed to use targetid instead of target.
John Boyer: How do we test the backward compatibility with the old name target?
Charlie Wiecha: Do we want everybody to update the implementations before we come out? It seems a simple syntactic issue.
John Boyer: So don't modify the tests, but just create new tests.
Charlie Wiecha: I meant are we going to ask EMC, for example, to redo their test report?
Steven Pemeberton: I thought we deprecated and added new, so we can leave the tests as they are. So it's OK to use the old ones.
John Boyer: I wrote the spec as using the new names, and a piece of normative text, processors MAY support attribute or element name "target" ignored if "targetref" or "targetid" appears.
Charlie Wiecha: Then we just need that test.
John Boyer: When we say MAY we need only one implementation.
John Boyer: The implementation report proves implementability; the spelling doesn't change that.
Leigh Klotz: Or change the test suite and say that the implementations passed it with the old spelling.
John Boyer: That's preferable. And if they don't support the older spelling in later releases, I don't want the test suite to fail them.
Leigh Klotz: I'd be happy with just a note from the vendors saying when they've changed the spelling.
John Boyer: And it's not the highest priority that we put the optional backward-compat test in anyway.
Steven Pemeberton: I agree, it's not the highest priority.
John Boyer: So if I just changed the existing test and created zero no new test, that would be OK for now.
Charlie Wiecha: They'd start to fail but it's a trivial change.
John Boyer: They'd have to run the test again to fail, but if they do it's pretty trivial to fix it.
Leigh Klotz: I'd say just send a note to the vendors saying that we've changed the spelling.
John Boyer: I think we don't have to wait for them to respond to go forward. How about just sending it to www-forms? OK?
Charlie Wiecha: OK

Action 2009-05-20.2: John Boyer to make target change to targetid or targetref in XForms 1.1 test suite and send a note about the spelling change to www-forms. We aren't expecting updated implementation reports.

John Boyer: The remaining actions on my plate aren't conformance-level changes, so we should be ready for PR in a few weeks.

* Future Features

John Boyer: We've talked about two tracks, 1.2 and 2.0. 1.2 would use the existing framework and include things already approved (data-driven switch, for example) to plug homes or make it easier to deal with document-centric applications of XForms in ODF. But ODF doesn't use the XForms UI elements. However, we're discussing it with them. Context-attribute everywhere is another example of lower-hanging fruit. By comparison, some of the XForms 2.0 items have been larger, more fundamental shifts of the processing model, such dynamic dependencies or amalgamating the recalculate and revalidate steps. There's grey space in the middle.
John Boyer: So what are the interests of current and prospective WG members.
Steven Pemeberton: I have suggestions for ease-of-use. I don't want to mention them all here, but I'd like to have just one copy of the model and many forms; a sort of data sheet.
John Boyer: Definitely. http://lists.w3.org/Archives/Public/public-forms/2009May/0036.html
John Boyer: That sounds like low-hanging fruit, model/@src.
Steven Pemeberton: There are ID linkages, and those don't work across documents.
John Boyer: I'd assumed it would be brought it as part of a document.
Steven Pemeberton: The IDs aren't exposed in the body of the form, only in the form. So we could change some datatypes. It's not trivial, but I think it's soluble.

John Boyer: Another authoring one is why someone might want to use the same model across multiple documents, with several pages doing incremental collection. One problem is that we have a lot of machinery around restricting submissions based on failure to meet constraints, and required MIPs. If you have several pages working together, you have to submit to get from one page to the next, and there will be unmet constraints. It's like we have to be able to distinguish
Leigh Klotz: states.
John Boyer: Or classes of constraints.
Leigh Klotz: It sounds like constraints in states, SCXML.
Charlie Wiecha: Or sub-models, with constraints in the sub-models.
John Boyer: I don't think model/@src gets us where we need to be. We need to solve sub-models as well. Can we bundle those together? Is that 1.2 or 2.0? Or is that distinction something to defer?

Steven Pemeberton: It could be fun to ask for future version features again in the group.
John Boyer: We've always had an open door...
Steven Pemeberton: But making it a new agenda item.
Charlie Wiecha: And we also have an opportunity to XForms in HTML5 or HTML6. There are some issues there. This may turn more into Ubiquity and other AJAX libraries (JSON support, event models, DOM consistency), and not necessarily related to HTML5. The MVC pattern for AJAX will happen with or without us.

John Boyer: And xinclude?
Leigh Klotz: For model inclusion, but Steven and you had another idea.
Erik Bruchez: We use it on a daily basis and it works.
Leigh Klotz: Sub-models and encapsulation give a higher level of abstraction, but as Erik points out xinclude works and people don't need our permission to use it, but because of the IDS it breaks encapsulation.
Erik Bruchez: We could take time to look at it.

John Boyer: And rich text content? Is that a mediatype?
Erik Bruchez: Yes, we use text/html. The drawback is that we store the HTML as text content. People ask why that is and why we can't edit XHTML.
John Boyer: So the larger issue is that our so-called atomic controls operate on strings seem to have use cases where they are bound to some kind of tree.
Erik Bruchez: We lifted the restriction in xf:copy. It might be good to do this for a rich-text editor.
Steven Pemeberton: This was one of the issues on my list as well. I expressed it as repeat over mixed content.
John Boyer: It has been useful to have restrictions on ref. So perhaps a different attribute, for the rebuild-recalculate?
Steven Pemeberton: We often assume we know the type.
Leigh Klotz: Imagine a textarea/@incremental bound to mixed content; that would produce a rebuild on every character.
John Boyer: Authors would learn not to do that.
Leigh Klotz: But they will want it immediately; our first textarea example was an SMS counter.
John Boyer: So you'd need finer control over rebuild.

John Boyer: And the next would be dialogs.
Leigh Klotz: Like xxf:dialog from Orbeon. And as Charlie would point out, the AJAX libraries are rich with ways to display and style pop-in and grey-in dialogs, but we don't have a good syntax for expressing the intent declaratively.
John Boyer: So all we have to do is handle the event flow. When you press the OK button you get your message to come back up; the event handler fires on any event in the bubble phase. Does XML Events 2 fix that? There's no target phase and it's not the default?
Steven Pemeberton: I think it fixes it in your sense of the word. XML Events is a binding to something that already exists, so we can't specify new behavior. We can't change the defaults because it's DOM Events.
Leigh Klotz: It may be that we trigger dialog differently, as it's more of a switch with the rest of the document.
John Boyer: So it's a binding to DOM Events 3?
Steven Pemeberton: DOM Events 3 never happened so we went back to DOM Events 2.
John Boyer: Can't you set your own default for your own?
Leigh Klotz: How can you have a "you" and a "they"? There's one DOM shared by DOM events and XML Events.
Steven Pemeberton: We pretend the target phase by making the implementation look. But target would be a very bad default. Almost always you have these things (an onclick) on an element. If that "a" has an "em" inside it you won't hear it. The default is well-chosen.
John Boyer: Within mixed content. In XForms I don't care about it.
Steven Pemeberton: That's why target is part of the bubble phase. If you put it on the target that's all you get anyway.
John Boyer: If I have a trigger/message/trigger then the inner one bubbles up. That's why we need a different mechanism, such as a document-level switch, as Leigh said.
Steven Pemeberton: In your use case, you cancel the event, having dealt with it. We have an attribute for that.
Leigh Klotz: stoppropagation.
John Boyer: So the author would write stoppropagation on every element inside a message. That's particularly for content reuse.
Steven Pemeberton: I have to go.

John Boyer: Next week, future features.
Steven Pemeberton: So start posting them?

* Meeting Ends

* IRC Log