Erik Bruchez, Orbeon
John Boyer, IBM (Chair)
Kenneth Sklander, Picoforms
Leigh Klotz, Xerox (minutes)
Steven Pemeberton CWI/W3C
Charlie Wiecha, IBM
Nick van den Bleeken, Inventive Designers
Mark Birbeck, WebBackplane
http://lists.w3.org/Archives/Public/public-forms/2009May/0011.html
John Boyer: Since it's fully
virtual, how should we schedule it?
Charlie Wiecha: I liked the rolling
idea.
John Boyer: How about those in Europe?
Originally it was a Virtual Day on June 4th, then June 8th-10th
together. Virtual days are really only 5 hours. So do we do 3 or 4
virtual days?
Steven Pemeberton: It's hard to stay
on the phone that long.
John Boyer: Doing three virtual days
in a row doesn't help. I think Erik responded about the 6AM Pacific
Time issue as well.
John Boyer: If we did these every
week, how does that play against the telecon?
Steven Pemeberton: In XHTML2, we use
one hour of the telecon for the small issues, and use FtF time for
one focus (issue or specification).
John Boyer: How are people's times on
Wednesdays after this call? It's not great for me, as I couldn't do
the full length, but ... do we want to have the weekly call
Wednesdays and FtF on Thursday?
Charlie Wiecha: I would say
Friday.
Steven Pemeberton: That's a joke,
right? It would be evening here. Monday is out. TWR is OK for me,
with some clashes, but not Friday.
John Boyer: So Thursday?
Steven Pemeberton: Works for me. What
time would you start
John Boyer: 1400-1600 UTC, then an
hour break, then 1700-1900 UTC.
Steven Pemeberton: That would work
well with me.
Leigh Klotz: For how many days?
John Boyer: If we wanted the same
number of hours, we'd have to do six of those. We'lve lose people
in vacations. So June 4th, 11th, 18th, 25th, and July 2nd.
John Boyer: Or we could do 5 hours,
1300UTC (6AM PDT), June 4th through July 2nd, giving us the same
days.
Charlie Wiecha: Or go later an hour
rather than early.
Steven Pemeberton: The original
proposal goes to 9PM so this would be 10PM.
Charlie Wiecha: Would people prefer
the later option?
John Boyer: Can you live with it,
Steven?
Steven Pemeberton: Sure.
John Boyer: So June 4th, 11th, 18th,
25th and July 2nd, 1400-1600 UTC, then an hour break, then
1700-2000 UTC.
Steven Pemeberton: We decided for the
18th for an XHTML FtF, so I couldn't participate.
John Boyer: If we put off the
18th...
Leigh Klotz: Steven's probably not the
only person who will miss one, and he'll probably be available on
IRC anyway.
Steven Pemeberton: Right.
John Boyer: So we'll have a regular
Wednesday call then FtF days on Thursdays.
Resolution 2009-05-20.1: Virtual FtF days for 2009: June 4th, 11th, 18th, 25th and July 2nd; 1400-1600 UTC, then an hour break, then 1700-2000 UTC.
John Boyer: Next, question, do we
need a registration page?
Leigh Klotz: Isn't there usually a
vacation registration page?
John Boyer: For July and August, but
not June. So we could extend it.
Leigh Klotz: It's probably a better
match to use the vacation page.
Steven Pemeberton: Good point.
John Boyer: So on Wednesday we can
have an agenda planned.
Steven Pemeberton: I get an action
item to create the form?
Action 2009-05-20.1: Steven Pemeberton to create vacation form for June, July and August, which will double as virtual F2F regrets page.
http://www.w3.org/2002/09/wbs/32219/formsabsence2009/John Boyer: I'd like to get to PR
soon. Nick and Uli are away this week. I'm not sure if there are
actions for them or me.
Erik Bruchez: I don't think so.
Charlie Wiecha: No.
John Boyer: I changed the target
dispatch attributes. The dispatch action also had a target child
element. I understood the action to rename the child element as
well. I updated the schema and the specification. The word target
appears in a lot of places (event targeting).
John Boyer: I thought we could look at
the test suite, as we don't have Nick, but I did a quick search but
there are 40 affected tests and about half a dozen are submission
related. The other 30 something are dispatch. All need to be
changed to use targetid instead of target.
John Boyer: How do we test the
backward compatibility with the old name target?
Charlie Wiecha: Do we want everybody
to update the implementations before we come out? It seems a simple
syntactic issue.
John Boyer: So don't modify the tests,
but just create new tests.
Charlie Wiecha: I meant are we going
to ask EMC, for example, to redo their test report?
Steven Pemeberton: I thought we
deprecated and added new, so we can leave the tests as they are. So
it's OK to use the old ones.
John Boyer: I wrote the spec as using
the new names, and a piece of normative text, processors MAY
support attribute or element name "target" ignored if "targetref"
or "targetid" appears.
Charlie Wiecha: Then we just need that
test.
John Boyer: When we say MAY we need
only one implementation.
John Boyer: The implementation report
proves implementability; the spelling doesn't change that.
Leigh Klotz: Or change the test suite
and say that the implementations passed it with the old
spelling.
John Boyer: That's preferable. And if
they don't support the older spelling in later releases, I don't
want the test suite to fail them.
Leigh Klotz: I'd be happy with just a
note from the vendors saying when they've changed the
spelling.
John Boyer: And it's not the highest
priority that we put the optional backward-compat test in
anyway.
Steven Pemeberton: I agree, it's not
the highest priority.
John Boyer: So if I just changed the
existing test and created zero no new test, that would be OK for
now.
Charlie Wiecha: They'd start to fail
but it's a trivial change.
John Boyer: They'd have to run the
test again to fail, but if they do it's pretty trivial to fix
it.
Leigh Klotz: I'd say just send a note
to the vendors saying that we've changed the spelling.
John Boyer: I think we don't have to
wait for them to respond to go forward. How about just sending it
to www-forms? OK?
Charlie Wiecha: OK
Action 2009-05-20.2: John Boyer to make target change to targetid or targetref in XForms 1.1 test suite and send a note about the spelling change to www-forms. We aren't expecting updated implementation reports.
John Boyer: The remaining actions on my plate aren't conformance-level changes, so we should be ready for PR in a few weeks.
John Boyer: We've talked about two
tracks, 1.2 and 2.0. 1.2 would use the existing framework and
include things already approved (data-driven switch, for example)
to plug homes or make it easier to deal with document-centric
applications of XForms in ODF. But ODF doesn't use the XForms UI
elements. However, we're discussing it with them. Context-attribute
everywhere is another example of lower-hanging fruit. By
comparison, some of the XForms 2.0 items have been larger, more
fundamental shifts of the processing model, such dynamic
dependencies or amalgamating the recalculate and revalidate steps.
There's grey space in the middle.
John Boyer: So what are the interests
of current and prospective WG members.
Steven Pemeberton: I have suggestions
for ease-of-use. I don't want to mention them all here, but I'd
like to have just one copy of the model and many forms; a sort of
data sheet.
John Boyer: Definitely.
http://lists.w3.org/Archives/Public/public-forms/2009May/0036.html
John Boyer: That sounds like
low-hanging fruit, model/@src.
Steven Pemeberton: There are ID
linkages, and those don't work across documents.
John Boyer: I'd assumed it would be
brought it as part of a document.
Steven Pemeberton: The IDs aren't
exposed in the body of the form, only in the form. So we could
change some datatypes. It's not trivial, but I think it's
soluble.
John Boyer: Another authoring one
is why someone might want to use the same model across multiple
documents, with several pages doing incremental collection. One
problem is that we have a lot of machinery around restricting
submissions based on failure to meet constraints, and required
MIPs. If you have several pages working together, you have to
submit to get from one page to the next, and there will be unmet
constraints. It's like we have to be able to distinguish
Leigh Klotz: states.
John Boyer: Or classes of
constraints.
Leigh Klotz: It sounds like
constraints in states, SCXML.
Charlie Wiecha: Or sub-models, with
constraints in the sub-models.
John Boyer: I don't think model/@src
gets us where we need to be. We need to solve sub-models as well.
Can we bundle those together? Is that 1.2 or 2.0? Or is that
distinction something to defer?
Steven Pemeberton: It could be fun
to ask for future version features again in the group.
John Boyer: We've always had an open
door...
Steven Pemeberton: But making it a new
agenda item.
Charlie Wiecha: And we also have an
opportunity to XForms in HTML5 or HTML6. There are some issues
there. This may turn more into Ubiquity and other AJAX libraries
(JSON support, event models, DOM consistency), and not necessarily
related to HTML5. The MVC pattern for AJAX will happen with or
without us.
John Boyer: And xinclude?
Leigh Klotz: For model inclusion, but
Steven and you had another idea.
Erik Bruchez: We use it on a daily
basis and it works.
Leigh Klotz: Sub-models and
encapsulation give a higher level of abstraction, but as Erik
points out xinclude works and people don't need our permission to
use it, but because of the IDS it breaks encapsulation.
Erik Bruchez: We could take time to
look at it.
John Boyer: And rich text content?
Is that a mediatype?
Erik Bruchez: Yes, we use text/html.
The drawback is that we store the HTML as text content. People ask
why that is and why we can't edit XHTML.
John Boyer: So the larger issue is
that our so-called atomic controls operate on strings seem to have
use cases where they are bound to some kind of tree.
Erik Bruchez: We lifted the
restriction in xf:copy. It might be good to do this for a rich-text
editor.
Steven Pemeberton: This was one of the
issues on my list as well. I expressed it as repeat over mixed
content.
John Boyer: It has been useful to have
restrictions on ref. So perhaps a different attribute, for the
rebuild-recalculate?
Steven Pemeberton: We often assume we
know the type.
Leigh Klotz: Imagine a
textarea/@incremental bound to mixed content; that would produce a
rebuild on every character.
John Boyer: Authors would learn not to
do that.
Leigh Klotz: But they will want it
immediately; our first textarea example was an SMS counter.
John Boyer: So you'd need finer
control over rebuild.
John Boyer: And the next would be
dialogs.
Leigh Klotz: Like xxf:dialog from
Orbeon. And as Charlie would point out, the AJAX libraries are rich
with ways to display and style pop-in and grey-in dialogs, but we
don't have a good syntax for expressing the intent
declaratively.
John Boyer: So all we have to do is
handle the event flow. When you press the OK button you get your
message to come back up; the event handler fires on any event in
the bubble phase. Does XML Events 2 fix that? There's no target
phase and it's not the default?
Steven Pemeberton: I think it fixes it
in your sense of the word. XML Events is a binding to something
that already exists, so we can't specify new behavior. We can't
change the defaults because it's DOM Events.
Leigh Klotz: It may be that we trigger
dialog differently, as it's more of a switch with the rest of the
document.
John Boyer: So it's a binding to DOM
Events 3?
Steven Pemeberton: DOM Events 3 never
happened so we went back to DOM Events 2.
John Boyer: Can't you set your own
default for your own?
Leigh Klotz: How can you have a "you"
and a "they"? There's one DOM shared by DOM events and XML
Events.
Steven Pemeberton: We pretend the
target phase by making the implementation look. But target would be
a very bad default. Almost always you have these things (an
onclick) on an element. If that "a" has an "em" inside it you won't
hear it. The default is well-chosen.
John Boyer: Within mixed content. In
XForms I don't care about it.
Steven Pemeberton: That's why target
is part of the bubble phase. If you put it on the target that's all
you get anyway.
John Boyer: If I have a
trigger/message/trigger then the inner one bubbles up. That's why
we need a different mechanism, such as a document-level switch, as
Leigh said.
Steven Pemeberton: In your use case,
you cancel the event, having dealt with it. We have an attribute
for that.
Leigh Klotz: stoppropagation.
John Boyer: So the author would write
stoppropagation on every element inside a message. That's
particularly for content reuse.
Steven Pemeberton: I have to go.
John Boyer: Next week, future
features.
Steven Pemeberton: So start posting
them?