Steven Pemberton, CWI/W3C
Nick van den Bleeken, Inventive Designers
Leigh Klotz, Xerox
Uli Lissé, DreamLabs
Erik Bruchez, Orbeon
Charlie Wiecha, IBM
Daylight Savings Time change in US
Steven Pemberton: So four or five people there and two remotely.
Nick van: Is Innovimax jouining?
http://www.w3.org/2002/09/wbs/33280/forms2010/results
Steven Pemberton: He's one of the
organizers of XML Prague.
Nick van: I will review action items for next week.
Test 10.8.e
http://lists.w3.org/Archives/Public/public-forms/2010Mar/0004.html
Charlie Wiecha: If there are no
comments we can just check it back in. Would people still like the
alert? This way is easier to test with Selenium.
Steven Pemberton: No, this is an
excellent way of doing it.
Charlie Wiecha: So someone needs to
check it in. I'll contact John.
Leigh Klotz: Is 10.8.f done?
Charlie Wiecha: Yes, that's
done.
Steven Pemberton: http://lists.w3.org/Archives/Public/public-forms/2010Feb/0022
Charlie Wiecha: I'll work with John to
get that one checked in too.
Steven Pemberton: So you're saying
the name is already not enough.
Erik Bruchez: Yes, with @bind on a
control, it's clear that the element already has to know whether it
is @ref or @nodeset. An implementor can already decide whether to
consume a single binding or a nodeset binding. If we have only one
attribute, that has other benefits; it's confusing to use the funny
name @nodeset on bind.
Steven Pemberton: That's quite a
convincing argument. If we took an existing XForm and applied the
change so that ref meant nodeset but in certain cases it would be a
single node, would that change the behavior of any existing
forms?
Erik Bruchez: ref isn't allowed where
nodeset is.
Steven Pemberton: If we deprecated
nodeset and applied the semantics, is there any place where an
existing xform wouldn't work?
Erik Bruchez: I don't see any except
if an implementation already supported @ref and already the
single-node rule via generic code. It might be that such an
implementation would handle repeat/@ref differently; but as a new
feature, implementors would have to implement the new behavior.
We'd have to ask implementors; it might not be a problem.
Erik Bruchez: We could enable it only
for XForms 1.2.
Steven Pemberton: If it doesn't break
existing content...
Charlie Wiecha: I can imagine
implementations that decide to send value-change events based on
the presence of a ref attribute; if you use that on a repeat you'd
get events based on the first node.
Steven Pemberton: Erik's suggestion is
that that doesn't happen.
Charlie Wiecha: It may be fortuitous
that it doesn't happen by virtue of implementors choices.
Steven Pemberton: I'm assuming you're
applying MIP events only if the first node is used.
Erik Bruchez: It depends on how we
introduce the change; we were thinking of a better way of
explaining how and when MIP events are dispatched. This is only an
issue with repeat, not itemset and bind.
Charlie Wiecha: If we're embedded in
ODF or Dojo, the model processor wouldn't be able to make those
decision.
Steven Pemberton: Mark Birbeck has
said we should have xhtml:p/@ref.
Charlie Wiecha: Same for me. The model
processor doesn't know about the Dojo widgets.
Erik Bruchez: How do you fix bind?
It's broken.
Charlie Wiecha: Yes. But I'm not sure
that adding @ref is the fix instead of looking at bind. Is there a
way for a model processor to make this determination?
Erik Bruchez: If you need two
attributes then bind would be deprecated; bind-nodeset and
bind-ref.
Leigh Klotz: If you need two
attributes, John suggested a second one which controls the
behavior, defaulted for xforms controls.
Erik Bruchez: I don't see what the
benefits are; for authors can just use one attribute, @ref, and we
don't have to revisit bind.
Charlie Wiecha: It works great for
xforms controls but it buys us orthogonality.
Erik Bruchez: A control has some kind
of runtime; I don't know about p/@ref. It isn't going to be a major
feature of XForms. I've never had the problem. I use xf:output. If
it's a real control, something that integrates with Dojo, that's a
real use case, but it has to have some kind of implementation
(JavaScript, you name it) for init, reading data, writing data, and
so on. In that case the control can make the decision about single
node or nodeset. That's my point. There's no need for external
knowledge.
Charlie Wiecha: That's the question;
is there any need at the external level. The real case with ODF is
xforms without having to define internal APIs. Is there a need at a
markup level to have this clarified?
Erik Bruchez: That's the exact
question. So far I don't see the need; even if there was a need in
some cases, I'd rather go for the simplicity and making life
simpler for authors instead of implementors.
Steven Pemberton: I absolutely agree
with that sentiment, but we should try to anticipate the problems
that Charlie is talking about, because those elements might be
future XForms elements, and ODF integration is a good example; we
should try to cover all use cases.
Nick van: It's only for value-changed
we don't want for complex content. You already get readonly. For
complex content in the future you want value-changed.
Erik Bruchez: You need the control to
know about the content. That's an argument for the control knowing,
not external.
Erik Bruchez: One thing we had in
XForms 1.1 is that all MIP and value-changed events are determined
through the marking algorithm. I think that's broken. This proposal
is for the control to determine when the value has changed, looking
at its previous value. Same for readonly-readwrite, to dispatch its
own events. The form author sees the controls, not the
implementation. I see only benefits for the control to read its
bindings and decide when to dispatch.
Steven Pemberton: I keep swapping between the two. First you see it one way, then the other. I'm definitely a supporter of using ref everywhere.
Erik Bruchez: ..
Steven Pemberton: Why not just use [1]
if you want to bind to the first instead of using a single
node.
Erik Bruchez: ...
Steven Pemberton: OK for bind. But do
you want the nodeset delivered or is it ambiguous.
Nick van: Where would it be
ambiguous?
Steven Pemberton: Only on elements in
other namespaces.
Erik Bruchez: I'm looking for a
concrete example. If you add your own controls, you have to specify
how the controls consume bindings. That's no problem. If it's a
repeating control, it consumes a nodeset. Otherwise, just a first
node. Is it that it doesn't look as declarative? I don't see the
philosophical difference.
Steven Pemberton: Maybe you're right;
as you said, bind has this problem already. So we have ref and bind
that work the same way. You don't have to say anything special
about bind.
Erik Bruchez: I don't think that's a
problem. If I have xforms:input/@ref="..." with a 1000 nodes. XPath
expressions in Saxon are iterators; so if you consume one item,
just iterate once.
Leigh Klotz: What about using
select, as we heard from Mikko Honkala early on.
Steven Pemberton: I'm not sure what
changing the name would be.
Leigh Klotz: We're talking about
changing the name.
Steven Pemberton: I would propose that
we make ref and nodeset still work everywhere. So I would be
reluctant to change it, in order to keep compatibility of at all
possible. If we were starting from zero, I'd say we should consider
it, but we now have forms, so I'm not in favor of changing
select.
Charlie Wiecha: It's not the name
issue; it's single vs multiple binding and whether we want the
control in charge.
Steven Pemberton: I'm not sure we
should make a resolution until we have more people. But I'd like to
take a straw poll. Is anybody opposed to adopting "ref" as the
generic word for selecting?
Leigh Klotz: We haven't discussed the
repeat attributes. Does that make a difference?
Erik Bruchez: We should change
repeat-nodeset to repeat-ref.
Nick van: Or repeat.
Charlie Wiecha: To answer your
question Steven, I'm not there yet.
Steven Pemberton: repeat-bind,
repeat-number, ...
Charlie Wiecha: I want to push more on
the idea that the form control is in charge and see if that leads
to complex content...
Erik Bruchez: We can do ref, we can
leave it as is, or we can do something else. I'd like to see the
alternative and how it works with bind. We have a pretty clear idea
of the semantic of ref in those places, but I don't see the impact
of the alternatives.
Steven Pemberton: I see another
possibility; leaving ref and nodeset as they are, and adding
select, as Leigh points out, to use select everywhere. That would
be a new behavior going forward.
Erik Bruchez: I'm not sure it would
answer Charlie's concern. The unified attribute would be the way
forward.
Nick van: [irc] If we change something
I support having ref everywhere, and another solution should be as
easy for the author as ref everywhere (or another attribute name
everywhere)
Erik Bruchez: It would be called
"select" instead of "ref" but it wouldn't address Charlie's
question.
Charlie Wiecha: I agree.
Steven Pemberton: How do you resolve
your misgivings?
Charlie Wiecha: Do we have an agenda
item for putting the control in charge? I'm concerned about the
modularity of the model and view; Erik's proposing another way of
still doing that, which is where control is more in charge than the
model. There may be implications to discuss.
Nick van: We discussed improving UI
events. In my opinion, these events aren't the ones that model uses
to communicate to the UI. The model can use its own events and the
UI can use its own events for authors.
Steven Pemberton: I've added it to the
F2F agenda.
Leigh Klotz: I've tracked down the discussions before and you can read them. We shouldn't repeat the mistakes of the past.
Charlie Wiecha: I've posted the hotels list.
Steven Pemberton: The next meeting is an hour earlier for Europeans.