W3C Forms teleconference March 3, 2010

* Present

Leigh Klotz, Xerox (minutes)
Steven Pemberton, CWI/W3C (Chair)
Charlie Wiecha, IBM
Uli Lissé, Dreamlabs
Erik Bruchez, Orbeon
John Boyer, IBM

* Agenda


* Next FtF

Next F2F in Boston in conjunction with AC Meeting, March 24-26, 2010 http://www.w3.org/MarkUp/Forms/wiki/FtF_2010_03_24_Agenda

Steven Pemberton: John and Uli aren't, Charlie and Leigh are? Erik?
Uli Lissé: Remote except for the 25th.
Steven Pemberton: And Nick.

Charlie Wiecha: Do we need a hotel list still? The Sonesta?
Steven Pemberton: I'll give you a couple.

Steven Pemberton: Please add to the agenda at the wiki.

* Rechartering


Steven Pemberton: We still need to get votes out.

* XForms 1.1 and XHTML+XForms1.1 XSD Schemas

http://lists.w3.org/Archives/Public/www-forms-editor/2009Nov/0003.html http://lists.w3.org/Archives/Public/www-archive/2010Mar/0007.html Owen Newnan has handed off his work (LINK TBD)

Leigh Klotz: He's got two attachments, an Eclipse project for validation, and a document describing technical issues with XSD, integration issues, and XForms issues.
Steven Pemberton: The RTF document says that the zip file contains other issues, and it has a list of changes.

Action 2010-03-3.1: Leigh Klotz to investigate Owen Newnan schema issues and report to list. http://lists.w3.org/Archives/Public/www-forms-editor/2009Nov/0003.html http://lists.w3.org/Archives/Public/www-forms-editor/2009Nov/0003.html

Leigh Klotz: We can move to the XForms 1.1 RNG issues now that this is done.

* XHTML+XForms 1.1 RelaxNG Schema

http://lists.w3.org/Archives/Public/public-forms/2010Jan/0019.html http://lists.w3.org/Archives/Public/public-forms/2010Jan/0037.html Question from Erik is, "do we really want to enforce that the label is first?"

Steven Pemberton: It really is so in the spec.
Leigh Klotz: Yes.
Steven Pemberton: So perhaps we ought to keep it that way because processors might do require it. I think validation for 1.1 should require the label.
John Boyer: We do have an action item for intermixing item, itemset, and action items in select and select1. We agreed to that erratum even though it is a change of schema because we found nobody enforced that ordering.
Steven Pemberton: That reflects reality; it's fair enough.
John Boyer: I can't say about the label for all processors.
Erik Bruchez: In general, unless there is a good reason, we shouldn't specify an order. It's hard for authors to remember; for an implementor, it's trivial to handle any order.
Steven Pemberton: I could imagine a problem with CSS which doesn't support re-ordering elements. If an implementation uses CSS it can't put the label before the content. So CSS expects the elements to be in the order they're to be displayed.
Erik Bruchez: That would argue in favor of the author choosing the order.
John Boyer: I don't see how this relates; the label in relation to what? It's inside the thing; it's child order.
Steven Pemberton: True, but the itemset could be before the label and I could imagine an implementation having trouble unless it re-orders the elements internally.
Erik Bruchez: If the implementation uses that order or uses a visual representation of the markup; I don't know how Firefox or Ubiquity does it, but we don't use the order of the elements; we do a transformation. We generate HTML4 markup independently.
Steven Pemberton: If you parse and then process you'll have less trouble than if you parse and process simultaneously. I guess Ubiquity already has the DOM. That might be OK. I could imagine situations where the implementation has a problem. I think it is a bit much for 1.1. We should wait for 1.2.
Erik Bruchez: We also have hint, alert, itemset; what happens with them? As far as the positioning, it's not clear to me what happens. These tell the control what to do and it does its work. In the case of items, it seems the styling issue wouldn't be directly relevant. For hint, help, and alert as well, I could imagine people have different ways for handling those. We can ask native client implementors, but I think it would still be better to not impose a specific order.
Steven Pemberton: OK. I agree, but not for 1.1. I think that a 1.1 validator should require the label to the label to be first because that's what the spec says, but we can make the change in the future.
Erik Bruchez: Do we have a way to keep track of these kinds of things?
Steven Pemberton: Track changes?
Erik Bruchez: When we think more discussion is needed. Use the wiki?
Steven Pemberton: There is a trackbot issue system? It's independent of actions.
Erik Bruchez: If it's hard to use I'd rather use the wiki.
Steven Pemberton: I'm perfectly happy to do that.

Action 2010-03-3.2: Steven Pemberton to investigate trackbot issue tracking system, for comparison to wiki.

Erik Bruchez: I think the action list could go to the wiki as well.

