W3C Forms teleconference December 12, 2007

* Present

TV Raman, Google (briefly)
Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Joern Turner, Dreamlabs
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net (briefly)
Nick van den Bleeken, Inventive Designers
Rafael Benito, SATEC
Roger Perez, SATEC
Uli Lissé, Dreamlabs
Keith Wells, IBM

* Agenda

http://lists.w3.org/Archives/Public/public-forms/2007Dec/0017.html

* Previous Minutes

* The Forms Monthly

http://lists.w3.org/Archives/Public/public-forms/2007Dec/0016.html

John Boyer: We are still needing the new short names, but would you like to send it out with just the /xforms and /xforms11 short names?
Leigh Klotz: Sure. I'll do that.
Leigh Klotz: Lets you configure what resources can be reached from this resource, using HTTP headers and PI's
Leigh Klotz: It looks a bit weak, and will not enable mashups, because these others URI's need to specify what is allowed
Leigh Klotz: We could ask if they use XForms as a test case
Leigh Klotz: I want some input from implementers, bcz I'm not a real expert on this
Leigh Klotz: They are moving forward fast, so the time to respond is limited
Leigh Klotz: the problem is that the client checks the security, no tickets, tokens, so it is weak
John Boyer: how can they increase their security
Leigh Klotz: I don't want to comment on this, it seems that this is what they want to solve
Leigh Klotz: XForms implementations should check if they could implement it and give feedback
Leigh Klotz: explains how it works
Leigh Klotz: before a POST you do a get to check security
John Boyer: what if the server doesn't implement the GET
Leigh Klotz: then you can not access this resource
John Boyer: do they only check if you try to cross a domain boundary
Leigh Klotz: yes indeed
John Boyer: If we implement it we should do a GET before a POST
John Boyer: So we need to consider it in a future version in the submission model
Leigh Klotz: we need ensure that if it is done, we can incorporate it
John Boyer: Do you want to post your e-mail
Leigh Klotz: I want an implementer to look at it
Leigh Klotz: I think MarkB or Aaron should look at it
John Boyer: We could ask Aaron to join a future call
Leigh Klotz: I will send a response and say that we are working on it
John Boyer: Would you cross post it to www-forms

Action 2007-12-12.1: Leigh Klotz to post updated message on access-control to comments list, and indicate that we continue to study the isssue. http://lists.w3.org/Archives/Public/public-forms/2007Dec/0012.html

* Triage of future features

John Boyer: The main theme is glass authoring and there are a number of steps we need to achieve it (model-free, etc.) But for now before we get started on discussion of technical details, who is available to write down these technical details?
Nick van: I can do some work in it but I think we first need a requirements document, or something like that, then go for the details.
John Boyer: Our XForms 1.1 requirements document was detailed, but we already have a functional requirement to simplify glass-to-data forms authoring. There are specific things we've come up with which we believe answer that requirement; those specific things are the level at which our past requirements documents have been written. We do need a requirements document, but the section header and bullet points would be detailed requirements, with one paragraph each of rough properties, not full spec'd out. Is that a reasonable model for proceeeding?
Nick van: If we do something high-level it could be done for the next F2F.
John Boyer: The XForms 1.1 requirements, http://www.w3.org/TR/xforms-11-req/ went to from "improve client-server interaction" to a solution (SOAP). For the second one, we went from one base requirement on submission improvement to three specific recommendations, but those recommendations were brief. The level of discussion of these features we're discussing now is at that level: for example, "make the model optional."
Nick van: So we don't need to know them before we write the requirements document.
John Boyer: True. Focusing on the requirements... It's not going to take long to produce the document once we decide which things to produce in the documents. Someone could start working on the technical details then. Nick, are you thinking of pulling together the 1.2 requirements document?
Nick van: I can try to write some detail about the points in there now and we can try to discuss which goes where.
John Boyer: In some cases we'd have a paragraph describing what's going wrong and then the requirements statement would be to fix that.

John Boyer: Are there any concerns about having the glass-to-data issues in XForms 1.2: optional model, MIPS on UI controls, submission without model, instance without model.
Nick van: I'm not sure we need instance without model, as I commented, because of default values. In my opinion, the SOAP submission is the only thing that isn't fixed, but that's for advanced users; we might want to solve the SOAP submission problem separately.
John Boyer: I wonder if it makes sense to put an instance element inside a submission. If our intent is to get the instances to contain the request and response SOAP envelopes, then putting them inside the instance would make sense. Something you could throw in your document and have it more or less work. Then action handlers to put the data in and out.
Leigh Klotz: That sounds like XAC.
Nick van: Or higher-level actions, a simple SOAP call with simple arguments. It's still quite difficult to make the SOAP envelope.
Leigh Klotz: When people do SOAP in programming languages, they use tools do to it. It's already fairly easy for document style but not RPC style, so perhaps some XSLT or something to let people do RPC-style SOAP in XForms.
John Boyer: So maybe allowing SOAP submissions to occur with an implicit instance is the issue. We still want the implicit instance but we don't want to lose web services in the meantime.
John Boyer: Number five on the list is default values on UI controls. Even our current way of doing default values in the model is a bit of a hack. It's easy in HTML, but we don't have the corresponding capability.
Leigh Klotz: At the UI layer. We have it at the data layer.
John Boyer: We're talking about only a UI layer version, so the default value issue needs to be included.
Leigh Klotz: If we step back and take out model, what breaks? I think events break. But events are broken already. Josef Dietl and I proposed it as an implementation and expository technique but it isn't satisfactory.
John Boyer: ...
Erik Bruchez: We discussed a related issue at the Madrid F2F. The UI events don't cover the use cases. The decision was to consider this as an issue. One way of solving it would be a new architecture for UI events.
Leigh Klotz: Yes, both model-based events and UI events need to be looked at. Let's just add events the list of 5 things that we're looking at for XForms 1.2.
John Boyer: We have a model that the XForms model pushes out the information based on the recalculation engine; that's seems to be a part of the problem.
Leigh Klotz: Josef and I proposed using events as a spec and implementation technology for the processor, as a parallel to the UI events, but I think the experiment hasn't worked, and if we're removing model we should look at removing this.
John Boyer: This sounds like a conversation that's going somewhere positive. Can we flesh out a bit more of the details about what would actually change?
Leigh Klotz: I'd like to have something like "simplify and provide use cases for UI events and model events" on the list of five things for XForms 1.2.

Resolution 2007-12-12.1: We add something like "simplify and provide use cases for UI events and model events" on the list of five things for XForms 1.2.

* Next week

John Boyer: Try to take your own pass through this week and contribute to getting us further along. We do have a meeting next week.

* IRC Log

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

* Meeting Ends