W3C Forms teleconference January 26, 2011

* Present

Alain Couthures, AgenceXML
Erik Bruchez, Orbeon
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Philip Fennel, MarkLogic
Steven Pemberton, CWI/W3C
John Boyer, IBM
Kurt Cagle, LOC
Dan McCreary, Dan McCreary & Associates [Joined Late]

* Agenda


* Previous Minutes


* Action Items and Tracker


Steven Pemberton: I've worked on the out-of-date actions. John's action item is not confused anymore.
John Boyer: I deleted or closed duplicates.



Leigh Klotz: It's semi-official policy that they're doing a rolling-release.
Steven Pemberton: I don't think we need to do anything about this.

* XForms 1.1 errata

Steven Pemberton: They're fixed in the 1.1 Wiki version.
John Boyer: For the first it's in the errata. I'll check the second.
John Boyer: Both are done.

* XBL2

http://lists.w3.org/Archives/Public/public-forms/2011Jan/0030.html http://lists.w3.org/Archives/Public/public-forms/2011Jan/0031.html

Steven Pemberton: Leigh, any comments?
Leigh Klotz: Maybe Erik will say something when he joins.
Steven Pemberton: Should I raise this at HCG?
Leigh Klotz: When Erik joins we can come to consensus, and then I think that would be appropriate.
Kurt Cagle: With the move away from namespaces, is it worth talking about the dual-path effort?
Steven Pemberton: It might well be worth suggesting. It should be clear that we're asking for a namespaced version.
Erik Bruchez: [joins]
Kurt Cagle: HTBL
Leigh Klotz: I suggested WebBL to Art Barstow.
Kurt Cagle: I've talked to Sam Ruby about joining the WG. Maintaining parallel tracks may be important.
Steven Pemberton: The more we talk about this, I think we should surface it at the HCG for a future agenda item. That may lead to inviting others.
Leigh Klotz: Parallel development may lead to too much and too little overlap. I'd like to see XBL in the desktop browser for the implementation (like Mozilla XForms and Ubiquity) and then a namespace addition for use with our own implementation on top of that for macros.

* Form Control Labels


Kurt Cagle: I don't see any reason not to go down that path. There are some implementations that already do that. Separating the labels out seems obvious in retrospect. Does it break the model in any way? I haven't seen anything that would.