Steven Pemberton: Here's the issues. http://www.w3.org/2005/06/tracker/xforms/actions/1
Leigh Klotz: It's read protected; it should probably be write-protected.
Steven Pemberton: I closed my action. http://www.w3.org/2005/06/tracker/xforms/actions/608
Erik Bruchez: I'm not convinced yet; this tool is a little funny. It has 572 spam issues. We should agree on a place for tracking important things. Actions there as well would be great. I'm not sure the tracker is the best solution. I'm not sure we want to decide now.
Steven Pemberton: There's no rush. We'll have to clear out the tracker if we're going to use it. It has two advantages: we can update it on the fly during calls using IRC, and everybody can make changes. The trackbot follows our mailing list, so if you say "ACTION 608" it will link to it. So it has some advantages. I'll look into that more.
Leigh Klotz: So then you want to re-open your action?

Resolution 2010-03-3.1: For validation and schemas, we keep label first in controls as it's so specified in the XForms 1.1 Recommendation.

John Boyer: It's not just labels.
Steven Pemberton: We should generalize it.
John Boyer: There's probably not a good reason to impose an order anywhere.

Resolution 2010-03-3.2: We plan to investigate relaxing ordering constraints for labels and other elements in XForms 1.2.

Steven Pemberton: Action item?
Steven Pemberton: Let's leave it as that for a minute.

Erik Bruchez: For the remaining items on RNG?
Leigh Klotz: There are two agenda items. This one is done, but the general "Comments on XForm 1.1" is done.

* XForms 1.1 Test Suite issues

Charlie Wiecha: 10.8.f is done. 10.8.e I will send mail about.
Charlie Wiecha: I've re-written it to be automated with Selenium, for example.
Leigh Klotz: Is it checked in?
Charlie Wiecha: No, I'll send mail first and then we'll discuss it.

* xforms:bind and @ref


