W3C Forms teleconference May 14, 2008

* Present

Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Doug Scheppers, W3C
Steven Pemberton, CWI/W3C
Uli Lissé, Dreamlabs
Keith Wells, IBM

* Agenda


* Previous Minutes

Previous minutes: http://lists.w3.org/Archives/Public/public-forms/2008May/0006.html IRC supplement: http://www.w3.org/2008/05/07-forms-minutes.html

* XTech

Steven Pemberton: It wasn't quite as well attended as last year, but a good conference. I gave a half-day tutorial on XForms which was attended by about twenty people, which is sizable. I learned of two new implementations, one at the exhibits. The other one is Mark Birbeck plus IBM's Ubiquity.
John Boyer: We thought we'd promote ubiquity of XForms
Steven Pemberton: There was a huge amount of RDFa.

* Ubiquity

John Boyer: I have been working with Mark Birbeck to launch this new project for XForms. http://code.google.com/p/ubiquity-xforms/ It's a pure AJAX library implementation of XForms with the ability to be glued to a number of UI libraries such as YUI, Dojo, Scriptaculous, etc. The key is to to promote ubiquity of XForms on the web under the Apache license and to make it available under all the platforms. I think there's a lot of opportunity to contribute and to wrap projects around the core implementation. It's a JavaScript license, completely in the browser.

* F2F

John Boyer: It seems like it's time to have a registration page. http://www.w3.org/2002/09/wbs/32219/formsftf200806/
Keith Wells: I won't be able to attend.

* Rich Web Application Backplane

Charlie Wiecha: We have our kickoff call Friday at 10AM, either weekly or biweekly. If it's weekly we'll have to change time due to HCG. I've invited some others to join, but the Voice issue is up. Please join up if you can. We have about half a dozen at this point. It would be good to get more. It would be good to tie some discussions to the code project for experimentation, perhaps in another project; it would then not be just a paper exercise.


Action Item List: http://lists.w3.org/Archives/Public/public-forms/2008May/0014.html Those with >>= 10 actions should commit to taking down one specific action item from their list this week. Can't be one someone else has already done. Which one?

John Boyer: Nick I heard you are eager to get started on the spec-ready text, even though you don't have ten items. I can help create the bundle.
Nick van: I'm glad to help.
John Boyer: We have lots of technical knowledge; the exercise is getting it communicated. You can put it in the wiki page first if you want, but the ideal would be to work together.

* ITS Action

Leigh Klotz: Felix Sasaki has said their group is not publishing now, but they would like to work with us to publish a guide on how to use ITS with XForms. I suggested we put it outside of TR space, as we did with Steven's guide to XForms for XHTML authors.
John Boyer: In the wiki?
Leigh Klotz: No, as a document, but just not in TR space. It's like a Note, but not headed towards a spec, just informative.

* CSS Action

John Boyer: There are two issues: specifying presentation without CSS in the spec, and updating the sample section on CSS.
Leigh Klotz: The first is hard.
Leigh Klotz: John, I should send you a message and see if my concerns make sense.

* Forms Task Force

John Boyer: Nick and Keith, can you break down some of the messaging on the principles and get them out as discussion points? They also had some feedback. So break it down.

* Form tag(s), implied model(s)

John Boyer: For point B, I'm a little fuzzy on accept and accept-charset. Is there a submission expert?
Leigh Klotz: If it's not UTF-8 I don't understand it.
John Boyer: Me too.
Nick van: http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3
John Boyer: "This attribute specifies a comma-separated list of content types that a server processing this form will handle correctly. "
Leigh Klotz: This is the mediatype attribute on xf:upload: "User agents may use this information to filter out non-conforming files when prompting a user to select files to be sent to the server (cf. the INPUT element when type=file)."
John Boyer: OK, so we could use it in upload.
Leigh Klotz: Default if not otherwise specified.
John Boyer: That seems reasonable. http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3

John Boyer: For accept-charset we may need to look at it more closely.

