Erik Bruchez, Orbeon
John Boyer, IBM
Leigh Klotz, Xerox (minutes)
Mark Birbeck, Web Backplane [irc]
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair)
Charlie Wiecha, IBM
Philip Fennell, MarkLogic
Steven Pemberton: Welcome Philip
Fennel. Please introduce yourself.
Philip Fennell: I work for MarkLogic
in the UK. I do a lot of consulting with customers XML, XSLT,
XQuery, and XProc work and am engaged in XForms work. I've been
previously at the BBC and HP Labs in Bristol, where I worked on
XForms for Java and SWT. I live in the southeast of England.
Steven Pemberton: Welcome. This is the
tail-end of the "previous" working group and we're currently going
through re-chartering.
Steven Pemberton: I believe we got a good response. The management team has an agenda item to consider the issue today. When the new charter kicks in, I think everyone has to re-join.
John Boyer: On contact with the new
group, should we wait for the announcement?
Steven Pemberton: It's easiest to
point to the announcement but you can certain get contact
going.
John Boyer: At the last meeting we
resolved to ask implementors to try out features in their XForms
1.1 processors. Should we encourage trying out other features, from
the F2F meeting? One is multiple model-item properties. Is there
any harm in that? It seems like it's in the same category of
"nothing that previously worked would stop working."
Steven Pemberton: Right. In fact, I
suspect that many implementations already work with multiple
bindings. I've seen some of my forms which do work this way
already.
John Boyer: I suspect so.
Steven Pemberton: It sounds like a
good plan. Do you want to take the action to post a message
encourage?
Resolution 2010-04-7.1: Forms WG encourages XForms 1.1 implementers to provide early experimental adoption of "multiple MIP" resolution appearing in http://www.w3.org/2010/03/25-forms-minutes.html#res_multimip
Action 2010-04-7.1: John Boyer to post messages encouraging to experiment with allowing multiple bindings for the same MIP, as described in the MIP resolution: http://www.w3.org/2010/03/25-forms-minutes.html#res_multimip
Steven Pemberton: Any
comments?
John Boyer: We should come to a
conclusion.
Steven Pemberton: If we declare it,
and SVG has to declare it too, then there would be different
definitions.
Charlie Wiecha: Does it bubble and
capture the same way?
Steven Pemberton: Yes. I can't answer
right now whether it has the same other properties.
Charlie Wiecha: click is odd for
VoiceXML, but there may be additional issues if there are
differences in semantics.
Steven Pemberton: It's unfortunate for
form compatibility.
John Boyer: Older processors will work
fine; it's only new versions of languages such as XForms n+1. We
could use a version attribute.
Steven Pemberton: Doesn't that allow
some forms processors to stop working?
John Boyer: Demand will push whether
backward-compatibility gets implemented, or whether it would be
easier to fix the forms. It's a Darwinian decision mechanism. The
reverse issue is, from the DOM perspective, if they have click and
it's required across web browsers (which is all they care about)
and then DOMActivate is optional to implement. If someone
implements the optional components, what are they going to
do?
Steven Pemberton: The spec does define
what happens.
John Boyer: So if they have both, do
they dispatch both?
Steven Pemberton: That is right, but
it depends to what degree you optimize; if nobody has registered
for an event you don't have to dispatch it. Bubble and capture work
that way as well.
John Boyer: So implementations
wouldn't be penalized.
Steven Pemberton: Not if they do it
right.
John Boyer: Then I don't see a problem
with optional. Aside from web browsers, there are other places that
need it. I thought Charlie noted there were some limitations on
where click could go.
Charlie Wiecha: That's what I am
asking.
John Boyer: Is it any benefit to
XForms if DOM 3 lists DOMActivate as optional, if none of the web
browsers implement it? What does it gain us?
Steven Pemberton: It gains backward
compatibility; you don't have to re-write forms. Not everybody has
control over forms. If you load someone else's forms, you can't
change them.
John Boyer: And what do we get from
having it defined in DOM3? Permission to use it?
Steven Pemberton: Yes, and hopefully
it will be implemented in the future as well.
John Boyer: We have a significant
investment as a company with using DOMActivate outside HTML in our
product. Our tools use it, and we've trained our users, our
consultants, and developing our design tools. We'd have to spend a
significant amount of money to change it.
Steven Pemberton: Good
statement.
Charlie Wiecha: We need to resolve if
there are any semantic differences, and whether click can be used
only in certain locations.
Steven Pemberton: I'll read the spec
for that; someone else should as well.
Action 2010-04-7.2: Steven Pemberton to read http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMActivate and report back on semantic differences and whether click can be used only in certain locations.
John Boyer: Our discussion of UI
state got us to the point of seeing that there was a difference
between absent nodes and non-relevant nodes. That was an important
distinction we haven't properly made before. We tried to make
things absent but zombie-like. We also discussed switch, and there
were a number of use cases for non-selected cases with variations.
The use cases sounded like minimal, compact, and full behaviors of
select1, which is somewhat analogous. It seemed like a minimal
behavior is like non-selected cases being absent, that compact was
like non-selected cases still being non-relevant but somehow more
available, and full appearance like using switch for a wizard where
the non-selected cases contain controls that aren't shown but might
still participate in validity eventing (i.e. fully live but styled
display:none). For example, a tabbed switch might show the case
labels of non-selected cases. We might be able to describe those
cases using appearances.
Leigh Klotz: Chiba used
switch/@appearance as early as 2003 and the same for repeat. So we
might see if any processors already use @appearance before we start
deciding it.
Steven Pemberton: Did you mean repeat
or switch, John?
John Boyer: I was talking about
switch.
Steven Pemberton: I like use cases for
repeat such as labels.
Leigh Klotz: repeat appearance has
been used for tables, omitting header rows, etc.
Nick van: I've never used it.
John Boyer: It could have become
common practice, such as select/@appearance=minimal
not doing radio buttons. Of course, we should see what others are
doing already. We could have recommended practice rather than
optional, so that mobile devices could do different things.
Steven Pemberton: So, minimal clearly
has only the current case being visible. I like the idea of compact
being tabbed, or was it full?
John Boyer: I think that a switch
currently shows you one case full of things; but there seem to be
three things. The compact one is what we're doing now, where the
cases are non-relevant, but we have language that talks about what
you can do with non-relevant things. A lot of people aren't too
happy with that behavior. It would be nicer if the non-selected
cases were completely absent. So how do we encode the behavior of
being absent.
Steven Pemberton: Now I understand;
you mean "absent" as we meant at the F2F.
John Boyer: Sometimes we want absent;
sometimes we want non-relevant. And sometimes we want non-selected
cases to receive events and participate in the lifecycle (be alive
and well, so to speak), and just stylistically cause display:none.
So you would have the flexibility to style as a multi-tab
switch.
Leigh Klotz: I don't dispute the use
cases, but I don't like having the @appearance control
behavior.
John Boyer: I started to think about
that; is it really that difference from appearance on a
select1?
Erik Bruchez: I think so far,
appearance is purely presentational and wouldn't impact events or
other internal state. It would be considered an important
change.
Steven Pemberton: Yes, in the past was
CSS for example.
John Boyer: So maybe we need a
different attribute.
Steven Pemberton: So these different
versions are available in tthe markup.
John Boyer: We could experiment with
this in XForms 1.1
Leigh Klotz: Orbeon uses foreign
attributes for experimentation.
Erik Bruchez: We use an extension
attribute that controls the switch behavior. It's a boolean for
xforms-11-switch. It's not very fancy.
John Boyer: Certainly, appearance full
is about being fully live and styled. It's not strictly styling.
It's saying how should the switch behave.
Leigh Klotz: Do you think you'd come
up with more than three if you weren't fitting it to
appearance?
John Boyer: Some people want
multi-select switch, but I think that's a different issue.
Steven Pemberton: That should be
possible with model-based switching.
John Boyer: We're talking about a
data-based version of the switch element. It would select all the
ones that are listed.
Steven Pemberton: It's an interesting
suggestion, which I now understand. I personally would like to
think a little bit longer about it.
John Boyer: The only two hard things
are avoiding bugs in concurrent programs and naming. I can't think
of a fourth case. minimal, compact, and full as value names seem
pretty good, though compact is a bit suspicious.
Steven Pemberton: It is more about
behavior than appearance. Let's think about it a little longer.
Leigh Klotz: I think Charlie is
nearly done with the model/@src feature, but I had some questions
about whether it was useful enough. At the F2F we talked about some
use cases John mentioned. John, do you have any progress on the use
cases for the designer tool?
John Boyer: Not yet.
Steven Pemberton: Next week,
then?
John Boyer: Sure.