Erik Bruchez: I believe we discussed this in the past; people want xf:bind to address one node and they assume they can use a ref attribute.
Steven Pemberton: This did get raised a long time ago, by Roland Merrick. I think he said we didn't need both. I don't think there's anywhere you would get confused by having a ref instead of a nodeset; please correct me if I'm wrong. It says ref or nodeset depending on what we expect (single or multiple). We made that explicit. Roland Merrick asked why not just call them all ref.
Leigh Klotz: Originally they were all ref and we changed them.
Steven Pemberton: Raman was opposd to it. But we may say that ref and nodeset are the same thing and that you can use one or the other.
John Boyer: Except that they mean two different things.
Steven Pemberton: They do, but is there ever a place where that matters?
John Boyer: The first-node rule is imposed by ref; nodeset gives you multiple nodes. There are lots of places where multiple nodes doesn't make sense, and ref automatically picks the first one.
Erik Bruchez: You could move that logic into the consumer. Input could be the place that applies the rule.
John Boyer: There was a feeling that the referencing mechanism might be loosely coupled to its consumers. If you consider global attribute versions, xf:ref.
Erik Bruchez: Imagine bind with a large nodeset, and then you use input/@bind. It's inconsistent. The nodeset attribute is problematic with XPath 2.0; if you accept bind, (repeat and itemset), then you don't have to restrict it to a nodeset there. We can repeat over atomic values. It's a sequence, not a nodeset. The nodeset attribute for repeat and itemset would become a misnomer; so would a ref, by the way. We might need some new attribute names.
Steven Pemberton: We could say that it would just work; repeat/@ref would produce a nodeset.
John Boyer: In addition to the first node rule, @ref imparts the UI life cycle and the MIP properties. So if ref points to multiple nodes, what happens?
Erik Bruchez: The first-node rule works.
John Boyer: repeat/@ref gives binding to multiple nodes.
Erik Bruchez: We're trying to change that with UI events.
John Boyer: UI Events yes, but not MIPs.
Erik Bruchez: How does that work with @nodeset.
John Boyer: It doesn't as @nodeset doesn't impart UI Events or MIPs.
Erik Bruchez: I don't see that as hard to change; it creates virtual groups.
John Boyer: That's different than the repeat element itself receiving that information.
Erik Bruchez: It would be slightly different. The repeat container element doesn't have a clear notion of relevance.
Charlie Wiecha: Rather than having that knowledge pushed back to the element, that knowledge is cleanly carried by the attribute. We can describe it in the attribute. We would no longer have a way to do that.
John Boyer: We could have @ref and @reftype and default @reftype. That helps the nodeset naming problem.
Erik Bruchez: Authors want to type the smallest possible markup.
John Boyer: We can automatically default it on our namespace.
Erik Bruchez: What's the extra attribute for?
John Boyer: For overriding it; either you get control with an attribute or you don't have control. Right now we have two names: @nodeset (multiple, no MIPs, no UI events), ref (single, MIPs, UI Events)
Steven Pemberton: We assigned that magic to the name of the attribute rather than the context. We could say the magic happens because of the context, and not the attribute.
Leigh Klotz: The argument is for xf:@ref (foreign namespace).
Steven Pemberton: Well, so if we allow bind/@ref then newbies will say that bind only binds to the first node.
Erik Bruchez: I don't see why we can't just using @ref. I can modify my implementation to support @ref everywhere and not change anything. I don't see the concrete problem.
John Boyer: It wouldn't be a correct implementation. Would you make it all work? The UI eventing and MIPs?
Erik Bruchez: Absolutely.
John Boyer: For xf:repeat/@ref="/my/items" which MIPs do you apply to the xf:repeat element.
Erik Bruchez: I'm not because I'll apply it to the virtual groups that do the node binding.
John Boyer: So you're saying xf:repeat/@ref wouldn't apply MIPs to repeat.
Erik Bruchez: No, we can in the future change it so that @ref doesn't do that. How far would the behavior be from what we have now? I don't see major obstacles, if we agreed that for authoring it would be a good solution, and more XPath 2.0 friendly, it would be good. I don't care that much about whether xf:repeat itself receives readonly events. In my implementation it's not going to, and if the spec says it should, we can reword it slightly.
John Boyer: I guess we're saying there is a difference but we need to fully understand it.
Charlie Wiecha: Yes.
Erik Bruchez: @nodeset is used only in bind, repeat, and itemset. We need to examine these anyway.
Leigh Klotz: I think the original proposal was to use @nodes on repeat.
Charlie Wiecha: Back from history...the orthogonality is on the attributes now, and we'll have to move that orthogonality to the context now. That may mean introducing new attributes such as bind type.
John Boyer: Then people could choose the binding type only on foreign elements, and we could default it to UI bindings.
Erik Bruchez: Let's say you're using XBL to implement a control. You could use foobar/@ref and I don't see a problem. It could be repeat-like or it could be input-like. We couldn't say that the @ref was interpreted by the xforms engine on the foobar element anyway. It was done internally by the XBL component. It could decide it internally.
John Boyer: Yes. More so, because @ref an and @nodeset are used on setvalue and insert. We do have this problem already because @nodeset on an insert is different from @nodeset on repeat. So we have this problem already.
Erik Bruchez: I agree. There were issues raised on repeat and setvalue. I believe the attributes are badly named: there is a fundamental difference between input with ref or nodeset, and an action needing a source for data. It doesn't have the same meaning.
John Boyer: It was for similarity: setvalue/@ref and input/@ref; insert/@nodeset and repeat/@nodeset. But it's not the same kind of binding. We handle it with definitions only; those definitions say that we've picked the right default value for a binding-type identifier.
Erik Bruchez: We have ref-vs-nodeset in bind, the discrepancy in actions, and the XPath 2.0 conflicts (select, sequence?). Don't we have enough attributes already?
John Boyer: I get it, but right now we have two attributes @ref and @nodeset. We already have the problem that we're not properly indicating the bind type. We can go to @ref and then have @reftype articulated; still two attributes, but we don't have to use defaulting and definitions.
Erik Bruchez: Would you add @reftype?
John Boyer: We could add it and default it so that people almost never have to write it and it would be the same.
Leigh Klotz: So they have to write in their integration specs what the default is?
John Boyer: Yes. And we could say that by default it is UI binding.
Erik Bruchez: It seems like extra stuff to have an attribute./
Steven Pemberton: It seems like it's only for the case where the context doesn't impart the information. The rare case where you use xf:@ref as a global attribute that you need to determine which you were using.
Erik Bruchez: It would be better if there were only one.
Steven Pemberton: There's not, there's one element, and many elements.
John Boyer: And also the MIP attachment issue.
Erik Bruchez: Practically speaking, if it were a sequence of items in XPath 2.0, then an input control would accept a single-node binding defined by behavior.
Steven Pemberton: You're repeating what I said earlier, that we move the magic into the elements. @ref gives a nodeset but I take the first one.
John Boyer: The lowest common denominator is that it just returns the nodeset and then we add a different attribute to hold the other behaviors.
Steven Pemberton: I think Erik is saying we do that in the control itself and add the extra stuff there.
Erik Bruchez: For MIPs, in most implementations, when I get a node, it's node annotations. As long as the control gets the nodes, it will get them and it is free to use them. Same as with PSVI for Schema. So MIPs are available to the consumer.
John Boyer: I think you're for additional attributes to control it.
Erik Bruchez: I'm arguing against it..
John Boyer: PSVI defaults attributes.
Erik Bruchez: At runtime the control gets its bindings. I'm not talking about validation, but the instance.
Charlie Wiecha: How do you prevent an action from getting MIP events?
Steven Pemberton: Anyone want to write this up? If not, I'll do it.

Action 2010-03-3.3: Steven Pemberton to summarize @ref @nodeset @reftype discussion.

* IRC Minutes


* Meeting Ends