wd:choice semantics (was Re: Rename "union" to "select"?)

[Sylvain Wallez <sy...@apache.org>]

Sylvain Wallez wrote:

<snip/>

> Ah, and another question: why is the case-selection widget a sibling 
> of the "choice" widget? Shouldn't it be a child widget? This would 
> allow an stronger semantic grouping. But I'm not sure if this is good...


Continuing to share my (random) thoughts with you on this...

There are two problems we will quickly face with the current way 
"choices" identifies the case:
- what's the format (or convertor) used for "case" values?
- how can I express more complicated cases, e.g as comparisons?

The answer to both cases is to separate the case value from a widget 
value and turn it into a simple expression.

My previous example can then be:
<wd:choice id="schedule">
 <wd:label>Travel schedule</wd:label>
 <wd:widgets>
   <wd:field id="departure-date">...</wd:field>
   <wd:field id="return-date">...</wd:field>
 </wd:widgets>
 <wd:case id="one-way" test="travel-type == 1">
   <wd:use-widget id="departure-date"/>
 </wd:when>
 <wd:case id="two-way" test="travel-type == 2">
   <wd:use-widget id="departure-date"/>
   <wd:use-widget id="return-date"/>
 </wd:when>
</wd:choice>

The strings "one-way" and "two-way" are symbolic names that will be used 
in the template, and aren't necessarily the value of a widget.

Here's a more complicated example, that asks to input the number of 
items in various cloth categories depending on an expected temperature 
(any better use case is welcome!)

<wd:field id="expected-temp">..</wd:field>

<wd:choice id="clothes">
  <wd:widgets>
    <wd:field id="nb-anorak"/>
    <wd:field id="nb-t-shirts"/>
    <wd:field id="nb-pants"/>
    <wd:field id="nb-shirts"/>
  </wd:widgets>
  <wd:case id="cold" test="expected-temp &lt; 0.0">
    <wd:use-widget id="nb-shirts"/>
    <wd:use-widget id="nb-pants"/>
    <wd:use-widget id="nb-anoraks"/>
  </wd:case>
  <wd:case id="hot" test="expected-temp > 30.0">
    <wd:use-widget id="nb-shirts"/>
    <wd:use-widget id="nb-pants"/>
    <wd:use-widget id="nb-t-shirts"/>
  </wd:case>
  <wd:otherwise>
    <wd:use-widget id="nb-shirts"/>
    <wd:use-widget id="nb-pants"/>
  </wd:otherwise>
</wd:choice>

Several things to notice here:
- the "expected-temp" value considered uses the unit used 
application-wise (here deg-Celsius) watever the input unit for the user.
- the <wd:otherwise> clause.

The test condition above only involves the "expected-temp" value, but we 
could also combine it with "expected-weather" to allow for the selection 
of boots and t-shirts for tropical rains and regular shoes and anoraks 
in dry and cold areas.

WDYT?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: wd:choice semantics (was Re: Rename "union" to "select"?)

[Sylvain Wallez <sy...@apache.org>]

Tim Larson wrote:

>--- Sylvain Wallez <sy...@apache.org> wrote:
>  
>
>>Sylvain Wallez wrote:
>>Continuing to share my (random) thoughts with you on this...
>>    
>>
>
>Please do continue.
>  
>

No need to ask ;-)

>>There are two problems we will quickly face with the current way 
>>"choices" identifies the case:
>>- what's the format (or convertor) used for "case" values?
>>- how can I express more complicated cases, e.g as comparisons?
>>
>>The answer to both cases is to separate the case value from a widget 
>>value and turn it into a simple expression.
>>    
>>
>
><snip examples/>
>
>  
>
>>Several things to notice here:
>>- the "expected-temp" value considered uses the unit used 
>>application-wise (here deg-Celsius) watever the input unit for the user.
>>    
>>
>
>Do you have thoughts on dealing with unit localization, i.e. some users
>are asked to enter values in deg-C while others are asked to enter values
>in deg-F, but we want to use the same expressions to evaluate both?
>Oops, sorry.  Probably just use localized converters in readFromRequest
>and then have no issues here?
>  
>

That's exactly the point: there's no issue, as the expressions use 
widget.getValue and therefore use the exact same representation (and 
unit in the case of temperature) as other places of the application.

I chose the "expected-temp" example on purpose, as it can have a wide 
range of input/display formats depending on both the language (i.e. 
floating point format) and country (i.e. deg-C or deg-F), but the 
widget's value used in the expression will always be a Float in a single 
unit (here, I considered deg-C).

>>- the <wd:otherwise> clause.
>>    
>>
>
>Nice.
>
>  
>
>>The test condition above only involves the "expected-temp" value, but we 
>>could also combine it with "expected-weather" to allow for the selection 
>>of boots and t-shirts for tropical rains and regular shoes and anoraks 
>>in dry and cold areas.
>>    
>>
>
>What should we do if more than one expression tests true?
> (1) Say, "Don't do that!" to the programmer
> (2) First match wins
> (3) Allow all the widgets from cases where the expressions test true?
>I lean toward (2), but might be able to be convinced of use cases for (3).
>  
>

I share your opinion: (2) is consistent with XSL, and (3) may reduce 
verbosity but can also be confusing.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: wd:choice semantics (was Re: Rename "union" to "select"?)

[Tim Larson <ti...@yahoo.com>]

--- Sylvain Wallez <sy...@apache.org> wrote:
> Sylvain Wallez wrote:
> Continuing to share my (random) thoughts with you on this...

Please do continue.

> There are two problems we will quickly face with the current way 
> "choices" identifies the case:
> - what's the format (or convertor) used for "case" values?
> - how can I express more complicated cases, e.g as comparisons?
> 
> The answer to both cases is to separate the case value from a widget 
> value and turn it into a simple expression.

<snip examples/>

> Several things to notice here:
> - the "expected-temp" value considered uses the unit used 
> application-wise (here deg-Celsius) watever the input unit for the user.

Do you have thoughts on dealing with unit localization, i.e. some users
are asked to enter values in deg-C while others are asked to enter values
in deg-F, but we want to use the same expressions to evaluate both?
Oops, sorry.  Probably just use localized converters in readFromRequest
and then have no issues here?

> - the <wd:otherwise> clause.

Nice.

> The test condition above only involves the "expected-temp" value, but we 
> could also combine it with "expected-weather" to allow for the selection 
> of boots and t-shirts for tropical rains and regular shoes and anoraks 
> in dry and cold areas.

What should we do if more than one expression tests true?
 (1) Say, "Don't do that!" to the programmer
 (2) First match wins
 (3) Allow all the widgets from cases where the expressions test true?
I lean toward (2), but might be able to be convinced of use cases for (3).

> WDYT?

Interesting ideas, please continue :)

--Tim Larson


__________________________________
Do you Yahoo!?
Find out what made the Top Yahoo! Searches of 2003
http://search.yahoo.com/top2003