W3C Forms teleconference December 9, 2009

* Present

Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Kenneth Sklander, PicoForms
Nick van den Bleeken, Inventive Designers
Leigh Klotz, Xerox (minutes)
Charlie Wiecha, IBM

* Agenda


* Previous minutes

* Improving the XForms 1.1 test suite


John Boyer: I fixed a few minor typos.
Charlie Wiecha: The 5.1.a is still todo. 5.2.1 is sent out in email.
John Boyer: It's a minor issue about qname validation, which looks for namespace prefixes. Joern contends that we need to define the namespace. We want the invalidity test to be based on syntax, not namespace validation.
Charlie Wiecha: I'll make sure it's failing for reasons other than just namespace.
John Boyer: Empty string is an invalid value as well.

* select and select1 content model

Leigh Klotz: What about the order?
John Boyer: select1 has label, list ui common +, ui common *.
John Boyer: So the hint has to come after the items. See chapter 8.
Leigh Klotz: It flagged the hint at the end as wrong.
John Boyer: So label first, but for select1, so ui common is last.
Leigh Klotz: So that content model is ordered? Do we have the same problem in model?
John Boyer: Chapter 3 for model is unordered. http://www.w3.org/TR/2009/REC-xforms-20091020/#controls http://www.w3.org/TR/2009/REC-xforms-20091020/#structure-abstract

John Boyer: Submission has (resource, method, header), * followed by action *.
Leigh Klotz: Now I understand the spec langauge for order; I'll be able to resolve these issues with the schema.

* multiple help, hint, alert

Leigh Klotz: Second, we allow any number of label, help, hint, alert.
John Boyer: We don't have label. I think it was suggested for xml:lang at one point.
Leigh Klotz: But we don't do it for label so it doesn't sound intentional.
Leigh Klotz: I remember discussing it with Roland Merrick and he pointed out it wasn't good I18N practice, so we dropped the issue.
Charlie Wiecha: Usually they're externalized.
John Boyer: I think it's because it's challenging to have help, hint, alert, and action in any order in XML Schema.
Leigh Klotz: I think it's expressible in Relax NG. Do we want to express that?
John Boyer: I think so, yes.
Leigh Klotz: So for select1 they have to come at the end.
John Boyer: We probably had some challenges. I'm not sure people care, but the spec has picked that order.
John Boyer: Do implementors have this as a restriction?
Charlie Wiecha: It seems unnecessary.

Leigh Klotz: What do we really mean about MUST conform to a non-normative schema?
John Boyer: 12.1 and 12.2 should use "is expected to" instead of MUST. We need an erratum. The first two sections are about documents that include XForms content and says that they MUST conform to the schema. That's not a testable assertion and we don't have a test for it. We then say host languages may provide additional constraints. So the use of the words MUST and SHOULD is inappropriate. We should say that host languages should assume a valid form control and valid model.
Leigh Klotz: I think this will be important for our XForms+XHTML1 document for next year. For example I don't want to prohibit model in body. The issues I see right now are with order.

John Boyer: On section 12 conformance I need to produce an erratum.

Action 2009-12-9.1: John Boyer to issue XForms 1.1 erratum to section 12.1 and 12.2 to use "expected to" instead of "MUST" and "SHOULD".

John Boyer: Generally, having label first seems good. The list ui common vs. ui common seems possibly regrettable. Is anybody enforcing that order restriction? Erik, Nick?
Leigh Klotz: Kenneth?
John Boyer: Does anybody care if hint comes before item list?
Kenneth Sklander: No, I'm indifferent.
Leigh Klotz: How about help/hint/alert intermixed with item and itemset and choices?
John Boyer: I don't think so; I think we should say they can be freely mixed. It would be an erratum.
Leigh Klotz: Is that expressible?
John Boyer: You say this-or-that* for list-ui-common and ui-common.
Nick van: That allows multiples.
John Boyer: We might roll list-ui-common into ui-common. We need a more detailed technical look. The table might just say list-ui-common. The big problem is that we wanted to guarantee at least one item or itemset, so list-ui-common+ but ui-common*. Any merge or order relaxation would still guarantee list-ui-common+.

Leigh Klotz: That's what I did; I put them all before or all after.
John Boyer: That's a better relaxation. I'd like to have label/help/hint/alert together, but I'm not sure that mixing with the items is good.
Leigh Klotz: That's what I'd prefer.
John Boyer: That's surely easier to swallow as an erratum. Processor will probably be responsive anyway. Processors aren't guaranteed with schema validity problems. For example, some Section 8 tests didn't have ref in the tests for hint. Ubiquity failed.
Leigh Klotz: I think I've got the answers I need. I'll come back with any questions about this next week.
John Boyer: Please fix the XML Schema as well.

