W3C Forms teleconference April 23, 2008

* Present

Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Leigh Klotz, Xerox (minutes)
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Keith Wells, IBM
Nick van den Bleeken, Inventive Designers

* Agenda


* Previous minutes

* XForms Support in ODF

John Boyer: ODF has XForms support, but some of it is spotty, such as the lack of repeat and the support for model item properties on UI bindings. I'm hoping to file "last call" comments on ODF 1.2.

* Upcoming telecons

John Boyer: I can't make the May 7 telecon chair.
Steven Pemberton: Nor can I, as I am at XTech.
John Boyer: Can someone else serve as chair?
Nick van: [irc] I am available so I can try.
John Boyer: I can provide the agenda for you.

* Action Item List:


John Boyer: There's no need to consolidate Mark Birbeck's action items; just mark them all done when he does them. I'd like to encourage everyone to get through one thing done.

* Typo in xforms-submit-done


Action 2008-04-23.1: John Boye to address Typo in xforms-submit-done http://lists.w3.org/Archives/Public/public-forms/2008Apr/0088.html

* Question about dependency system


Nick van: The problem is that is with a couple of binds and predicates that select some of those nodes. I don't think it can be done according to the spec. If you have a dependency on ../item[] then you have a dependency on all the items.
John Boyer: That is correct; we say that, yes. If I understand correctly, using a,b,c for id; which of these binds breaks?
Nick van: All of them because they all have a nodeset item with @id=something and the calculate uses other items with other ids.
John Boyer: Then just the first one is unable to work?
Nick van: Yes because there is another bind that does a calculate based on an item.
John Boyer: If you just looked at the first one by itself?
Nick van: I think it would be a circular dependency.
John Boyer: So you're saying the nodeset identifies a particular item, but along the way the predicates are winnowing down to a particular item in both cases, but the expressions are dependent on all the items, including the one identified by the nodeset. We take out self-references automatically.
Nick van: That will work. But if you have two binds?
John Boyer: Your second bind binds without a calculate so there is no problem. I see; on the third bind down, the reference list lists all the items, not just 4, 5, and 6. So the third bind b-23 is dependent on a set of things that includes b-21, which depends by b-23. So we don't know which order to run those two calculates in.
Nick van: My assumption was that it depends on all the item elements.
John Boyer: http://www.w3.org/TR/xforms11/#expr-dependencies A node is selected by matching an XPath node-test or a function call. A node-test includes the name-test. ... So we claim in rigorous terms that the reference list produced by this calculate will include all the items, not just the ones that match the predicate. I think we were in Madrid when we talked about specifying this more fully in the spec. I think my prior understanding had been that you had to match both the node test and the predicate, but the group majority wanted to be on node-test only.
Nick van: I remember that but I don't recall what we resolved then.
John Boyer: We say it is referenced even if a filter subsequently excludes it. For better or worse, we are now clear on the subject.
Nick van: I'm not sure why.
John Boyer: http://www.w3.org/TR/xforms11/#expr-dependencies
John Boyer: http://www.w3.org/TR/xpath#NT-NodeTest
John Boyer: http://www.w3.org/TR/xpath#NT-Step
Steven Pemberton: link to example?
John Boyer: http://www.w3.org/TR/xforms11/#expr-dependencies
John Boyer: So, Nick, can you take an action to explain why a node is considered to be matched when it passes the node test and not just the predicate is matched for bind?
Leigh Klotz: Isn't is to allow the bind to match a different node if the predicate condition changes, such as if you setvalue @id in one of these examples?
John Boyer: Yes, that must be it.
Erik Bruchez: I think it's time for someone to write a new article about dependencies.
John Boyer: Do we still need the action item or is that good enough?
Nick van: I'm comfortable. I can write a note to explain it.
John Boyer: I think it would be useful.
Nick van: minutes madrid: http://www.w3.org/2007/09/12-forms-minutes.html, http://www.w3.org/2007/09/12-forms-minutes.html, http://www.w3.org/2007/09/12-forms-minutes.html,

Action 2008-04-23.2: Nick van den Bleeken to propose note to for http://www.w3.org/TR/xforms11/#expr-dependencies to explain rationale for bind causing dependencies on node-test and predicate conditions.

* Is this the only comment on XML Base 2e?


John Boyer: Is anyone reviewing this?
Steven Pemberton: I am for XHTML2, by June 30th.
John Boyer: I think Nick should file his comment independently. Steven will you look at with an eye towards XForms submission.
Steven Pemberton: Yes, any URIs that might be in XHTML2 or XForms.

* Forms Task Force


John Boyer: We need to keep the conversation going here.
Nick van: I want to respond but I need to coordinate with Mark on elements and attributes.
John Boyer: I think the disagreement is whether a core XForms processor should respond to the HTML brand of syntax. In the tag soup example, no, but if you had well-formed XML, would we expect an XForms processor to do that? Maybe RFC-2119 with May or Should instead of Must. Or it may lie in a module, which an XForms processor May or Should support. Factoring out that concern, I think it's relevant that if a fieldset used a name attribute, it might be something we'd be suggesting as allowing that fieldset to participate in the XForms processing model as if it were a group.
Nick van: We didn't discuss WebForms 2.0 proposal. Do we need to support those elements?
John Boyer: Part of the issue there is that at the broader architectural level, one of the principles I was trying to get across is that all of the efforts to improve HTML going forward should adopt the principle that features that people would like to have that are already expressed in a prior recommendation of the W3C, that those prior recommendations should take priority on how to make that feature. An XForms way of doing that feature should take priority over the ideas that are expressed in Web Forms 2.0 over repetition. As dog food, there is our taking a step in a module in XForms or Core XForms such as fieldset and the form tag, because they have precedence from HTML4. Otherwise, there is a proliferation of different ways of trying to express the same idea and trying to wire them all into one processing model becomes more difficult.
Nick van: ...
John Boyer: We should ask how Web Forms 2.0 tables and repetition map into a recognized data layer, with their syntax?