Action 2008-05-14.1: Nick van den Bleeken to read http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3 and make proposal for accept providing default to xf:upload/@mediatype and make proposal for accept-charset for http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3

* Implied submission with form tag and/or with submit

Nick van: I made a wiki page about this. http://www.w3.org/MarkUp/Forms/wiki/Allow_submission_elements_without_model_element The idea is allowing the submit or a send to refer to a submission but also override the attribute you can specify on the submit or the send. For example, a different resource to submit to two different search engines.
John Boyer: So would they override the default submission of the default model or would they create their own?
Nick van: Create their own.
John Boyer: And they would default from the form tag?
Nick van: I'm not sure we need to decide. If you don't specify a submission then they get the attributes from the form tag; that sounds reasonable.
John Boyer: You can't submit the form unless you have a submit control inside the form tag. So the thing that implies an XForms submission is the existence of a submit tag.
John Boyer: We need someone to write a proposal for the group for this kind of things.
Leigh Klotz: You don't need a submit in HTML4 for submission.
Nick van: Enter will do it.
John Boyer: Does that work everywhere?
Nick van: Yes. They listen for enter key on input. Leigh : Yes.
John Boyer: That suggests you need to imply a submission. What if you put an input type="submission"?
Nick van: It will do a submission.
John Boyer: Can you override it?
Nick van: You can cancel the default in onsubmit.
Leigh Klotz: I can't remember the outcome of multiple submits and enter.
Nick van: None are added, but mostly they use an onsubmit handler.
John Boyer: If you have an onsubmit handler is it cancelled?
Nick van: It depends on the return value.
John Boyer: We'll have to respond to this in the streamlined stuff as well, being able to cancel what we call the xforms-submit event.
Nick van: Isn't that something needs to be described in the HTML attributes model? We won't add it to our language.
John Boyer: It would be a note to the HTML onsubmit implementer. If it returned zero, say, we'd set the cancel flag on the xforms-submit event.
Nick van: Adding onsubmit doesn't make much sense in xforms.
John Boyer: Yes, it's like name. A form author may add them but we don't directly respond. It's like globally-named attributes that a particular processor may support.
Nick van: We need a chapter or module explaining it. Our buttons don't add data to the instance, for example.
John Boyer: We have two techniques in the spec to merge that in. We can define the section as informative; it can be advisement on how to integrate. Or we can use a note; a lot of people tend to regard normative notes as normative.
Nick van: We'll have a lot of them.
John Boyer: It took only a couple of sentences to say that the XForms processor doesn't interpret some attributes from the form tag. It can be fairly short. We just need proof (by exhaustion) that we have considered the existing language.

John Boyer: So, as part of the streamlined syntax, we need to respond to a submit control and also input type="submit". That has a slightly further problem with a name conflict. I've held it as self-evident that this means that we want our type MIP to be expressible somehow on a UI control. The attribute name can't be type.

John Boyer: ...
Nick van: It's submit-without-models.
John Boyer: Can you take that on?
Nick van: Yes.
John Boyer: Can you move that action over to you?

* Explicit models as inner (nested) models of implicit model, external models with src

John Boyer: If we had scopes, it would be fairly easy using XForms actions to ferry data back and forth. I know there are alternate opinions.
Charlie Wiecha: Another approach is to extend setvalue and use s1 and s2 as sibling implied models. We need an extension either way for cross-model assignment (not constraints or calculate).
John Boyer: Doesn't that wind up with spaghetti code?
Charlie Wiecha: It would allow for assignments across models.
John Boyer: Nested models give containment.
Nick van: Don't you need to communicate from the outer model to the inner model. I think we might need to postpone this to 2.0, but the behavior now with nested models would have the outer model nested?
John Boyer: I meant the email you posted. #3 in 0013. Free communication between two models with nested containment in either direction. That's the only difference in actions talking to anything. Going back to what you said, Charlie, you have to modify actions anyway. You have to have two different models for setvalue for ref and value.
Charlie Wiecha: Unless you have a grey-box approach where you know the ids.
John Boyer: What if you contain ...