Action 2009-12-9.2: John Boyer to issue XForms 1.1 erratum to fix select and select1 to put ui-common* before and after list-ui-common+.

John Boyer: Now onto only one help, hint, and alert.
Leigh Klotz: Did we agree to it?
John Boyer: Yes, I believe we did. Certainly from an interoperability standpoint.
Leigh Klotz: It may not be possible to express in the spec table language.
John Boyer: The spec table languge is constrained to what schema can say. The propose is normative. The table gives the minimal content model. We use prose for the rest. For example, it's not easy to give schema for a valid XPath expression.
John Boyer: Anything more than one would not behave in an interopable manner.

Action 2009-12-9.3: John Boyer to propose XForms 1.1 erratum to add language to indocate that only help, hint, and alert per form control is supported.

John Boyer: And xf:extension is awol?
Leigh Klotz: Yes.
John Boyer: I don't know why.
Leigh Klotz: Micah remvoed it. It's in UI common I think.
John Boyer: I don't see it.
Leigh Klotz: It's in there somewhere, saying to add it to UI elements.
John Boyer: I'd think any of our toplevel elements could use it. It always appears as the last child.
Kenneth Sklander: We use the extension element.
Leigh Klotz: Anywhere other than form controls.
Kenneth Sklander: Also in the model it can be anywhere for us. I was unaware of any order restrictions.

Leigh Klotz: Sounds like another issue.
John Boyer: For schema and tables.

Action 2009-12-9.4: John Boyer to propose erratum for XForms 1.1 to allow extension element in all toplevel elements.

* Chartering

John Boyer: We've amended the initial charter to include Leigh and Steven as initial co-chairs and sent it in. We're expecting some comments back.
Charlie Wiecha: Thanks.

* Improvements to UI events


John Boyer: Uli has sent regrets, but I think we understand his concerns.
John Boyer: In the November 25th meeting Nick discussed the "visited" CSS pseudoclass. This seems to affect display of invalid controls. If it's required but empty and the user hasn't gone there yet, then perhaps it can be styled differently?
Nick van: Yes.
John Boyer: I wonder how that holds up when the form controls are being managed by a switch or repeat? Are you really able to maintain a proper sense of "visited"? What happens when the user visits it, and then it's not in the selected case, and then it is again, is it visited?
Erik Bruchez: Good question. We say in XForms 1.1 that non-visible cases are non-relevant, so if you keep no state for non-visited controls, it would lose the state. There are other problems with non-visible cases being non-relevant; imagine for example a non-relevant case with a repeat and its repeat index being set. What is the user's expectation of the index being kept or reset? In our implementation, we would store the flag in the input control and we would lose the state if we followed this.
John Boyer: Yes, I've been discussing this and we found other issues with visited in controls. A repeat with a predicate for ten rows, for example; when it goes to rows 11-20, visit them all, then go back, it seems like the controls might be visited because they are optimized to share UI. So we'd have to maintain the visited information at the data layer, a MIP.
Erik Bruchez: It depends on the use case. In a master-detail form, the detail edits different pieces of information. You'd like to have it reset when closed.
John Boyer: Or, the visited information is more closely associated with the data than it is with the controls. I think the visited thing is, as Raman would put it, a red herring. We thought we could use it to detect different classes of validity states. We might have a different thing we're trying to achieve.
John Boyer: There are a few cases we're trying to achieve: invalid but empty, invalid and non-empty (visited or not), but in the empty case it's not whether the user has visited the control, but instead whether the user has tried to do some form-level controls. Once the user hits submit, it's invalid. That seems to be the trigger.
Leigh Klotz: Some wizard control might also do this, without submission.
John Boyer: It's form level vs. page level I think. That's the key.
Leigh Klotz: We have another way to express this; required=true() and then types with unioned the empty string.
John Boyer: Those still come across as invalid.

