Charlie Wiecha, IBM
John Boyer, IBM (Chair)
Leigh Klotz, Xerox (minutes before break)
Mark Birbeck, x-port.net
Nick van den Bleeken, Inventive Designers (minutes after break)
Steven Pemberton, CWI/W3C (minutes after break)
Keith Wells, IBM
Erik Bruchez, Orbeon [after break]
http://www.w3.org/MarkUp/Forms/wiki/Model-driven_switch_with_case_attr
John Boyer: There's been a bit of
discussion today as well. People have said select and select1 are
the selection controls. I have the view that switch is the
container form controls for groups of UI elements to select
amongst. The case element of switch and item element receive the
same events. There's a lot of synergy for a switch inside a select
or select1 instead of an itemset. So item is primitive, but switch
is for a group of controls. Then the UI binding is the proper
binding. Opinions?
Charlie Wiecha: It's unfortunate Uli
isn't here.
John Boyer: He sent in a dissenting
opinion.
Steven Pemberton: A comment...you say
"never really liked switch/case because case is acting
like a UI binding." I've understood from the server-side people
that this was a positive, because they can deliver part of
the...
John Boyer: I meant a design I've been
using, with an attribute on the case selection, not the current
design. Mine was second a like UI binding on the same control. I
agree with what you're saying.
Steven Pemberton: Good.
John Boyer: I like having the data
drive what case is selected, but I don't' like the second attribute
on the same control. ...
Charlie Wiecha: I like the way the
elements are coming together; it seems to resolve the issue about
being a proper model binding. But it looks like a lot of convention
that an author has to know; are we missing a way to simplify this?
Perhaps redefining select and select1 without literally using
switch?
John Boyer: I started from wanting to
switch between a bunch of controls. The next step is to drive that
from data. From Wednesday, it was clear that select1 driving was
one way.
Charlie Wiecha: Where do the values
come from? The labels on the cases?
John Boyer: The ids in the first
example. Later is the one with the value. So cases does the same
thing as item.
Leigh Klotz: Could we do something
similar with choices, the group holder for item.
Mark Birbeck: All the second example
really does is show how to have a item have more markup. In the
example the other day, I had video controls in select1 with live
video inside labels, and the larger output shows the results of the
selection. There's a couple of problems, but it proves it works.
John objected to controls inside label. If you look at what John
has here, he has ... in there. One possibility is that
the ... that's a child of case is instead a child of
item. So instead of putting it in label, we add an extended
"when-selected" code underneath. There are lots of different
selection arrangements that we aren't able to do with XForms.
Things like tabs are like this too.
John Boyer: Mark, can you look at the
IRC: This is what I think Mark is proposing. Rather than putting
switch/case inside select/select1
<select1 ref="payment/methods/@method">
<label>Choose method:</label>
<item>
<label>
<value>
<group>
...
</group>
</item>
...
Mark Birbeck: Kind of; I see the
video as part of the label.
Steven Pemberton: I don't see a reason
to have a video in a label.
John Boyer: But this lets you put
input controls in a label.
Steven Pemberton: Yes, it's weird, but
what...
John Boyer: It seems better to have a
container control that can contain input controls associated with
items to select. I don't mind putting the video in the label; it
seems acceptable for output.
Mark Birbeck: I'm with you.
John Boyer: When you want to choose
among other inputs and select1s...
Mark Birbeck: I agree. We're still a
step away from your design to store in the model, but we might get
there. This is config dialogs, for example. Down the left,
checkboxes and radio buttons on the left cause grayed out controls
on the right to become active.
Steven Pemberton: Which one is
tricky?
Mark Birbeck: The ability to choose
value with a radio button or checkbox and have the consequence to
open up further controls neatly laid out to the right of the
control you choose. You can do it with groups and
ref=x and relevant but you have to position it next to
those checkboxes. The easiest way with XHTML is to put it inside
the label. John's right; there's a need for an input aspect to
this. The ... would be a great addition, either
way.
John Boyer: But I'd have to put a ref
on every group to reset the context of the subtree. switch/case is
the container control that communicates that we're choosing among
different containers. It can be select1/item/value/group or
select1/switch/case.
Leigh Klotz: What do we get by
limiting the switch to be inside the case? It looks like it will
always be ref="..".
John Boyer: It might be.
Leigh Klotz: Actually it looks like
switch ref=.
John Boyer: I had imagined a subtree.
The input controls inside would need to refer.
Leigh Klotz: Oh I see. switch ref
doesn't change the value. This ref is really switch context.
John Boyer: That's right. Charlie;
What's driving the case selection?
John Boyer: The method attribute. The
case would receive an xforms-select just like an item receives an
xforms-select.
Charlie Wiecha: At some point we need
to discuss whether this affects switch outside select1.
John Boyer: I think a switch does what
it does; a select1 wrapper is another data-driven way. The select1
would then toggle the switch when it gets its value change.
Charlie Wiecha: So we'd still have the
existing toggle function?
Keith Wells: How does an
implementation know to present the select1 inside the switch?
John Boyer: The idea is that
switch/case is one of the items. If select1 appearance=full then
the appearance might be radio buttons. It's the content of the
unselected cases that behaves as if they aren't there. Whichever
button you select then should cause the radio button for COD to be
lit up and the select1 to tell the switch to toggle to show to the
user.
Keith Wells: This bothers me from a UI
perspective; how do you style using CSS? How do you separate the
select1? It seems a UI and switch a document control. Now we're
merging the two.
John Boyer: My guess is that the
default behavior to is that when you select it, that group of
controls appears immediately beneath the label. I'm sure you could
style that case to show up in a different location. Meanings for
appearance attributes on switch might be nice. Maybe tabs above the
switch.
Nick van: [irc] you can only show the
content of the case that is selected, bcz not selected cases are
non relevant
John Boyer: I was getting at that; the
content is non-relevant but you have to be able to send
xforms-select and xforms-deselect elements at them. So you can read
the non-selected labels. Just think of switch: for switch you have
to be able to read the labels.
Nick van: I agree but in the
configuration dialog example from Mark Birbeck, when the radio
button wasn't selected, it would be strange to render as you
described. The UI goes away when you select another button.
John Boyer: So if you have form
controls in the labels?
Nick van: Not in the label but as
contents of the case. Otherwise the UI collapses all the
time.
John Boyer: Some people like that; you
can style the controls to be grey though.
Nick van: But you don't get the events
then.
John Boyer: How's that different from
group relevant?
Nick van: The controls will be out of
sync there too.
John Boyer: That's an orthogonal
issue; you don't like display controls as inactive. We have
something similar on the bug fix issue list.
Nick van: You could do it with
group.
John Boyer: That's a different choice;
if you want a select1 in a different set of controls...that's an
argument against group in item.
Nick van: ...
John Boyer: Nothing causes that group
to become inactive. The switch semantic is better as the case
becomes relevant by virtue of switch and case. There's no
equivalent definition of group and non-selected item/group.
Mark Birbeck: I have a proposal.
One problem is...so far we have an object model. Now we're shooting
off in a number of directions, like multiple inheritance. case has
acquired a value and switch has ref and the behavior has changed;
you could say select has evolved slightly. I'd like to see
incremental evolution rather than blending too many things.
Consider this dialog box with nested checkboxes and radio buttons
with upload controls on one.
Mark Birbeck: Now consider this
markup. http://www.w3.org/MarkUp/Forms/2008/screen20080201.PNG
John Boyer: This is a bit of a
degenerate case...there's not a set of controls nested.
Mark Birbeck: I'll show that. What I
propose is that we take how you would mark this up, using the .[]
relevance trick, and look at the problems. #1 the CSS is difficult
for putting them together. So, inspired by you John, here's your
...: put group into the item. It then flows properly
with positioning in the document. It only takes a little CSS to
push the control to the right, for example. The second thing is to
add the context attribute to select1, and then add a relevance
controller to the containing element,
group/@ref=.[.=true]. Now let's consider a shorthand
for this: case
Charlie Wiecha: The implicit behavior
is that when them item is selected, this is the content to
display.
Mark Birbeck: So it's defined in other
elements of the language.
John Boyer: Two things I like: It
seems like we could avoid toggle with this; you couldn't select
these cases with toggle. I forgot the other.
Mark Birbeck: Now you have a
serialization of the UI state.
John Boyer: The other was that this
makes short work of a case of controls iterating over an itemset.
That's a problem with switch inside select1 because switch doesn't
have the repeated case concept.
Mark Birbeck: I agree that putting
controls inside labels is a a bit odd.
Nick van: [irc] I like this much more
then adding the extra switch
Charlie Wiecha: I agree; I was having
trouble understanding the composite behavior.
John Boyer: Me too. Anyone feel
uncomfortable with the latest development?
Charlie Wiecha: I don't like the case
element, but I like the general direction. It will raise issues
about the different behaviors.
Mark Birbeck: There's a proposal on
the list that we define in an info set. If you were to say case is
one selection among many, if true visible.
Charlie Wiecha: There's only one case
in each item; it's the substance of what you want to display.
John Boyer: Why can't case be the word
that replaces item?
Mark Birbeck: Then the bindings?
John Boyer: You just have value and
label. Both are targets for xforms-select.
Charlie Wiecha: So we don't need a
separate container for everything other than label and value.
John Boyer: I can live with it.
Mark Birbeck: You need a container
once you need another group. It's probably worth having a grouping
thing.
Steven Pemberton: I don't follow. We
got a group, the item, and it has other stuff as well. What's the
problem with that?
Mark Birbeck: If I change this to
case, and then we add a new element you can't tell whether it's for
the child or the parent.
Mark Birbeck: One positive is the
use of itemset, and we'd then have to have caseset.
This reminds me of my pitch of trigger, as output with a handler
and some CSS. So item has this behavior, the value that's stored.
But there's other stuff that can go in.
Steven Pemberton: [irc] Do we really
need itemset? Can't we just say that <item nodeset="...">
does the job of itemset
Charlie Wiecha: i still don't like
calling the element <case>
Steven Pemberton: +1 to charlie
Mark Birbeck: I'm off to make a
sausage sandwich.
Charlie Wiecha: There's only one
case in the item, not a selection.
Steven Pemberton: I don't get how we
can explain having to write case to an author.
Charlie Wiecha: I'm on the narrower
issue of the spelling.
Steven Pemberton: I'm not sure about
the future argument; I don't see how putting case
around it changes it.
John Boyer: I can answer that. The
case does two things: it's a container, but it's also
trying to hint at the semantic that the stuff inside that container
will behave as if non-relevant when the case is not selected.
Steven Pemberton: If we try to model
this particular use case, it looks more like a setvalue inside of a
case than a case inside of a select1.
John Boyer: Coming back to
switch/case, we have a control that can switch user interfaces.
Authors are being negatively inhibited at best and actively
discouraged from using the control we have because it's next to
impossible to control it from data, so if you have a document or a
regular web app where you expect the user to proceed through the
app over time, being able to store the case in that data becomes a
necessity. The app then can't remember what switch you were last
on.
Steven Pemberton: I'm completely in
favor of model-driven controls.
Charlie Wiecha: I don't see what the
switch element is giving us. We have the conflict between
select1/item and switch/case. I don't think what case does; it's
just a container for content.
Steven Pemberton: It's not true that
we can't do what's being demonstrated here; we can do it with
relevance. The argument seems to be that it's hard to present
right.
John Boyer: We can do it with
relevance and a pile of groups; but people are pushed away from
using switch/case and use a pile of unrelated groups and model
relevance.
Steven Pemberton: I see what you're
saying and I almost agree.
Charlie Wiecha: We have not yet solved
the model-driven switch problem. That's the other half of this
problem. We should do them separately and see if the deeper
commonality is an XForms 2.0 solution. I'd like to see select1/case
where we spell case xyzzy and then move on to
model-driven switch.
John Boyer: That's not too bad as long
as we spell it case. We have a UI switching container control. If
we start with that then how do we add to that the ability to drive
the case selection from data? The answer seems to be quit using
switch, which is a shame.
Charlie Wiecha: I'm not proposing
select1 to solve teh model-driven switch problem nor switch
...
John Boyer: I like switch in
select1.
Charlie Wiecha: I don't get it. It
looks like two levels of selection handling. It looks like a
propeller-head version.
Nick van: [irc] I like the case in
select and switch because the the case does the relevance behavior
and the element around it (select, select1, switch)
Leigh Klotz: What if you had select1
the first child element of switch instead?
Steven Pemberton: The more I think
about it the less satisfied I am with the case inside the
select1.
Leigh Klotz: I think switch/ref is
great and have for years but never knew what to do about the value.
Now we have the value element. The switch shouldn't present its own
trigger ui though (I know chiba has appearance attributes but I
don't like it.) So use select1 and put it inside switch.
John Boyer: I like it.
Charlie Wiecha: It would solve Mark's
UI layout problem.
John Boyer: The select1 control
listens.
Charlie Wiecha: Is there any data
binding on the select1?
John Boyer: The select1 has the ref.
The switch binds to a tree as the context and the select1 can
branch off the root to the attribute that holds the selection
that's made.
Charlie Wiecha: So the ref on the
switch is for context, as Leigh said.
Steven Pemberton: How are the cases
selected for match?
John Boyer: I would think each case
would have a label and a value, in parallel.
Nick van: [irc] I find it a bit
strange. I don't understand why the select needs be inside the case
and how you con be sure that the same values are in the cases
John Boyer: It was a suggestion from
Leigh to indicate they are working together.
Charlie Wiecha: How does the backwards
value setting happen?
John Boyer: The UI binding on the
select1 is two-way. It pushes a value-changed event into the
select1 which then issues the event to the switch for the
matching-value, which the switch then listens to.
Charlie Wiecha: How about toggling
back to the third case?
John Boyer: It's the switches job to
interoperate with its contained select1. The switch is the
controller.
Keith Wells: What happens when you
have a select? Are several cases relevant?
John Boyer: Let's hold that for Nick's
question.
Nick van: Isn't this going to be
hard to maintain the same values in the select and the cases?
John Boyer: It could be.
John Boyer: For XForms 1.2 we could
stick to IDs for the cases. I don't have a problem with ids.
Leigh Klotz: Can we get by without
having items in the select1?
John Boyer: Maybe not. It seems more
natural. The labels that drive a radio group might be distinct from
the cases.
Nick van: It seems a bit extreme to
have it twice.
John Boyer: Maybe we need a simpler
child element; here's a switch and a child of that ...maybe
input?
Leigh Klotz: The advantage of select1
is you get to use the machinery of XForms and the host language to
display.
John Boyer: Then style the switch as a
group of tabs.
Leigh Klotz: It's like an implicit
single-element group at the head.
Nick van: Do we need the form
control?
Leigh Klotz: It lets you do trigger
with setvalue, select1 with radio buttons, and input with boolean
checkbox nested.
John Boyer: ...
Nick van: ...
John Boyer: From the spec standpoint,
we have containers group, switch, and repeat, and then atomic
controls to manipulate a singular leaf node of data. Switch with
cases is the container control, and we want to have that container
control store its state in the instance data. Now we need to bind
it to the data.
Leigh Klotz: Doesn't ref do
that?
John Boyer: No, because ref on
containers doesn't set the value. switch is a container.
Leigh: <switch ref="payment/method"> <xyzzy ref="@method"> <select1>...</select1> </xyzzy> <case>...</case>
Leigh Klotz: So we use the binding
site from upload and call it xyzzy. The content model is group. We
get content or no inside it so Nick is happy. Mark would like the
content. We can't use ref for single-node binding because it's a
homophone for the context because it's a container.
John Boyer: OK, so what do we call
xyzzy?
Leigh Klotz: [leaves]
Leigh Klotz: [returns]
