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

All,

I followed the discussion yesterday with great pleasure. However, I have 
strong feelings against mixing switch/case and select1/select, both in 
syntax and semantics. Especially I don't like the idea of making switch 
a child of select1 or select. What's select1/select supposed to be then? 
A core control capable of holding a container control? A hybrid? This 
seems quirky to me.

First of all, we should clearly separate the issues we're trying to solve:

- keeping UI state during serialization
- multi-case switches
- variable number of cases

I see demand for all of these use cases.

* Keeping UI state during serialization

As Mark pointed out in the discussion, we should have a general 
mechanism to keep UI state rather than having a switch/case-specific 
solution. We need to serialize repeat indexes too.

While I'm perfectly comfortable with an xforms-ready handler restoring 
repeat indexes and case selections (provided that we add a case() 
function), I do understand the need for another solution in terms of 
digital signatures.

Adding @case to switch seems useful, but only for /reading/ state. Like 
Mark I have objections against making a container like switch 
essentially an input control. To toggle a case of such a switch a 
setvalue should be enough.

For repeats, we could make @startindex an XPath expression then.

* Multi-case switches

I don't know if really want a switch with multiple cases being 
/selected/. In this case I wouldn't call it a switch anymore, because 
that's misleading. The common conception of a switch does not allow 
multiple cases. I would rather go with group/@ref=self:node()[...] for 
that use case.

But having multiple cases /visible/ seems to be achievable: Like Raman I 
regard case as syntactic sugar, just mimicking a group. However, we 
still have the issue with a non-selected case being handled the same 
like a non-relevant group. While a non-selected case must not be visible 
per spec, a non-relevant group might be visible (depending on rendering 
of non-relevance). So, if we solve this issue by relaxing the 
non-visibility requirement of non-selected cases, we could have 
non-selected case visible.

* Variable number of cases

I like Raman's proposal of <caseset>, even if the element name might not 
be - uhm, well - capable of winning a majority. This would be 
straight-forward, the processing model and the in-scope evaluation 
context language could be adopted from itemset.

Just my 0.02[$|€]

Regards,
Uli.

John Boyer wrote:
> 
> 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
> 

-- 
Ulrich Nicolas Lissé

Received on Friday, 1 February 2008 13:01:58 UTC