Pretty cool talk today; how about switch *inside* select1/select

I'm sure you are all pretty much the same on this point, but I found 
today's telecon pretty cool and stimulating.

For my own part I had previously recognized the similarity between <switch 
... @case> and <select1 ref...>, but it was something I previously put 
into the "coincidental parallelism" bucket because I select1 is a basic 
form control, not a container control.

That being said, I have really never liked <switch ref="..." @case> as a 
design because @case is essentially acting like a UI binding.

After today's discussion, I sat trying to rationalize in my mind all the 
view points, and an idea came up that seems pretty cool to me, so I hope 
you like it too.

Wouldn't it be cool to put <switch> inside of <select1>?  It would look 
like this:

<select1 ref="payment/methods/@method">
   <label>Choose your payment method:</label>
   <switch ref="..">
       <case id="VISA"> <label>Visa</label> ...
       <case id="MC"> <label>Mastercard</label> ...
       <case id="COD"> <label>Cash on delivery</label> ...
   </switch>
</select1>
 
There seem to be several benefits

1) We would have an actual UI binding from the select1 as the way to 
automatically drive the switch case selection
2) We would retain switch as the *container* form control for UI 
selection.
3) The switch ref is still able to reset the context relative to where the 
data is stored.
4) We haven't yet even added any new vocabulary; just a new possible 
content model for select1
5) We seem to get multicase switches seemingly for free by using select 
rather than select1, again with no new vocabulary

A <toggle case="X"/> would make the selection in the switch, which would 
in turn notify the select1 of the value change needed for its UI binding
Setting the value of the node referenced by the select1 would push a case 
choice from the select1 to the contained switch automatically

The only issue to settle, then, would be whether it is worth the effort to 
use a value space, rather than an id space, for case selection.  We 
discussed doing this via a value attribute, though I had thought for 
consistency with the <item> element that it should be a child element of 
case instead.  Regardless of that choice, the above makes it clearer that 
having the value space method for selecting cases would be preferable.  So 
it might look like this instead:

<select1 ref="payment/methods/@method">
   <label>Choose your payment method:</label>
   <switch ref="..">
       <case> 
            <label>Visa</label> 
            <value>VISA</value> 
            ...
       </case>
       <case>
            <label>Mastercard</label> 
            <value>MC</value> 
            ...
       </case>
       <case>
            <label>Cash on delivery</label> 
            <value>COD</value> 
            ...
       </case>
   </switch>
</select1>

This looks really cool because it is quite analogous to using <item> with 
label and value children, except we are declaratively indicating that the 
selection is being associated with switching among set of form controls. 
It even becomes easy to see how to extend this to the "itemset" version by 
using repeat inside switch!  This would generate a variable number of 
cases according to how much data there is. 

Maybe we could consider whether all of this is good to go or some of it 
should be deferred, but great fun in any *case*!  (sorry) 

What do people think about this approach?

John M. Boyer, Ph.D.
Senior Technical Staff Member
Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw