Issues to Be Resolved in UIML 4.0

1. How should UIML represent layout

Dr. Luyten pointed out that the UIML 3.0 Specification does not address layout considerations. This lack of attention is intentional as the language designers envisioned the definition of layout constraints as part of vocabulary definition.

2. How do we represent design patterns in UIML

HCI Designs want to be able to use UIML with establish Design Patterns. Should these patterns be made a formal part of the language, or can we use <template> tags to represent them?

3. Should UIML include the notion of variables

DISL contains a mechanism for defining XML-level variables that may be beneficial to UIML. The incorporation of variables has been included in the specification and is discussed in The_<variable>_Element. A <variable> element can be child of the following elements: The_<part>_Element, The_<property>_Element, The_<behavior>_Element, The_<op>_Element, The_<action>_Element, The_<repeat>_Element, The_<iterator>_Element and The_<param>_Element.

4. Should UIML incorporate arithmetic logic

DISL allows the interface definition to include logical statements that can be used to perform basic arithmetic and mathematical operations. These simple arithmetic operations have been added to Semantics_of_<op>, while examples for the use of arithmetic in UIML can be found in Examples_with_variables.

5. Should UIML include Data Models

Dr. Vanderdonckt asked how UIML handles Data Models and differences in data types between versions of a particular widget set. The answer is that at this time, UIML really only has a single data type: Strings. The text values in the UIML are then converted to the appropriate data type by the rendering implementation.

7. How to reduce repetition in the definition of UIs

Many cases exist where very similar UIML elements need to be repeated to fully define a UI. One simple example is a simple calculator interface like the one below (taken from Windows 2000.).

To define the behavior on the number pad would require nine separate rules like the one below (in the Java Vocabulary).

<rule>

• <condition>

  • <event part-name=”Button1” class=”actionPerformed”/>

  </condition>

  <action>

  • <property part-name=”Display” name=”text”>

    • <call name=”utils.concatenate”>

      • <param><property part-name=”Display” name=”text”/></param> <param>1</param>

      </call>

    </property>

  </action>

</rule>

Each of the rules would be exactly the same except for the button name and the second parameter for the <call> element.

7.1 Topics for the committee to discuss

• What other elements besides <part> and <rule> have similar issues?

• How can the amount of UIML be reduced while the richness of the interaction is maintained?

9. Is the <listener> element is general enough

Kris Luyten has pointed out that the notion of an event listener as embodied in the listener element does not apply to his .NET implementation of UIML. Instead a more general element may need to be defined that specifies how events are reported.

10. Should rendering engines reference specific instances of external objects

It is sometimes desirable to have data preserved in the application logic so that the interface can be updates based on past user interaction with the system. Currently this is difficult to achieve as the logic element only specifies the class of object associated with a call element and not the specific instance. This implies that the objects are stateless or static and that the UIML rendering engine will instantiate the object each time the call is made. In order to overcome this, UIML may need a mechanism to specify which instance of an object will be referenced by a specific call. This would allow multiple instances of the same external object to exist within the system and be reference separately.

10.1 Proposed solution

Add an instance-name attribute to the call element to specify the specific object to be called. This requires the UIML rendering engine to maintain a table of objects referenced by unique identifiers that can be referenced in the UIML. A UIML rendering engine should then look up the specific instance in its table and if the object exists then use the one retrieved. If the object does not exist in the table, then a new should be created and entered into the table with the specified identifier. If the instance-name attribute is omitted a “throw-away” object is created to support the call, and is then disposed of.

11. How to access parameterized constructors for widgets and application logic

The current UIML specification assumes that a default implementation exists for each widget and backend component that allows the object to be instanciated without requiring any additional information (a default constructor). This is not always the case, as is evidenced by several widgets in the Java Abstract Windowing Toolkit (AWT). UIML may need a mechanism for specifying constructor arguments at the time the object is created.

12. Should <d-property> tags enumerate acceptable values when there is a constrained set

