Charlie Wiecha, IBM
John Boyer, IBM (Chair)
Joern Turner, DreamLabs
Leigh Klotz, Xerox (minutes)
Mark Birbeck, x-port.net
Erik Bruchez, Orbeon
Nick van den Bleeken, Inventive Designers
Roger Pérez, SATEC
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Keith Wells, IBM
John Boyer: Anybody not yet
registered?
Leigh Klotz: I am not and I plan to
call in.
John Boyer: Keith do we have
that?
Keith Wells: Yes, we have full
conference. We have 7 in person and 11 total registered.
John Boyer: We agreed to meet for
six hours, from 9AM-3PM EST, which is 1400 UTC. It won't be a full
eight-hour meeting. I know at least some of the folks on the east
coast are going to need a break.
Steven Pemberton: We'll all need a
break.
John Boyer: We should arrange for a
time to hang up and get back on. 2.5 hours, break, 2.5 hours?
Steven Pemberton: That sounds
good.
John Boyer: OK, we'll do that.
Charlie Wiecha: I'll try to set up
a web conference, at least first for the virtual day.
Steven Pemberton: Are we going to be
in the Radisson?
John Boyer: How far is the
Radisson?
Steven Pemberton: 2.4KM.
Keith Wells: It's a straight shot, but
probably not too walkable.
Mark Birbeck: I have an account with
Yugma and they give desktop sharing, free phone number,
recording...
Charlie Wiecha: Our IBM does not
record. But will it be useful?
Mark Birbeck: I can't think of a use
for it.
John Boyer: OK, maybe we'll stick with
Charlie setting something up.
John Boyer: I think it will be
mostly future features. 1.2 on Friday, Monday; 2.0 on Tuesday; 1.2
on Wednesday.
Charlie Wiecha: Sounds like a nice
break.
John Boyer: I know we want to get out
of first public working draft. OK so we'll run with that. I'll put
out topics after this call.
John Boyer: Leigh, how's
that?
Leigh Klotz: I'll take a look.
John Boyer: We can go over it
Friday.
Leigh Klotz: We can publish Friday's
results then.
John Boyer: On Monday.
John Boyer: I think these are cut and paste errors for datatypes. Is everyone happy to have me do that?
Action 2008-01-30.1: John Boyer to fix http://lists.w3.org/Archives/Public/www-forms-editor/2007Dec/0003.html
John Boyer: The issue is the
shortname link to XML Events instead of the dated version, which is
unfortunate in that we don't get later versions. The deeper issue
is that the shortname points to the WD for XML Events 2. It seems
it shouldn't point to something that isn't a Rec. Is that a fair
statement?
Steven Pemberton: It depends on the
definition of should. When it is new, it should point
to the latest. But a shortname isn't guaranteed to give a Rec. A
normative reference should probably use a dated version.
John Boyer: What is our policy going
to be in group, domain, and W3C on shortnames?
Steven Pemberton: I am sure it's
already defined; I believe it always points to the latest version,
end of story.
John Boyer: The W3C document doesn't
say that, which is part of the problem.
Steven Pemberton: It says it should
point to the latest recommendation. http://www.w3.org/2005/05/tr-versions
John Boyer: We agree with that, but
what about the version-specific ones? xforms10, xforms11, xforms20?
I think it makes sense to have those numerically-identified
shortnames point to the latest copy of the spec if they have
major-minor. It's OK now that 1.1 is in CR, but as soon as 1.2 is
in WD, I wouldn't want someone to get that. We had talked about
some pushback here for two-digit version number so we can properly
represent the latest versions whether or not they are
recommendations.
Steven Pemberton: Here are examples of
shortnames with more than one digit: http://www.w3.org/TR/html401/
http://www.w3.org/TR/html401/
http://www.w3.org/TR/html401/
John Boyer: I know Ian wants us to
migrate off 11 because the tr document doesn't provide for it.
Meanwhile can we get the XML Events link put back to the latest
Rec?
Steven Pemberton: I'll ask about what
the practice is, about pointing to latest Rec or not.
John Boyer: Is there any objection to
take an action to correct this bib entry and any other ones that
are using short names? I might not do that any time soon.
Action 2008-01-30.2: John Boyer to ensure that all bibliographic entries in XForms 1.0 do not use short names.
John Boyer: As many of you know, the ODF spec using the XForms model and uses the XForms shortname.
Leigh Klotz: Dave Orchard has
weighed in with some comments.
John Boyer: It looks like it may be
changing then?
Leigh Klotz: So we should wait.
John Boyer: Or maybe we can just ask
them to consider XForms submission when they do the changes.
Leigh Klotz: Even if they put a blank
section in for now. OK, I'll do that.
John Boyer: There are selected
attributes on cases, but it's not clear how things work in repeat.
We'd like at least the chance to have a straightforward method to
have a switch driven by data in the model rather than by hidden
data stored in the UI that can't be captured across save/reload.
The straightforward proposal is an attribute on switch, perhaps
called case, with an XPath expression evaluated in the
context of the ref or the in-scope evaluation context, resulting in
an id. This would override the selected attributes on cases. toggle
would then select a new case, but that would push into the
referenced node into the case attribute.
Charlie Wiecha: That does make sense.
id is one pattern; I wonder if there's another pattern with a
looser coupling, such as pattern matching.
Erik Bruchez: It seems there is a
strong parallel with select1. select1 is used to select a value,
which is not the goal here. Is there a way to make the syntax
closer. Perhaps cases can take labels, or xf:value.
Charlie Wiecha: That's the direction
I'm thinking as well.
John Boyer: That's pretty clever. It
also opens up the door for multi-case switches; we have select1 and
select. select is driven off a space-separated list of values; we
could consider more than one case at a time.
Charlie Wiecha: I wasn't going to go
there but I did think of that, too. It then becomes more like a
production rule system.
John Boyer: We do have a related use
case that Nick and Erik have been onto for a while, with multi-case
switch; it could easily move to 1.2. They wanted the other cases to
be live to still be able to detect invalidity; somehow
live and 'on top.' Maybe that's too far and we stick
to one case being selected and an attribute on switch that says
whether non-selected cases are in the XForms 1.1 zombie
state.
Charlie Wiecha: Let's consider Erik's
case of the analog of select and select1.
John Boyer: A different element.
Charlie Wiecha: With consistent
syntax.
John Boyer: Are people liking this? A
label element and a value element in each case? select off of that
somehow?
Mark Birbeck: I've always been against
extending case in this kind of way. Erik's summarized it quite
well. There's a difference between those things in the model and
those things that aren't. It gets confused. I've always seen
case/switch more like a dropbox; whether it's open or closed is
irrelevant for the model. That's not to say there's not use cases
for it, but why not come up with new element for them. For example,
the way Erik's putting it, sometimes we want to reflect the value
into the model and sometimes we don't. So extend select. The third
way is Charlie sometimes wants the model to control the way things
appear. You could do it with group ref=.[...] and say
it when conditions are true. I'm agreeing we do need something: ui
only, model reflected in ui, ui reflected in model. Then let's work
out the best way to achieve those use cases, rather than adding an
attribute to case.
John Boyer: I'm not proposing an
attribute to case ...
Mark Birbeck: There's two ways to
change it: user interaction (toggle, etc.) not reflected in model,
and then if we change in the model, we have to work out issues
about conflicts, loops, etc. These would be unnecessary if we had
user choice switch/case where we don't care until they're done, and
sometimes the wizard approach.
John Boyer: The group approach is not
appealing. It's hard to tell a pile of groups are working together.
A containment element gives you the idea.
Charlie Wiecha: ...
Mark Birbeck: Maybe I've
misunderstood, but you just reminded me. The way we implemented
switch and case is that it toggles all child elements. Maybe we're
not so far apart. switch is a controller and case is an anonymous
thing. Maybe we can have a generic controller, case or group
inside, with different rules.
John Boyer: I do. I see case as a
group of controls with a different name because of the
parent.
Mark Birbeck: In our Javascript
version, switch with div children functions the same way. There's
justification for validation, but not for functionality.
John Boyer: Do you really have to wrap
it in a case? It doesn't seem like a big deal from a design tool,
but maybe in a text editor.
Mark Birbeck: It's not the typing. The
key aspect of switch is that the switch element and the id of the
children. There's no reason to require xf:case.
John Boyer: Toggle tells switch the
id. It would be cool if it would switch and push the value into a
referenced node. Toggle then takes on a little bit of
setvalue.
Mark Birbeck: I can imagine you
convincing me of that. So if we had a toggle-fired event with the
value.
John Boyer: In fact it's not called a
case attribute, but I do have an implementation of this under a
foreign-namespaced attribute. If someone does a setvalue or UI for
the data node, then that does act like a UI binding and toggles the
switch, which is pretty handy. Then I can use a separate control
like a select1 to drive it in a more data centric way. It opens up
easier control opportunities than what I had before.
John Boyer: So the proposal for me is
to pursue writing up these things we've talked about as a strawman
for 1.2.
Charlie Wiecha: Can you summarize
where we got to?
John Boyer: Please correct me if I'm
wrong. I didn't hear anyone say they didn't want to do this for 1.2
After discussion with Mark, it sounded like he could imagine it. It
seemed like a secondary attribute on switch would be useful, to
contain an XPath expression resolving to a node to have a two-way
binding to switch. To Mark's point, whether switch has to be
limited to case as today and instead select among child elements,
then calling the attribute something other than case might make
sense; maybe state.
Leigh Klotz: I don't see anything
wrong with leaving it called case.
John Boyer: If we want to open up the
content model it might not be advantageous. Or just use case.
Charlie Wiecha: It implies it's not
really switch anymore.
Mark Birbeck: Part of the reason I had
been saying the item under select can't take arbitrary markup was
in terms of reflecting it in the instance, all the architecture is
there, as Erik says with select1. The bulk of the change would be
the content of item would be the same as the content of case. We
kind of need to go that way with maps. I have a select1 that allow
you to choose the URI of a video. The items in the select1 are
video showing, using XBL. You need to do the kind of UI people
expect nowadays.
John Boyer: I can see opening up
select1 to that possibility; but what might a basic author might
think? Creating groups of controls and switching them might not be
select1. We could allow group in the item syntax, but it also seems
to me that there's a lot more basic people who will tend towards
choosing switch.
Mark Birbeck: You're right. If you've
got to reflect the value of this video then you would move from
select1; if they start with video clips and get the user to choose
one that might be switch case.
John Boyer: And possibly make the
select1 with item labels that are the thumbnail; then that changes
cases.
Mark Birbeck: Say you have 4 videos:
the label of each is the mini-version of the video. It's a radio
button.
John Boyer: Sure. Maybe the
switch/case might pop up on the right with the video you
chose.
Leigh Klotz: [irc] i see some
similarity with xxf:dialog and the proposed xf:dialog as well, in
terms of expanded content models
John Boyer: People create the switch,
then the selector that drives the switch through data. This happens
using the designer tools.
John Boyer: OK, there's debate about
whether to call the attribute case. It kind of makes sense do that
that. We have case/@toggle and the child element as well. The
semantic we're projecting is that we're selecting cases in a
switch. So either way I can write it up with case or without. Does
that sound reasonable.
Charlie Wiecha: I think it's going in
the right direction.
John Boyer: The last bit was the
modification to use a value element rather than an id. Does that
sound like the way we want to go? Originally I thought of using an
id, as with toggle. What came up during this conversation was to
question that.
Charlie Wiecha: It is a bit of
decoupling between the model and the UI.
Steven Pemberton: I agree. It doesn't
seem quite to match.
Leigh Klotz: A number of "little
languages" these days allow switch/case with calculated values
rather than manifest constants so that seems useful anyway.
Roger Pérez: [irc] an xpath
boolean expression to the selected attribute of the actual case
instead of the new att?
John Boyer: ...
Steven Pemberton: If we'd chosen
something other than id in the beginning we'd have never had the
repeat problems.
John Boyer: Not for switch but we had
id on input and select1 for setfocus. So we had the general
problem.
Mark Birbeck: Which is how it got
solved.
John Boyer: Roger asked about
selected. My own personal preference is to use switch to select a
single case. Pretty much anything goes then, and the author has to
work out that one can be true; it seems like a multi-select
capability; I'm not sure that's what this widget is. By comparison
it seems easy from a design to drag-and-drop and gesture data on to
a switch to produce a binding. So I think a single attribute of the
switch is better, because it's about th switch.
Nick van: [irc] you have also a
problem if the value of the switch doesn't results in an id of a
case in the switch
John Boyer: We'd be changing to have a
value element within each case; it would choose a case based on
value element. It's then like select or select1; there's
precedent.
Leigh Klotz: You'd get out of
range.
John Boyer: With empty?
Leigh Klotz: With non-empty but not an
id in the list.
John Boyer: I buy out-of-range.
Leigh Klotz: But you'd get a binding
error if you did it with markup. So can we say you can use
switch/ref only with case/value? Those co-occurrence constraints
are hard to express.
John Boyer: I like what Rafael said if
we consider a value attribute.
Nick van: [irc] if we have
<case value=""> then we can make in sync with
select and select1
John Boyer: I hadn't realized a
attribute was considered; just a child element.
Charlie Wiecha: This is what I
thought.
Mark Birbeck: This is what I don't
want. I think deciding which to prioritize is a problem. If you go
on the id, the user can select one of the cases; the model can
update. They can stay in sync. If someone selects a different case,
the expression that makes another case selectable hasn't changed.
Changing the id is ok, but if it's selected by id or by
expression.
Leigh Klotz: This isn't the selected
proposal where you can have such conflicts; it's switch/@ref sets
the value and the case/@value is the one matched.
Mark Birbeck: So switch becomes
select1.
John Boyer: Say you had a select1 with
items; the ref chooses leaf nodes, but...
Mark Birbeck: Sure but if the items in
the select1 need to come from a different place, then we have other
ways to do that. It seems quirky to turn switch/case into select1
and we're losing the distinctions.
Nick van: [irc] I think it is the same
as select1, it is only a display issue of select1
John Boyer: The usual semantic of
select1 is to choose the value; the usual semantic of switch/case
is to display a group. If we throw group into select1 we lose the
semantic of select1 then. switch is then a container form control
and select is an atomic one.
Mark Birbeck: Rather than becoming an
output control, it becomes an input control. Group isn't an input.
Output isn't an input. Switch and case aren't inputs, at the
moment. It's one thing to enhance them and another to change them
into something else.
John Boyer: There are states that
exist in the UI that we have no way of capturing in the
serialization.
Mark Birbeck: There may be other ways
of reflecting that back into the model other than running
switch/case into select1; perhaps the index function as in repeat.
There may be other ways that don't require us to bend switch/case
to become an input control.
John Boyer: So case(). It still lacks
automaticity. When a form gets initialized, the switch could
automatically decide what case is selected based on the case
attribute. With a function, you still have to write an xforms-ready
handler.
Mark Birbeck: That's why I have
problems with this. The current switch/case uses the attribute, and
then toggle. In the model we're now discussing, those two phases
get blurred. We'd have to set the instance data. So we could have
the enabled attribute an expression. It doesn't have to be so
flexible that it's no longer switch.case
Nick van: [irc] and when you change
data you should add a change-value listener that switches the
case
John Boyer: Suppose we did turn the
selected attributes of cases into XPath expressions; that makes it
easy to have data drive the switch, but then when the you toggle
it's in conflict.
Mark Birbeck: I was thinking of just
at initialization time.
John Boyer: Initialization is tricky.
When it's time to go home, you save, restore, and then
initialization kicks in and you can't pick up where you left
off.
Mark Birbeck: I don't disagree. But I
just don't think switch/case is the right vehicle. It already
exists as a very UI-based thing. I can imagine the UI binding
because that conflict doesn't arise, but when we get to general
instance data, it does.
John Boyer: To be clear, with IDs I
was talking about two-way communications.
Charlie Wiecha: I think that makes
Mark more comfortable.
Mark Birbeck: Yes, it's the
case/@value that makes me uncomfortable.
John Boyer: Me too.
Leigh Klotz: I don't see the sync
problem; I see the select1 issue.
Mark Birbeck: If you have an id it's
always synchronized because it sets the value. But I have case
whose value is non-smoker, a case could be selected on the basis of
information that's non-selected, does it toggle Y?
Leigh Klotz: I don't see how it's
inconsistent if it's exactly the same as select1. Just adding ref
and value to switch and case won't cause inconsistency because it's
precisely select1 with a different UI content model.
Mark Birbeck: But it isn't consistent
or the same because value is evaluated to determine whether it
selected.
Leigh Klotz: No, it's just like in
switch case.
Mark Birbeck: I had misunderstood the
proposal.
Leigh Klotz: I think you still don't
like it but it isn't inconsistent.
Mark Birbeck: Yes, it's
pointless.
Charlie Wiecha: This was my proposal
from an hour ago.
John Boyer: <switch
ref="some/tree" case="@selected"><case
value="justLikeID"
John Boyer: If @selected node contains
the value that equals the value attribute then the case is
selected
Mark Birbeck: I saw on someone's
blog recently, separate instance data just for UI controls. We do
this too. I think we could make this fairly simple though.
Erik Bruchez: [irc] same here using a
separate instance is often done also to handle controls
relevance
Charlie Wiecha: One of your
objections was the state variable is in model and not the UI. Maybe
if we had some dynamic aspects of state in the UI we could handle
this.
John Boyer: If you save the data,
you've lost it. switch/case and repeat indices are about it. It's
important for digital-security and document-oriented aspects.
Charlie Wiecha: We could still treat
it as data but have it at a remove somehow.
John Boyer: The processing model isn't
hard; it's just like select1. But I need an idea of whether we're
going to do this or not for 1.2. Let's pick that up on Friday.