RE: Comments on the flexible behavior proposal

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

Thank you Robbie for your comments,  I have copied some of them here for
convenience of discussion.

>> I would rephrase this as "Each rule must contain an <event> tag as a
first level child or a <condition> tag containing at least one event.
These events (or the single event which was the first level child)
represent the reason for firing the rule." We could then speak of either
a trigger event or multiple trigger events. <<

I very much want to get away from putting <event> tags inside of
<condition> tags.  We have run into considerable trouble implementing
complex conditions when this is the case.  I do see a need for detecting
multiple events together.  How about this as an alternative:  What if we
allow multiple <event> children of rule that are related by an implied
"and".  Thus if we had two <event> children of a <rule>, both events
would need to fire before the rule is triggered.  We would need to
define rules for what it means for two events to be fired at the same
time though...


>>Important: If the rule would not allow for conditions as a first level
child, none of the examples with variables would work, since they
typically check the condition together with variable states and only
then may fire. <<

Let me make sure I understand what you mean here.  The variable examples
detect an event and then check a variable value to determine if a rule
should fire, correct?  If that is the case, then the flexible behavior
proposal does cover these circumstances.  Consider the following UIML
snippet:

<rule>
  <event part-name="Button1" class="ButtonClicked"/>
  <condition>
    <op name="equals">
      <variable id="clickCount/>
      <constant value="2"/>
    </op>
    <action>
      ...do stuff...
    </action>
  </condition>  
</rule>

This structure is legal under the initial proposal, and implies a
semantic "and" relationship between the <event> and <condition>.  So in
order for the <action> contained in the <condition> to be executed, the
event would need to fire and the condition would need to evaluate to
true.  Does this cover the case you are referring to?

>><action> elements retain the same description and purpose that they
had in the UIML 3.1 specification, but they may now contain a
<condition> child as the last child in the <action> specification.  This
is used to chain conditional statements together while allowing actions
to occur in between. For this specific part, an additional example would
be welcome...<<

I'll work one up! 
  
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: Robbie Schaefer [mailto:robbie@c-lab.de] 
Sent: Tuesday, January 30, 2007 4:15 AM
To: James Helms; kris.luyten@uhasselt.be
Cc: vanderdonckt@isys.ucl.ac.be; Heinz Josef Eikerling
Subject: Comments on the flexible behavior proposal

Hi all,

since I was not quite ready before our last telephone conference, I
would like to comment further on James' flexible behavior proposal.
For me the main point is, that a condition (containing also the
"trigger") may be a first-level child of a rule as well. I marked the
changes in blue. Furthermore I discussed an example for transitions
based on values only, and how events could be used either explicitely
for this or how the UIML-render logic could take care.
Feel free to ask me questions if something is not clear.

All the best,
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 _/