Erik Bruchez: We have a customer requirement (and our own) to indicate when you tab out when something happens, changed or not. It's a user experience question. The user will fill out a form in a given order and you don't want to overwhelm the user with error messages. Back in the days when you pressed the submit button then you would see the error. Nowadays things are more dynamic and as the user goes from field1 to field2, even without change, something happened, so it shows very clearly that it's needed. I think that's a valid use case and that's where visited came from. It would be good to have some support in XForms for it.
John Boyer: I agree. I think the notion of visited could be relaxed to the point where we don't have to go bananas with the definition, especially if we had a form-level state for showing invalid-but-empty. The visited state could be more localized.
Erik Bruchez: We use CSS; when you press submit, we set one or more CSS classes to say visited or submitted. We've tried both approaches. We still need something at the control level to show the user errors as he goes through the form.
John Boyer: If "visited" means "user has visited recently" or "some form-level operation has happened" then it seems like there are some cases where the implementation inability to remember whether the user has visited the control wouldn't matter as much. I'm concerned that at the control level only we it's hard stabilize visited, and pushing it up into the data layer as a pseudo-mip is all we can do.
Erik Bruchez: All other MIPs are re-evaluated during rebuild/recalculate; you can recreate them without state. This would be information that cannot be recreated. You have to keep it as a pseudo-annotation to the DOM.
John Boyer: That's right. When you replace an instance portion you could flip the visited flag back to unvisited for only those nodes.
Leigh Klotz: Were you saying we should have an event as well for the state change?
John Boyer: We do have an unfortunate profusion of events on state changes because we under-utilized context information; there would need to be an event.
John Boyer: Another use case would be a wizard done with a switch that shows the same data on multiple pages; it would still show the visited flag correctly.
John Boyer: This may be 1.2, and it may be an encumbrance. Maybe we don't want xforms-valid, xforms-invalid, xforms-enabled, xforms-disabled, and should take the plunge and say just that there is an update-yourself event.
Nick van: I see no harm in using these events for form authors and leaving the update event for implementors.
John Boyer: I'm trying to rationalize this with Uli's simplicity argument. Context information can tell validity, enabled, readonly, possibly visited. So only one event and depending on what you're interested in, you use @if.
Erik Bruchez: Uli was suggesting something like this, a state-change event.
Nick van: Then you need an @if on every action. We could make it easier if XML events supported listening for two events.
Leigh Klotz: I think it does.
John Boyer: I think XML Events 2 does.
Erik Bruchez: They accepted my proposal to do that. But we might become in charge of that.
John Boyer: We're getting lots of events. We have two to listen to. So we try to tone it down to xforms-enabled with context; it's really xforms-refresh.
Nick van: It's not for too many events; in many forms, I don't want events at startup, only when the node has changed.
John Boyer: No you have to capture xforms-enabled on startup for the error tracker.
Nick van: That's in one case. In all other cases, we don't capture them. That's one specific use case.
John Boyer: You said it would great to listen for multiple events. You still have to listen for xforms-enabled and invalid, and listen for xforms-invalid.
Nick van: If we make validity available in all events then we don't need a different @if.
John Boyer: ...
Nick van: The error capturing control is a rare case. The others are more common. It's a bit more code for the uncommon things, and less code for the common ones.
John Boyer: How often do you get the uncommon cases? Do people write a lot of xforms-invalid handlers, or is it for implementors? Implementors can just listen for xforms-refresh.
Nick van: For me the events are for form authors.
Leigh Klotz: I see two sides: (1) macros for common cases, and making harder things possible, and (2) keeping the same model and syntax for events so that once you learn how to do it, it always works and you don't have an inexplicable debugging problem when you miss the second event. So, Nick, why do you think that the @if case with a single event is harder to learn than a list of events?
Nick van: The invalid event is only sent when there is a change. The common event will be sent all the time. You have to add if it's invalid and if the previous value was invalid.
Leigh Klotz: So I don't think @if is the issue then; it's the cumbersome logic for detecting that there was a change.
Erik Bruchez: How do you know when to send the event anyway? It's the same problem as now.
John Boyer: We have all the same issues in the data layer already; it decides to send at the valid-to-invalid transition. At the form control, if it's rewired from a valid to an invalid node, does it get the event? Node a is invalid, node b is valid. A a result of a calculation, it changes binding to node b.
Erik Bruchez: If the control sees a change, then an event should be dispatched. We do a diff at every refresh. By the way we don't have an event for the control being rebound to a different node; if that were the case, you'd detect it.
John Boyer: It sounds like the refresh event goes from the model to the control, or at least the control decides to dispatch xforms-valid to itself.
Nick van: There should be events for form authors but those aren't the ones used in the implementation. You can do that yourself.
John Boyer: ...
Erik Bruchez: I find those events useless. It's the same code in the model. It doesn't add much to the specification. For the UI events during refresh, we already say. We don't say that the model dispatches it; it's done by code somewhere. What's important is that the events get dispatched to the control; it doesn't matter whether the model does it or the control does it.
John Boyer: I've seen extensions want to listen to xforms-refresh.
Charlie Wiecha: [irc] I'm a big believer in orthogonality...and like the single event w/context approach. Lots of folks have argued that ocmplexity comes from having to understand all th specail cases (even if they're the common ones) so not having special cases is good.

John Boyer: Tomorrow, we should step back from solving the problem to looking at the dynamism and the use cases.

* Next Meeting

John Boyer: Next meeting is tomorrow.

* IRC Minutes


* Meeting Ends