The d-property element defines which properties can be set on their parent d-class. Sometimes these properties have a limited number of valid values. For example, the property horizontalAlignment accepts the values LEFT, RIGHT, and CENTER. These are represented by integer constants in Java, and thus the d-property definition calls for the int primitive type to be passed as a parameter. This does not give the rendering engine any key from the vocabulary on which to check if the value is valid.

Instead, perhaps the vocabulary file should enumerate the valid values of properties having these special sets. This would allow for easy error checking and for the creation of property sheets in UIML authoring environments.

12.1 Resolution

The <d-param> element has been updated to allow <constant> children. These children enumerate the valid values of the <d-param>. This solution goes beyond th scope of the original issue, in that it allows vocabulary designers to also defined enumerated values for methods defined in the <logic> section as well.

13. How to set properties globally

Should UIML include a mechanism to set global properties?

14. How to set properties on <event> tags when throwing an event

The specification is not clear on how to set properties on <event> tags that represent events to be fired.

14.1 Proposed Solution

Extend the usage of <property> to be able to set properties on events before the event is thrown. Since events can have properties defined in UIML vocabulary files, no special change to <presentation> is necessary. Example

• <action>

  • <event class="ItemSelected" part-name="list">

    • <property name=”selectedItem”>

      • <call name=”listApplication.getSelectedItem”/>

      </property>

    </event>

  </action>

14.2 Affected Sections of the Specification

5.7, 5.7.5, and 5.5.1

14.3 Resolution

The proposed solution has been adopted.

15A When does the <when-false> action of an <op> tag get evaluated

There is an example of the <op> tag in section 5.7.6.1 of the UIML specification that compares the value of a <property> tag and a <constant>. The implied semantics are that whenever the two values are equal the rule will fire. When does this condition get checked? The text seems to indicate that the condition will be checked continuously. Now let us further assume that the UIML author has defined a <when-true> / <when-false> pair in the action corresponding to this <condition>. Does the <when-false> constantly activate until the condition is true? See the code sample below for an example of this issue.

• <condition>

  • <op name="equal">

    • <property name="value" part-name="city"/> <constant value="'Los Angeles'"/>

    </op>

  </condition> <action>

  • <when-true>

    • <property name=”value” part-name=”status”>Arrived</property>

    </when-true> <when-false>

    • <property name=”value” part-name=”status”>Traveling</property>

    </when-false>

  </action>

15A.4 Topics for the TC to discuss

• When should non-event driven <condition> tags be evaluated?

• Should there be a trigger event that is required to evaluate the <condition>?

15A.5 Affected sections of the Specification

5.7.6, 5.7.12, 5.7.13, and 5.7.14

15B. Should sub-elements of <behavior> have id’s and be able to be referenced?

Practitioners have asked that sub-elements of <behavior> have id’s and be able to be referenced from other elements within a behavior. The mechanism desired is similar to defining templates for tags like <condition> and <action>, so that they may be defined once and referenced in multiple places. DISL defines a similar separation.

16. How to restrict access to elements within a <template>

Potential implementers of UIML at the Raytheon Company have requested a mechanism to control which elements in a <template> can be overridden using the how=”cascade” attribute. They would like to be able to define certain elements of a <template> as immutable so that they may be assured that safety and mission critical elements of a user interface will be present in any customized version of the interface. A limited form of this functionality is already described in the UIML 3.x specification in section 7.4. This section describes the export attribute, which can be set on <part> and <property> elements within a template to prevent UIML authors using the <template> from changing properties on a given <part>. No current mechanism is in place that would prevent a UIML author from replacing a <part> within the <template> with one of his or her own.

16.1 Proposed Solution

Extend the export attribute to apply to elements beyond <property>.

16.2 Affected sections of the Specification

7.4

16.3 Resolution

The TC has decided that the current export mechanism is sufficient to resolve this issue.