Leigh Klotz: We could have an interface section of targets for actions (setvalue is close to action with a payload). You don't have to worry about which model for the attributes-on-attributes problem for setvalue.
John Boyer: I was wrong on that.
Leigh Klotz: But it's one of the sinkholes we come close to.
Charlie Wiecha: We want to do something without re-inventing CORBA with angle brackets.
Leigh Klotz: Sounds like we want to make a mess but not too big a mess.

John Boyer: If we kept it as a separate DOM and defined an event flow (like repeats) we wouldn't have an ID conflct but we'd have a way of defining an interface that the included model exposes.
Charlie Wiecha: Then we don't care about nested vs sibling.
John Boyer: The nested model flattening made me uncomfortable because of id conflict. I like Leigh's proposal but I think we need to work it out sooner rather than later. Should I do the work or are people uncomfortable?

Leigh Klotz: What did you mean by DOM flow? DOM of the model or DOM of the inter-model instance data?
John Boyer: The latter. Rather than defining the fact that those things are pulled in, they don't have to be pulled into the same DOM.
Nick van: I see a lot of extra work, but I could be wrong .
Leigh Klotz: That's the former.
Charlie Wiecha: We need both.

Uli Lissé: I hate inner classes in Java and I don't like nested models. I think sibling classes is better. I think cross models via the id interface are better. I think we excluded cross-model communication, but with scripting you can have it anyway. I'd like to see more formal stuff. I don't think it's a good idea to have models sucked in via src created as the own DOM; the instance would them have its own DOM and it gets too complicated.
Charlie Wiecha: That's what I was saying.
Uli Lissé: I'd like to see accessing data from one model in another.
John Boyer: [irc] Instead of nested models, solve cross-model communication, possibly by defining the interface in the model
John Boyer: So the person who writes the model definition may have a greater skill set than the person consuming the skill set. It's not a big stretch to say that the person who wrote serviceDefintion1.xfmodel can write <interface>.
Steven Pemberton: [irc] has to go

Charlie Wiecha: The current src attribute on instance, what do we do with id attributes?
John Boyer: It's created as a separate DOM.
Charlie Wiecha: There's one for the running instance, but do we keep that DOM?
John Boyer: The xf:instance element has src but whatever it points at is not xf:instance.
Charlie Wiecha: So we don't keep the "source" but just the running instance copy.
John Boyer: It's similar.
Charlie Wiecha: Here we have the model declaration which has to be separated into the shadow tree.
John Boyer: Nick, you said you see extra work. It might make sense to flesh it out for the willing volunteer to see if it's extra work. To me it sounds like a not more work. The harder part is defining what model/@src means.
Nick van: I think there are a lot of roads we can take and coming to a consensus will be a lot of discussion.
John Boyer: So for 1.2 we either abandon model/@src or we have to solve the cross-model interface problem.
Nick van: The same holds for canonical forms. So it's not a streamlined thing only.
John Boyer: We are adding a lot of syntax to XForms-canonical in order to support streamlining; the question is whether this is something we need to add?
Charlie Wiecha: I see it as a great issue but not a streamlining issue.
John Boyer: OK, then we defer this and model/@src to 2.0. I like it but I can live without it.
Nick van: I like it but we are already late.
John Boyer: Sounds like a resolution: model/@src is XForms 2.0.
Nick van: [irc] +1
Uli Lissé: I don't object but I'd love to see it in 1.2.
John Boyer: Can you live with it?
Uli Lissé: I'd like to drop nested models but not @src.
John Boyer: If we solve the @src problem in 1.2 we'd have to solve the interface problem.
Uli Lissé: I don't object to the resolution.
John Boyer: Any objections?

Resolution 2008-05-14.1: Defer model/@src to XForms 2.0 and we solve the cross-model interface problem there too.

John Boyer: The related issue is, what happens if someone puts a model inside a form tag? Does it take over the model?
Nick van: Take over, merge with implicit model, or two separate models.
John Boyer: That's the homework assignment for the week. Nick, can you start that on the list?

* IRC Log


* Meeting Ends