Leigh Klotz, Xerox (minutes)
Steven Pemberton, CWI/W3C (Chair)
Charlie Wiecha, IBM
Uli Lissé, Dreamlabs
Erik Bruchez, Orbeon
John Boyer, IBM
Steven Pemberton: John and Uli
aren't, Charlie and Leigh are? Erik?
Uli Lissé: Remote except for
the 25th.
Steven Pemberton: And Nick.
Charlie Wiecha: Do we need a hotel
list still? The Sonesta?
Steven Pemberton: I'll give you a
couple.
Steven Pemberton: Please add to the agenda at the wiki.
Steven Pemberton: We still need to get votes out.
Leigh Klotz: He's got two
attachments, an Eclipse project for validation, and a document
describing technical issues with XSD, integration issues, and
XForms issues.
Steven Pemberton: The RTF document
says that the zip file contains other issues, and it has a list of
changes.
Action 2010-03-3.1: Leigh Klotz to investigate Owen Newnan schema issues and report to list. http://lists.w3.org/Archives/Public/www-forms-editor/2009Nov/0003.html http://lists.w3.org/Archives/Public/www-forms-editor/2009Nov/0003.html
Leigh Klotz: We can move to the XForms 1.1 RNG issues now that this is done.
Steven Pemberton: It really is so
in the spec.
Leigh Klotz: Yes.
Steven Pemberton: So perhaps we ought
to keep it that way because processors might do require it. I think
validation for 1.1 should require the label.
John Boyer: We do have an action item
for intermixing item, itemset, and action items in select and
select1. We agreed to that erratum even though it is a change of
schema because we found nobody enforced that ordering.
Steven Pemberton: That reflects
reality; it's fair enough.
John Boyer: I can't say about the
label for all processors.
Erik Bruchez: In general, unless there
is a good reason, we shouldn't specify an order. It's hard for
authors to remember; for an implementor, it's trivial to handle any
order.
Steven Pemberton: I could imagine a
problem with CSS which doesn't support re-ordering elements. If an
implementation uses CSS it can't put the label before the content.
So CSS expects the elements to be in the order they're to be
displayed.
Erik Bruchez: That would argue in
favor of the author choosing the order.
John Boyer: I don't see how this
relates; the label in relation to what? It's inside the thing; it's
child order.
Steven Pemberton: True, but the
itemset could be before the label and I could imagine an
implementation having trouble unless it re-orders the elements
internally.
Erik Bruchez: If the implementation
uses that order or uses a visual representation of the markup; I
don't know how Firefox or Ubiquity does it, but we don't use the
order of the elements; we do a transformation. We generate HTML4
markup independently.
Steven Pemberton: If you parse and
then process you'll have less trouble than if you parse and process
simultaneously. I guess Ubiquity already has the DOM. That might be
OK. I could imagine situations where the implementation has a
problem. I think it is a bit much for 1.1. We should wait for
1.2.
Erik Bruchez: We also have hint,
alert, itemset; what happens with them? As far as the positioning,
it's not clear to me what happens. These tell the control what to
do and it does its work. In the case of items, it seems the styling
issue wouldn't be directly relevant. For hint, help, and alert as
well, I could imagine people have different ways for handling
those. We can ask native client implementors, but I think it would
still be better to not impose a specific order.
Steven Pemberton: OK. I agree, but not
for 1.1. I think that a 1.1 validator should require the label to
the label to be first because that's what the spec says, but we can
make the change in the future.
Erik Bruchez: Do we have a way to keep
track of these kinds of things?
Steven Pemberton: Track changes?
Erik Bruchez: When we think more
discussion is needed. Use the wiki?
Steven Pemberton: There is a trackbot
issue system? It's independent of actions.
Erik Bruchez: If it's hard to use I'd
rather use the wiki.
Steven Pemberton: I'm perfectly happy
to do that.
Action 2010-03-3.2: Steven Pemberton to investigate trackbot issue tracking system, for comparison to wiki.
Erik Bruchez: I think the action list could go to the wiki as well.
Steven Pemberton: Here's the
issues. http://www.w3.org/2005/06/tracker/xforms/actions/1
Leigh Klotz: It's read protected; it
should probably be write-protected.
Steven Pemberton: I closed my action.
http://www.w3.org/2005/06/tracker/xforms/actions/608
Erik Bruchez: I'm not convinced yet;
this tool is a little funny. It has 572 spam issues. We should
agree on a place for tracking important things. Actions there as
well would be great. I'm not sure the tracker is the best solution.
I'm not sure we want to decide now.
Steven Pemberton: There's no rush.
We'll have to clear out the tracker if we're going to use it. It
has two advantages: we can update it on the fly during calls using
IRC, and everybody can make changes. The trackbot follows our
mailing list, so if you say "ACTION 608" it will link to it. So it
has some advantages. I'll look into that more.
Leigh Klotz: So then you want to
re-open your action?
Resolution 2010-03-3.1: For validation and schemas, we keep label first in controls as it's so specified in the XForms 1.1 Recommendation.
John Boyer: It's not just
labels.
Steven Pemberton: We should generalize
it.
John Boyer: There's probably not a
good reason to impose an order anywhere.
Resolution 2010-03-3.2: We plan to investigate relaxing ordering constraints for labels and other elements in XForms 1.2.
Steven Pemberton: Action
item?
Steven Pemberton: Let's leave it as
that for a minute.
Erik Bruchez: For the remaining
items on RNG?
Leigh Klotz: There are two agenda
items. This one is done, but the general "Comments on XForm 1.1" is
done.
Test 10.8.e, 10.8.f Discussed here but not finished? http://www.w3.org/2010/02/17-forms-minutes.html#item04 http://lists.w3.org/Archives/Public/public-forms/2010Feb/0022.html http://lists.w3.org/Archives/Public/public-forms/2010Feb/0023.html http://lists.w3.org/Archives/Public/public-forms/2010Feb/0024.html http://lists.w3.org/Archives/Public/public-forms/2010Feb/0025.html
Charlie Wiecha: 10.8.f is done.
10.8.e I will send mail about.
Charlie Wiecha: I've re-written it to
be automated with Selenium, for example.
Leigh Klotz: Is it checked in?
Charlie Wiecha: No, I'll send mail
first and then we'll discuss it.
Erik Bruchez: I believe we
discussed this in the past; people want xf:bind to address one node
and they assume they can use a ref attribute.
Steven Pemberton: This did get raised
a long time ago, by Roland Merrick. I think he said we didn't need
both. I don't think there's anywhere you would get confused by
having a ref instead of a nodeset; please correct me if I'm wrong.
It says ref or nodeset depending on what we expect (single or
multiple). We made that explicit. Roland Merrick asked why not just
call them all ref.
Leigh Klotz: Originally they were all
ref and we changed them.
Steven Pemberton: Raman was opposd to
it. But we may say that ref and nodeset are the same thing and that
you can use one or the other.
John Boyer: Except that they mean two
different things.
Steven Pemberton: They do, but is
there ever a place where that matters?
John Boyer: The first-node rule is
imposed by ref; nodeset gives you multiple nodes. There are lots of
places where multiple nodes doesn't make sense, and ref
automatically picks the first one.
Erik Bruchez: You could move that
logic into the consumer. Input could be the place that applies the
rule.
John Boyer: There was a feeling that
the referencing mechanism might be loosely coupled to its
consumers. If you consider global attribute versions, xf:ref.
Erik Bruchez: Imagine bind with a
large nodeset, and then you use input/@bind. It's inconsistent. The
nodeset attribute is problematic with XPath 2.0; if you accept
bind, (repeat and itemset), then you don't have to restrict it to a
nodeset there. We can repeat over atomic values. It's a sequence,
not a nodeset. The nodeset attribute for repeat and itemset would
become a misnomer; so would a ref, by the way. We might need some
new attribute names.
Steven Pemberton: We could say that it
would just work; repeat/@ref would produce a nodeset.
John Boyer: In addition to the first
node rule, @ref imparts the UI life cycle and the MIP properties.
So if ref points to multiple nodes, what happens?
Erik Bruchez: The first-node rule
works.
John Boyer: repeat/@ref gives binding
to multiple nodes.
Erik Bruchez: We're trying to change
that with UI events.
John Boyer: UI Events yes, but not
MIPs.
Erik Bruchez: How does that work with
@nodeset.
John Boyer: It doesn't as @nodeset
doesn't impart UI Events or MIPs.
Erik Bruchez: I don't see that as hard
to change; it creates virtual groups.
John Boyer: That's different than the
repeat element itself receiving that information.
Erik Bruchez: It would be slightly
different. The repeat container element doesn't have a clear notion
of relevance.
Charlie Wiecha: Rather than having
that knowledge pushed back to the element, that knowledge is
cleanly carried by the attribute. We can describe it in the
attribute. We would no longer have a way to do that.
John Boyer: We could have @ref and
@reftype and default @reftype. That helps the nodeset naming
problem.
Erik Bruchez: Authors want to type the
smallest possible markup.
John Boyer: We can automatically
default it on our namespace.
Erik Bruchez: What's the extra
attribute for?
John Boyer: For overriding it; either
you get control with an attribute or you don't have control. Right
now we have two names: @nodeset (multiple, no MIPs, no UI events),
ref (single, MIPs, UI Events)
Steven Pemberton: We assigned that
magic to the name of the attribute rather than the context. We
could say the magic happens because of the context, and not the
attribute.
Leigh Klotz: The argument is for
xf:@ref (foreign namespace).
Steven Pemberton: Well, so if we allow
bind/@ref then newbies will say that bind only binds to the first
node.
Erik Bruchez: I don't see why we can't
just using @ref. I can modify my implementation to support @ref
everywhere and not change anything. I don't see the concrete
problem.
John Boyer: It wouldn't be a correct
implementation. Would you make it all work? The UI eventing and
MIPs?
Erik Bruchez: Absolutely.
John Boyer: For
xf:repeat/@ref="/my/items" which MIPs do you apply to the xf:repeat
element.
Erik Bruchez: I'm not because I'll
apply it to the virtual groups that do the node binding.
John Boyer: So you're saying
xf:repeat/@ref wouldn't apply MIPs to repeat.
Erik Bruchez: No, we can in the future
change it so that @ref doesn't do that. How far would the behavior
be from what we have now? I don't see major obstacles, if we agreed
that for authoring it would be a good solution, and more XPath 2.0
friendly, it would be good. I don't care that much about whether
xf:repeat itself receives readonly events. In my implementation
it's not going to, and if the spec says it should, we can reword it
slightly.
John Boyer: I guess we're saying there
is a difference but we need to fully understand it.
Charlie Wiecha: Yes.
Erik Bruchez: @nodeset is used only in
bind, repeat, and itemset. We need to examine these anyway.
Leigh Klotz: I think the original
proposal was to use @nodes on repeat.
Charlie Wiecha: Back from
history...the orthogonality is on the attributes now, and we'll
have to move that orthogonality to the context now. That may mean
introducing new attributes such as bind type.
John Boyer: Then people could choose
the binding type only on foreign elements, and we could default it
to UI bindings.
Erik Bruchez: Let's say you're using
XBL to implement a control. You could use foobar/@ref and I don't
see a problem. It could be repeat-like or it could be input-like.
We couldn't say that the @ref was interpreted by the xforms engine
on the foobar element anyway. It was done internally by the XBL
component. It could decide it internally.
John Boyer: Yes. More so, because @ref
an and @nodeset are used on setvalue and insert. We do have this
problem already because @nodeset on an insert is different from
@nodeset on repeat. So we have this problem already.
Erik Bruchez: I agree. There were
issues raised on repeat and setvalue. I believe the attributes are
badly named: there is a fundamental difference between input with
ref or nodeset, and an action needing a source for data. It doesn't
have the same meaning.
John Boyer: It was for similarity:
setvalue/@ref and input/@ref; insert/@nodeset and repeat/@nodeset.
But it's not the same kind of binding. We handle it with
definitions only; those definitions say that we've picked the right
default value for a binding-type identifier.
Erik Bruchez: We have ref-vs-nodeset
in bind, the discrepancy in actions, and the XPath 2.0 conflicts
(select, sequence?). Don't we have enough attributes already?
John Boyer: I get it, but right now we
have two attributes @ref and @nodeset. We already have the problem
that we're not properly indicating the bind type. We can go to @ref
and then have @reftype articulated; still two attributes, but we
don't have to use defaulting and definitions.
Erik Bruchez: Would you add
@reftype?
John Boyer: We could add it and
default it so that people almost never have to write it and it
would be the same.
Leigh Klotz: So they have to write in
their integration specs what the default is?
John Boyer: Yes. And we could say that
by default it is UI binding.
Erik Bruchez: It seems like extra
stuff to have an attribute./
Steven Pemberton: It seems like it's
only for the case where the context doesn't impart the information.
The rare case where you use xf:@ref as a global attribute that you
need to determine which you were using.
Erik Bruchez: It would be better if
there were only one.
Steven Pemberton: There's not, there's
one element, and many elements.
John Boyer: And also the MIP
attachment issue.
Erik Bruchez: Practically speaking, if
it were a sequence of items in XPath 2.0, then an input control
would accept a single-node binding defined by behavior.
Steven Pemberton: You're repeating
what I said earlier, that we move the magic into the elements. @ref
gives a nodeset but I take the first one.
John Boyer: The lowest common
denominator is that it just returns the nodeset and then we add a
different attribute to hold the other behaviors.
Steven Pemberton: I think Erik is
saying we do that in the control itself and add the extra stuff
there.
Erik Bruchez: For MIPs, in most
implementations, when I get a node, it's node annotations. As long
as the control gets the nodes, it will get them and it is free to
use them. Same as with PSVI for Schema. So MIPs are available to
the consumer.
John Boyer: I think you're for
additional attributes to control it.
Erik Bruchez: I'm arguing against
it..
John Boyer: PSVI defaults
attributes.
Erik Bruchez: At runtime the control
gets its bindings. I'm not talking about validation, but the
instance.
Charlie Wiecha: How do you prevent an
action from getting MIP events?
Steven Pemberton: Anyone want to write
this up? If not, I'll do it.
Action 2010-03-3.3: Steven Pemberton to summarize @ref @nodeset @reftype discussion.