18. How Do I Affect the Sourcing Document from a Template (Template Parameterization)

This issue is prevalent in interfaces where templates are used extensively for controls. For example, assume that we have a template that consisted of a panel containing two buttons. This panel may be used in several dialogs as "OK/Cancel" buttons or "Yes/No" buttons. In either case, we want the buttons to close the overall dialog containing the panel. Therefore we want to define the behavior of the buttons in the template as well. Currently, UIML does not provide a way for an action in a behavior to affect something except by id, but in our template case, we have no way of knowing the id of the container. We propose adding a method to parameterize the templates so that they can use placeholder id's in the behaviors and then map those id's to the actual sourcing id. This would add a new level of flexibility to the template mechanism and has been requested by users of UIML in industry.

This issue has not been addressed in any of the other User Interface Definition Languages that the TC has investigated and represents new ground to be broken in the field.

Such a mechanism would require dynamic tree operations when used with restructure. The parameters may not be able to be pre-rendered (expanded into the tree) before interaction.

The TC decided that over the next month we will submit proposals for candidate implementations of this in the specification. At the next meeting with will discuss these proposals as part of the Open Issues discussion.

19. Should the UIML Specification Support Optional Template Elements?

Optional elements can be removed by a sourcing document without removing them from the template. This issue involves the deletion of a template component from the sourcing document. For example, suppose we wished to import a button panel that sometimes had three buttons ("OK", "Cancel", and "Apply") and sometimes only two ("OK" and "Cancel"). In this case, the third button is optional. Currently we would have to define two separate templates to handle the two cases above, but it would provide better modularity and less redundancy to define one template with an optional part.

20. Should Template Content Be Distinguished by the Tag?

Dr. Luyten made the suggestion that the UIML specification may need to be changes so that templates could be distinguished by what they contain. Thus instead of a single generic <template> tag, we could have multiple <style-template> or <behavior-template> tags. Such a separation would be more readable and easier to implement in a rendering engine. This will also be added to the Open Issues for further discussion.

21. Should the UIML specification have both <equal> and <op>

The <equal> tag and the <op name=”==”> tag seem redundant. Both are used within a <condition> to check for an equality of values.

Example

The two snippets of UIML code below are equivalent.

Snippet 1:

• <condition>

  • <op name="==">

    • <property name="value" part-name="city"/> <constant value="'Los Angeles'"/>

    </op>

  </condition>

Snippet 2:

• <condition>

  • <equal>

    • <property name="value" part-name="city"/> <constant value="'Los Angeles'"/>

    </equal>

  </condition>

21.1 Proposed Solution

Remove the <equal> tag from the language and adhere to the more general <op> tag usage.

21.2 Affected sections of the Specification

5.7.4, 5.7.6, 3, and the UIML DTD and/or Schema. Note also that numerous examples containing <equal> will have to be updated.

23. Where should the “name” Attribute be replaced and where kept

The following elements of UIML still use the “name” attribute:

• <call>

• <event>

• <param>

• <property>

• <meta>

• <op>

These should be reviewed to determine if the “name” attribute should be replaced with “id”.

23.1 Affected sections of the Specification

5.7.8, 5.7.5, 5.7.15, 5.5.1, 4.2.1, and 5.7.6

23.2 Resolution

poo <call> - name has been replaced with component-id and method-id for clarity
<event> - pending
<param> - pending
<property> - pending
<meta> - pending
<op> - pending

Issues Postponed to UIML 4.1

Should UIML include the definition of transforms in the specification

USI-XML includes the notion of defining transforms as part of the language. Should UIML also include this?

How to handle multiple return values

The current UIML specification allows only one return value from a call to a backend application logic component. In some cases a backend component may modify several values and return the results via reference variables passed as parameters. Should UIML allow the definition of input and output variables or rely on the adapter layer of the UIML architecture to break such calls into single return methods?

How to programmatically generate segments of UIML