* Form tag, implied model

http://lists.w3.org/Archives/Public/public-forms/2008Apr/0064.html http://lists.w3.org/Archives/Public/public-forms/2008Apr/0069.html

John Boyer: What happens when the user wants to take the next step with XForms; we are trying to create an onramp. The first step seems to be the full-streamlined syntax with only UI controls and attributes. What's the next step? Do we want form authors to be able to express their own instance data? binds? There's a precedent expressed by HTML, with the form tag. It seems to be a useful container. We don't have a single container that is one UI and one set of form controls.
Leigh Klotz: I was hoping some of the recursive composition stuff that Charlie was doing would be out for us to explore.
Nick van: You can't have a wrapping element for your model if you have them separate for the UI.
Steven Pemberton: [irc] I don't see the need for wrapping controls quite honestly
Nick van: Interleaved in the markup
Steven Pemberton: [irc] Yes, a mashup or similar
John Boyer: How would you make a form as a component?
Leigh Klotz: Isn't that was the RAC stuff was?
John Boyer: XAC. It's more complicated.
Leigh Klotz: It's hard to evaluate without knowing what XAC solves.
John Boyer: Their work is about saying what to do with the net results of that component.
Leigh Klotz: Raman and I proposed a string language of defcomponent and component, and it got thrown out as being too hard to describe, very early on. I don't think that we can just say that a form tag works without saying how it works.
John Boyer: Portal software does it already. We don't have to say how. It's useful anyway.
Nick van: That can be done by markup. Why do we need it?
John Boyer: Our language?
Nick van: The host language.
John Boyer: That bothers me; for the sake of a single tag, we don't have completeness.
Nick van: There was a last-call comment that we needed a wrapping element and we decided we didn't.
John Boyer: Not for XForms 1.1. But XForms 1.2 is for appealing to existing web authors.
Nick van: What's easier than just dropping the element?
John Boyer: When you try to use our technology in a web application context with two portals, how do you conveniently say that all these things are in the portlet on the left and all of these things are in the portlet on the right.
Leigh Klotz: You just want something for scoping?
John Boyer: Easy scoping. It's like aspect orientation. You have a cross-cutting concern that you have to go into every control and add the model.
Nick van: You have the same problem with bind ids.
Erik Bruchez: The portals have this same problem. They prefix every single id in forms to avoid conflict. They say use an API to get a portlet prefix for the ids. If you use JSP, you have to do it everywhere.

Erik Bruchez: There are multiple strategies for translating XForms to HTML4, but that seems irrelevant. From the form authors perspective, do you want a form element for grouping?
Nick van: If they want to submit to multiple places, they can put the submission on their submit component instead of using JavaScript.
John Boyer: Or new attributes like XForms submission, directly on their submit. That should imply a particular XForms submissions as well.
Nick van: Or non-HTML authors who want to override XForms submission attributes on the submit control?
John Boyer: Absolutely. It's like the calculate attribute, in core XForms. There seem to be lots of cases where we're elaborating attributes instead of using elements. It's the same idea in the case of the form tag, though inside out. It turns out there are very few things we have to add to the InfoSet level. What we're really trying to distinguish is which of the web-author streamlined syntax measures do we really want to incorporate into XForms, and which do we want to be only available to web authors.
Nick van: In my opinion, only the ones that add functionality to the people who don't know HTML4.
John Boyer: So let's get rid of the spelling "form" for a minute. What if the model tag could be a container, not just binds and instances and submissions but also the UI to present it. Might that be useful? You could have it a separate file and refer to it.
Nick van: A form without a host language would be useful for us.
John Boyer: The host language could pull in the whole bucket all at the same time.
Leigh Klotz: Don't you mean just a minimal host language that borrows from HTML4 forms and gives you styling from HTML?
John Boyer: No, not a minimal host language. I could use it in XFDL.
Erik Bruchez: We use a minimal host language in our mobile stuff.
John Boyer: Why can't you have a model in the body of HTML? As you start to get into components that's going to happen to us. Modulo the model issue, if we want to incrementally introduce elements of XForms to web authors, how are they going to create the association between their UI controls and those extra elements? bind?
Nick van: Or write "model".
John Boyer: Does that model then take over for the implied model of the UI controls?
Nick van: It is the same issue with an instance.

Erik Bruchez: We use models to group functionality. We don't have a mapping between a model and controls.
John Boyer: The form tag may be like a fieldset, a module for HTML authors that maps that form tag onto the XForms InfoSet so that HTML4 authors can get access to XForms functionality. Or maybe we don't have to translate it. We can continue this thread on the list: what ends up in Core XForms and what is part of an HTML profile? Maybe all we need is an HTML profile and calling it XForms 1.2 is the wrong answer.
Nick van: XForms 1.2 is also making form authoring easier for non-HTML authors.
John Boyer: Perhaps. We need to figure out which things in the HTML profile are useful for all authors, starting from the HTML author and working out. As you point out, how many attributes from input are actually useful?

* IRC Minutes


* Meeting Ends