FW: Implementation specifics for UIML behavior rules

["James Helms" <jhelms@harmonia.com>]

 Hello all,

This just came in from one of Kris's colleagues and I thought it was
appropriate to post to the list.  

Thanks!

James Helms

Director of Research and Development
Harmonia, Inc. 
P.O. Box 11282
Blacksburg, VA 24062

Office: (540) 951-5900 x 205
Cell: (540) 558-9722



-----Original Message-----
From: Jo Vermeulen [mailto:jo.vermeulen@uhasselt.be] 
Sent: Tuesday, April 10, 2007 11:00 AM
To: James Helms
Cc: Marc Abrams; Robbie Schaefer; Kris Luyten
Subject: Implementation specifics for UIML behavior rules

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:

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

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?

I would appreciate any insights on working implementation strategies for
this part of the specification. And of course, it would be good to
clarify the spec as well :-)

Thanks in advance!

Best regards,

--
Jo Vermeulen
Expertise Centre for Digital Media - Hasselt University Wetenschapspark
2 3590 Diepenbeek, Belgium
tel: +32 (0)11 268411
email: jo.vermeulen@uhasselt.be
http://jozilla.net/

signature.asc