Erik Bruchez, Orbeon
John Boyer, IBM (chair)
Kenneth Sklander, PicoForms
Nick van den Bleeken, Inventive Designers
Leigh Klotz, Xerox (minutes)
Charlie Wiecha, IBM
http://lists.w3.org/Archives/Public/public-forms/2009Dec/0003.html
John Boyer: I fixed a few minor
typos.
Charlie Wiecha: The 5.1.a and 5.2.1
issues are still todo.
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.
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.
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.
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.
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.
John Boyer: Tomorrow, we should step back from solving the problem to looking at the dynamism and the use cases.
John Boyer: Next meeting is tomorrow.