Leigh Klotz: What about a label outside a repeat? Maybe we just don't allow it.
Nick van: It's quite natural to put labels outside a repeat.
Leigh Klotz: So perhaps the label is relevant if any of the matched controls are relevant.
Erik Bruchez: Maybe you can have them always relevant.
Kurt Cagle: If there's no data it wouldn't display.
Nick van: If you take the label out of the input, and put the input inside the table, and the label outside, how do you make the table non-relevant? Wouldn't part be non-relevant?
Leigh Klotz: It would be the column non-relevant.
Erik Bruchez: I could see it either way: relevance is tied to the list of concrete controls, and the table scenario is almost screaming for some way. (Empty table with headers, or no data - no table). If you have labels relevant when there are no concrete controls, it's a scenario we don't have in XForms 1.1. By nesting we get non-relevance of labels, but this would be the first time we have something that's separate from the related control.
Leigh Klotz: We could put ref on the label to bind to the data.
John Boyer: Label is part of a metadata cluster, and isn't independently existing. Relevance doesn't apply to label, help, hint, alert. So I think that the only way that label gets its permission to be seen or not is through the form control it's associated with. The repeat has an interesting case because we're saying we'd like to overlay the labels of the repeat as a column header. There's a point where we need a form control.
Kurt Cagle: I've thought that for a while.
Erik Bruchez: We call that L/H/H/A. That's true in the current spec, but when we implement label separate from controls, we allow them anywhere (before or after the control). Labels can be in non-relevant controls while the control is outside the group, so it's not just a property or associated data for the control. As soon as you have to implement that as a separate entity, you have to break some of those assumptions. I'm not sure it's blocking us from saying how labels pointing inside repeats behave.
John Boyer: So at toplevel, make it a form control?
Erik Bruchez: When you implement it you kind of have to look at it that way.
John Boyer: So we're saying it duck-types to a form control. If relevance applies to it, all the things that apply to other form controls, it's not different from an output, but it's also a label for something else, for screenreaders.
Kurt Cagle: A label would have a for attribute.
Steven Pemberton: Listening to this, I've got some slight misgivings. First, this is the first time we've made a decision about a forms document for presentational reasons. It's because the styling languages we have available, at least CSS, don't let us style the way we want to. We want to position a label elsewhere and we want to mess around with the document structure so the document looks a bit better. First that gives me misgivings because you can style for different modes and devices; we've seen some very good examples of that, for example a speech interface, with exactly the same form. So I'd like to address the use-case instead of the solution. I understand that label/@for in HTML does presentation in the document, even though strictly speaking that's not one of our aims. I'd much rather try to find what we're trying to do in a more presentation-oriented way.
Erik Bruchez: That's very idealistic.
Steven Pemberton: Sure it is, but that doesn't mean we can't try and do it.
Erik Bruchez: This is an obvious solution, though there may be others. We have markup on the page. CSS can move things around a little bit. With XSLT in 1998-1999, that was going to be the web styling language, then it became split into two very different things. XSLT lets you shuffle elements. With CSS we don't have the capability to shuffle elements on a page in a way that's as flexible as that. In our implementation, this was one of our first extensions, because we couldn't see how to solve the problem in another way. I'm a little skeptical.
John Boyer: We have a great ideal, but also a practical problem in terms of how people are designing forms, whether we like it or not. Because they don't have the mechanisms the way they need from us, they leave the input/label blank and then use output/label to position the labels where they want them.
Steven Pemberton: I quite understand that there's a use case. I'm not saying we shouldn't search for a solution, and this HTML solution is an obvious one. But if we had one that's more xforms-like, I'd have less misgivings.
John Boyer: From an A11Y standpoint it's a really bad idea that the label is blank. We're trying to fix that. Our design environment adds styling of the label to suppress it, then creates a second label, and points to the other label. So rather than having a label that says I'm for something else, we have the dependency going somewhere else.
Steven Pemberton: Yep.
John Boyer: An output which gets its content from the presentation layer.
Kurt Cagle: I've been putting together an XForms-esque application for internal use. One problem I run into with form controls is that there are two fundamental structures I run into: tables and property sheets. Property sheets are lists of items, atomic values in most cases. The challenge I have with labels in the form component is that, even from CSS, it's remarkably difficult to do something that should be easy. You can do funky things with floats. It's non trivial. On the second point...
John Boyer: Let's consider the first point. Instead of label/@for, use an output as a column header with value from an XForms label element in a form control in the repeat, the output is a separate form control whose relevance is governed by different rules and whose value comes from another place in the document. Then inside the repeat, the form control's labels should be hidden from view.
Kurt Cagle: I don't see it as a bad solution, but it has problems. First you are binding a control to a label, and this would go back to the control having a value separate from the model. It sets an interesting precedent.
John Boyer: You already have it with label with static content.
Erik Bruchez: And output that has a value.
Kurt Cagle: Also, it may end up introducing a level of complexity; the more you have to de-reference the more you have teach complexity. If you have outputs that reference label values, that's another point you have to teach. I'm not saying it's bad (structurally it's elegant), but for users it's an eyebrow-raiser.
Steven Pemberton: Who just joined?

Dan McCreary: I am a big XForms advocate and I have a few wikibooks out there.
Steven Pemberton: And you coined the term XRX?
Dan McCreary: Yes.
Steven Pemberton: We're glad you could join us.

Kurt Cagle: This is sufficiently pressing that we should document the approaches. If we can make the arguments pro and con and look that would be good. I'd be willing to do that.
Steven Pemberton: I'd like to ask people to document the use cases. The only real place where I come against it is with repeats. If there are other obvious use cases...
Erik Bruchez: In our implementation, we don't handle the repeat as the use case has been presented; they must be in the same repeated container. I find the idea as Kurt mentioned of dealing with repeats something to consider. The most pressing issue is layout; repeat is a second one.
Steven Pemberton: You're saying that there are use cases different from repeat, examples you can't do. I've personally never had that problem. I'd like to know about them to so I can use that to evaluate potential solutions. Just send them in.
Kurt Cagle: Where do we write this up? 1.2?
Leigh Klotz: Or just start as email.

