Forms F2F Raleign Virtual Day February 8, 2008

* Present

Charlie Wiecha, IBM
John Boyer, IBM (Chair)
Leigh Klotz, Xerox (minutes before break)
Mark Birbeck,
Nick van den Bleeken, Inventive Designers (minutes after break)
Steven Pemberton, CWI/W3C (minutes after break)
Keith Wells, IBM
Erik Bruchez, Orbeon [after break]

* Agenda

* Model driven switch with case attribute

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 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>

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 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.

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.

* Break

* More Model driven switch with case attribute

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">

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]

* Break

Leigh Klotz: [returns]

* Minutes after break continue on IRC

* Meeting Ends