Re: [uiml] FW: Implementation specifics for UIML behavior rules

["Robbie Schaefer" <robbie@c-lab.de>]

> Hello everyone,
>
> We currently have a Bachelor's thesis student working on improving the
> implementation of behavior rules (conditions and actions) in our
> renderer.
>
> He ran into a few difficulties however. There are some difficult cases,
> such as multiple events in the condition statement, or only a property
> in the condition statement. Here are a few examples:

These are exactly the issues I tried to bring to your attention after James
proposed the "flexible behavior", since they belong to the core concepts of
DISL.

> 1) suppose we want to fire an action when both a button is clicked, and
> an item is selected in a list.
>
> Although this isn't quite useful (except for multimodal user
> interfaces), the spec allows it.
>
> The problem here is how to know when two events are fired. They won't be
> fired at the same time, so we need to keep a list of all events that
> were fired ...

Exactly, that's how we did it in DISL: We defined event objects that where 
stored
in an event list with the capability of adding and removing events at any 
place. Each
event object should have an identifier, so that we can check for them in the
condition part and explicitly retrieve them from the event list.

As a side note, in DISL we are able to specify user-defined events with some 
nice additional attributes,
namely:
- activated (yes/no) so that an event can be defined and later be activated
- repeat (yes/no) e.g. for timed polling
- timer NMTOKEN for delayed events. The timer starts upon activation and the 
event fires
  after the timer expired

We implemented timed event objects with threads.

> 2) suppose we want to fire an action when a certain checkbox is
> 'checked' (property checked == true)
>
> The problem here is that we need to check the state of the user
> interface. However, the checked property is reflected in the underlying
> final user interface. In our renderer, the value of this property will
> only be made consistent with the concrete widget's value when we
> explicitly demand the value of this property (e.g. <property
> part-name='checkbox' name='checked'/>).
>
> One solution is to constantly poll to update the state of the user
> interface, but is clear that this is not an elegant solution. Especially
> on mobile devices this would pose problems as it would consume too much
> energy (and would drain the battery).
>
> Although one might think there is an event for checking or unchecking a
> checkbox, we can't do this for every property. Suppose we want to fire
> an action when a widget's color is red. There is no event for changing
> the color of a widget.
>
> James, how have you at Harmonia implemented this? Robbie, I suppose you
> solved this through with variables?

A simple solution is to go without events in such a case:
In fact, you also know the color of a widget, as you change the property 
value. Now
in DISL we can specify rules without events and just check if a set of 
properties and
variables contain the right value. This is what I called the "eventless" 
transition in
one of our previous discussions. The current specification allows an 
<op>-Element as
a child of a condition, so the following should be possible.

    <condition>
      <op name="equal">
        <property name="color" part-name="someWidget"/>
        <constant value="red"/>
      </op>
    </condition>

For implementation, we defined interaction cycles which trigger the 
behaviour resolver, so if
some state change occurs, we start a new phase of evaluating all the 
conditions. That's why we don't have to check for specific events per se in 
the rules.

Maybe this could be a way to go for you?

I don't think the spec should be changed here, but maybe we could add an 
explanation, how
eventless transitions could be implemented, at least if all agree with this 
approach.

HTH,
Robbie.
--
   _/ Dipl. Inf. Robbie Schaefer _/ Phone: +49 5251 60-6107  _/
  _/ Visual Interactive Systems _/ Fax: +49 5251 60-6065    _/
 _/ C-LAB Fuerstenallee 11     _/                          _/
_/ D-33102 Paderborn          _/ URL: http://www.c-lab.de _/