Proposal for Modification of Syntax for <rules> in UIML

Send comments to Sumanth Lingam (mailto:sumanth@harmonia.com)
6 February 2001

Reasons for Revision

In UIML, the behavior of a user interface (e.g., what happens when a button is pressed) is described by the <behavior> element. The <behavior> element is patterned after rule-based systems. The <behavior> element contains <rule> elements. Each <rule> contains a <condition> and an <action>. When a <condition> for a <rule> is true, an <action> is executed.

Until now in UIML (e.g., until the current UIML DTD, named UIML2_0d.dtd), the <condition> was limited to one of two cases:

• The <condition> holds when an event fires.
• The <condition> holds when an event fires, and one property of the event equals some constant value.

Here is an example:

<rule>
  <condition>
    <equal>
      <event part-name="List"
	  class="itemStateChanged" name="item"/>
      <constant  value="0"/>
    </equal>
  </condition>
  <action>
    <property part-name="DefnArea"
	name="text">Carnivorous, domesticated mammal
	that's fond of rats and  mice</property>
  </action>
</rule>

In the above example, which uses the Java AWT/Swing vocabulary with UIML, the condition holds true if the user selects the 0-th element of a list. (More precisely, the condition holds when the event type 'itemStateChanged' associated with part 'List' occurs and the value of the property 'name' is equal to constant value '0', the <action> element is executed.)

Obviously UIML needs a richer syntax to express a variety of conditions involving arbitrary expressions. For example, the <behavior> section might need to represent a finite state machine (FSM), where each condition is based on the state of various UI components, and the current state in the FSM. Moreover, in keeping with the extensible philosophy of UIML, the expression operators that can be used with UIML should be extensible. This need is addressed in this proposal.

Before discussing the proposed changed to UIML, one comment must be made. It is very tedious to express complex expressions in pure XML. There must be one XML element for every operator in the expression. Meanwhile a UIML author would probably want to write algebraic expressions like x==4 && y==2. This will be addressed by allowing the use of algebraic expressions in UIML shorthand, and then letting the shorthand parser expand algebraic expressions in pure XML used by UIML (the non-shorthand version).

New Element <op>

In UIML, to be able to validate complex conditions and specify multiple operations on the properties of the parts when an event occurs, a new element <op> could be introduced. <op> stands for operation. The construct of <op> is similar to that of <apply> tag in MathML. Here is an example:

<condition>

    <event name="Filled" part-name="city"/>
    <op name="&&">
       <op name="==">
        <property name="value" part-name="city"/>
 <constant name="city" type="string" value="'Los Angeles'"/>
     </op>
    <op name="==">
         <property name="value" part-name="state"/>
      <constant name="state" value="undefined"/>
    </op>
 </op>

</condition>

The UIML condition above evaluates to true if three items are satisfied:

• the "Filled" event occurs on a part named "city" and

• the "value" property of the event is equal to "Los Angeles"

• the "value" property of the event is equal to "undefined"

As a test of the expressive power of the proposed syntax, we'll consider VoiceXML in several places in this document. Here is the equivalent VoiceXML is the following:

<filled>
     <if cond="city =='Los Angeles'&amp;&amp;
 state ==undefined">
       <assign name="state" expr="'California'"/>
    </if>
</filled> 

Proposed Change to UIML DTD to Add <op>

The proposed modification to the UIML DTD is the following: (Yellow highlighted text denotes changes from UIML2_Od.dtd.)

<!ELEMENT    condition (equal|event|op)>   

<!ELEMENT    equal (event,(constant|property|reference|op))>

<!ELEMENT    equal (event,(constant|property|reference|op))>   

<!ELEMENT    property ((#PCDATA|constant|property|reference|call)*|op)>   

<!ELEMENT    param ((#PCDATA|property|reference|call)*|op)>

<!ELEMENT    op (constant|property|reference|call|op)*>

<!ATTLIST    op
             name CDATA #REQUIRED>

Examples of Use of <op>

Here is an example of the use of this syntax:

<condition>
  <op name="&&">
    <event part-name="xxx" class="yyy"/>
    <op name="zzz">
      ...
    </op>
  </op>
</condition>

The above construct evaluates to true when two things hold:

• the event yyy on the part with name xxx occurs AND
• the operation rooted at zzz is true

Here is a second example construct:

<condition>
  <equal>
    <event part-name="xxx" class="yyy" name="aaa"/>
    <op name="zzz">
      ...
    </op>
  </equal>
</condition>

The above construct evaluates to true when means when event yyy occurs for the part with name xxx and the value of event property "AAA" is equal to the value of operation "zzz". This could be equivalently written as:

<condition>
  <op name="==">
    <event part-name="xxx" class="yyy" name="AAA"/>
    <op name="zzz">
      ...
    </op>
  </op>
</condition>
<condition>

Here is a third example, which holds when event yyy occurs for the part with name xxx.

<condition>
  <event part-name="xxx" class="yyy"/>
</condition>

The<event> element can occur more than once in a <condition>. However, all uses must refer to the same event, so that a single event triggers evaluation of the condition. Therefore all <event> elements inside a <condition> must be identical in their attribute values, except for the name attribute. Here is an example:

<condition>
  <op name="==">
    <event part-name="Icon6" class="mouseDown" name="X"/>
    <event part-name="Icon6" class="mouseDown" name="Y"/>
  </op>
</condition>

In the above construct, when the event called mouseDown occurs for the user interface part named Icon6, the <condition> evaluates to true if the X and Y values of the mouseDown are equal. (Perhaps X and Y denote the X and Y coordinates of the mouse position when a mouse button is pressed.)

New Elements <when-true>, <when-false> and <by-default>

In the <action> element, the set of actions mentioned are performed if the condition specified in <condition> evaluates to true. But there is no simple construct to specify a set of actions to be performed if the condition is false or the default actions. <when-true> is equivalent to 'if the condition is true', <when-false> is equivalent to ' else' or ' if the condition is false'. <When-true> and <when-false> could be used only if the 'else' operation is required. Otherwise the list of actions to be performed could be mentioned as sub-elements of <action> implying that these are the default list of actions to be performed when the condition is true. Also to be noted is that the <op> element could be used to specify complex operations inside <action> element. For example:

<action>

  <when-true>
    <restructure at-part="confirm_exit" how="append" where="last">
      <template>
        <part name="ok"  class="Speech"/>
          <property name="content" >Okay, but the U.S. State
          Department is displeased.</property>
        </part>
      </template>
    </restructure>
    <event name="exitform" class="exit">
	</when-true>
 
  <when-false>
    <restructure at-part="confirm_exit" how="append" where="last">
      <template>
        <part name="OK"  class="Speech">
          <property  name="content" >Good, let's pick up where we le
          off.</Property>
        </part>
      </template>
      </restructure>
  </when-false>

</action> 

The equivalent VoiceXML is shown below.

<if cond="confirm_exit">
  Okay, but the US State Department is displeased.
  <exit/>
  <else/>
  Good, let's pick up where we left off.
</If>

Proposed Change to UIML DTD to Add <when-true>, <when-false>, <default>

The corresponding dtd modification is shown below.

<!ELEMENT    condition (equal|event|op)>   

<!ELEMENT    equal (event,(constant|property|reference|op))>

<!ELEMENT    action ((property|call)*, event?,
restructure?,op?)|(when-true?,when-false?,by-default?))>

<!ELEMENT    when-true ((property|call)*, event?,restructure?,op?)>   

<!ELEMENT    when-false ((property|call)*, event?,restructure?,op?)>   

<!ELEMENT    by-default ((property|call)*, event?,restructure?,op?)>   

<!ELEMENT    restructure (template)*>

<!ATTLIST    restructure
             at-part NMTOKEN   #REQUIRED
             how              (append|cascade|replace)  "replace"
             where            (first|last|before|after) "last"
             where-part       NMTOKEN                   #IMPLIED
             source           CDATA                     #IMPLIED>

Summary of Proposed Changes

• Introduced new Element <op>

• Added <op> as sub-element to <condition>

• Added <op> as sub-element to <param>

• Added <op> as sub-element to <property>

• Added <op> as sub-element to <action>

• Added <when-true> as sub-element to <action>

• Added <when-false> as sub-element to <action>

Acknowledgment

The suggestion to add <op name="..."> was made by Tim Thomas of Xerox.

© 1999-2001 UIML.org (all rights reserved)