Action 2011-01-26.1: Kurt Cagle to write use cases and pro and con of various approaches for separate label binding.

Action 2011-01-26.2: Erik Bruchez to write use cases for non-repeat separate label binding.

* BetterForm News

Nick van: Betterforms is Lars and Joern.
Leigh Klotz: Are they doing the same as Erik's AVT?
Nick van: They are.
Steven Pemberton: Could you do it?
Alain Couthures: It's not that easy because binding are attached to elements, not attributes.
Steven Pemberton: I could imagine some level problems with XSLT.
Alain Couthures: It's not.
Nick van: I also have XSLT that generates an XForms document, but double curly brackets are XForms time and single are XSLT time.
Dan McCreary: I use the same thing.
Steven Pemberton: If I were using Alain's implementation I wouldn't be using XSLT. Leigh. Yes, your document is the input document.
Steven Pemberton: We could all look at this.
Leigh Klotz: This may provide a second implementation of many XForms 1.2 features we could fast-track onto the Wiki.

John Boyer: If we have AVT in controls people may try to do this in other places like nodeset or calculate.
Nick van: These are on host-language attributes such as class.
John Boyer: How do we have that available in XForms? We could suggest it.
Erik Bruchez: There's enough interest but not in the XForms spec. Quite a few implementations do HTML and we could have that.
John Boyer: We have CSS pseudo-elements and pseudo-classes so there is a place. There are real challenges in doing AVT in XForms. If we're talking about host languages, that surely makes things a lot easier. The circular referencing potential and data lifecycle problems don't occur.
Erik Bruchez: I don't agree it's challenging. Everywhere we have a static value that's not an XPath expression or ID, you can put an AVT. I don't see any problem in our implementation.
John Boyer: It may be that you're not doing a recalculation engine, such as calculate or relevant.
Erik Bruchez: Right. The use case for AVTs provides a solution for dynamic values where previously you couldn't have one. So we don't do it where there are XPath expressions (ref, nodeset, value, context, etc). Where you need an AVT is for submission/@action, headers, etc. We have an exhaustive list. If you limit the use of AVT to those sets, you can, in one sentence, say wherever there is a static value you can use an AVT.
John Boyer: There's a teachability issue; there are places where you can't use an AVT.
Erik Bruchez: If you try to use an AVT to produce an XPath expression you're already in trouble. It's doable, but the main use case for AVT outside the host language is to make the language lighter than we did in XForms 1.1 with child elements. The world wants more short syntax and we have to be, as a WG, aware of that. Anything we can do is good.
Nick van: It makes the code more readable, eliminating child, concat, quotes, escaped, etc. It gets messy. AVT makes life easier.
John Boyer: I don't know why it's any different in the child element vs. the avt.
Nick van: You have to use static and dynamic parts and concat. For every change you need quotes. It gets complicated.
John Boyer: OK, that makes sense.

Steven Pemberton: As for your control over the host language issue, I've been thinking of another heresy where we can have XForms documents without switching namespaces. We could provide a ready host language for the case of very many simple documents we already have.
Nick van: What's the advantage over XHTML?
Steven Pemberton: Maybe we're ok, but maybe it's a heresy.
Leigh Klotz: I think we already have a host language, XHTML+XForms, and we're slated to write it up. If we want to put in AVT as an optional feature there then we should.
Kurt Cagle: It would be difficult to do something that isn't XHTML. Maybe we could move namespaces. In order to be able to stay on the parallel track, we have to move with the language. Those namespaces may have to get incorporated back into the XHTML namespace.
Leigh Klotz: Kurt do you think they're going to eliminate XSLT support?
Kurt Cagle: Michael Kay is pushing to make sure they don't.
Leigh Klotz: I see XSLT PI, XBL PI, for macros, then namespaces disappear and it turns into browser DOM HTML or XHTML, and in-browser XBL works there.
John Boyer: That puts us out of range of mobile phones.
Leigh Klotz: Mobile phones have 1GHz processors. And remember we dillied about XPath because the mobile phone members said they'd never do IEEE floating point, and then Java ME came along and they all did it.
Steven Pemberton: Let's stop there.

Steven Pemberton: Next week, XPath 2.0?
John Boyer: I won't be here.

* IRC Minutes


* Meeting Ends