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



From: Jo Vermeulen 

To: Robbie 
Schaefer 

Cc:  

Sent: Friday, April 13, 2007 12:03 PM

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

On 4/11/07, Robbie Schaefer <> wrote:

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

[snip] 

Sorry Robbie, after going through it again, I overlooked 
a few things. Here are my comments ... 

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

Well this is not completely true I guess, since some properties have 
default values ( e.g. the color of a widget). Of course you could get all 
possible properties defined in the vocabulary on startup, but that would again 
be resource intensive ...
 
I can also believe a property could be 
changed without setting the property explicitly in UIML. Suppose the underlying 
widget set alters a certain property? 

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>

Indeed, that was also how we thought about it ...

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?

That might be an option, but again you need to know when something 
changes ...

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.

Indeed, when we 
reach a consensus that would be a good thing to put in the spec. Maybe having 
multiple events in a condition (chained together through <op>) should be 
cleared out as well? 

P.S.: For anyone wanting to reply, please put my 
email address in there as well, since I am not on the uiml-list :-)

Best 
regards,

-- Jo