Members of the OASIS TC have commented on the benefit of having UIML programmatically generated by a piece of application logic. This would allow more flexible generation of dynamic user interfaces. On the other hand, the programmatic definition of UIML has to potential to break down the separation of presentation and business logic enforced by the UIML approach.

A failed solution: the code attribute

At one time, Harmonia, Inc. attempted to modify UIML to include a code attribute on <part> elements. This attribute specified a Java Object that would be invoked to produce a UIML <template> that would replace the <part> specifying the attribute.

This solution was abandoned for several reasons:

• UIML documents containing code attributes could not be cached. The UIML returned by objects specified by the attribute was defined in a generic vocabulary, which needed to be re-rendered each time the code attribute was invoked. This made it impossible to reduce the time to render via caching and made UIML an inefficient solution.

• The function of the code attribute was primarily to provide a mechanism for returning an unknown number of records from a database. This functionality was better solved by the creation of the <repeat> and <iterator> elements. These elements provide the same functionality in a more efficient way and require no additional Java objects to be written.

Should UIML include inheritance within d-classes and templates

Jo Vermeulen pointed out through the UIML public comment form that UIML could benefit from an inheritance mechanism for designing vocabularies. The extent and scope of the inheritance capability is now in the hands of the UIML TC. At a minimum, a mechanism that allowed the basic inheritance of properties, events, and listeners would reduce the amount of work required to define a vocabulary.

Proposed solution

A basic inheritance capability could be realized by adding an extends attribute to the d-class element. This attribute’s value would reference the id attribute of a separate d-class. The extending element would then gain all the events, d-properties, and listeners defined on the referenced d-class and any additional elements defined as children of the extending element will be cascaded with the elements being pulled from the referenced element.

The current template functionality provides a basic mechanism for realizing inheritance. In the example given above, a UIML author could define the base d-class in a template and cascade the template onto another d-class to achieve the same goal. The TC will discuss whether this mechanism is sufficient or whether a stronger notion of inheritance is necessary.

How should <template> elements address components within other <template> elements

The UIML specification does not address the case where two templates are sourced from the same UIML document but contain information that affects the other template. A simple example is given below. <uiml>

• <interface>

  • <structure>

    • <part class=”JFrame”>

      • <part id=”part1” source=”#partTemplate” how=”replace”/>

      </part>

    </structure> <style source=”#styleTemplate” how=”replace”/>

  </interface>

  <template id=”partTemplate”>

  • <part class=”JLabel” id=”label/>

  </template>

  <template id=”styleTemplate”>

  • <style>

    • <property name=”text” part-name=”label”>Hello World</property>

    </style>

  </template>

</uiml>

Note that the above UIML would not result in a JFrame containing a JLabel that read “Hello World”. This is due to the fact that the <part> named “label” will be re-named when the template is included in the sourcing tree. This problem is compounded when the <template> elements are accessed outside of the sourcing UIML document and potentially written by separate authors.

Topics for the TC to discuss

• Should there be a shorthand way of referencing elements in <template> tags?

• Should implementations of the language do an ordered search for element id’s to avoid having to know the fully qualified name of an element within a <template>? For example, look first in the sourcing document and then examine each sourced branch of the tree that represents content of a <template>.

Affected sections of the Specification

7.1

How many children should <d-property> tags be allowed

The definition of <d-property> is unclear. It seems that a <d-property> should only ever have two children: a setting method and a getting method. The current definition of <d-property> allows for an unrestricted number of <d-method> or <d-param> children to be defined. There is also no clear indication in the definition of a <d-property> as to which child is the setting method and which is the getting method. A separate sub-issue here is whether it is ever appropriate for <d-param> to be a child of <d-property>.

Topics for the TC to discuss

• Should <d-property> ever have more than 2 children?

• Should an explicit mechanism be built into the definition of <d-property> to identify which child is the getting method and which is the setting method.

• Is <d-param> a valid child of <d-property>?

Affected sections of the Specification

6.4.3