Blacksburg 
Computer Science Department, Virginia Tech
USA | Using XML in a generic model of mediators | Table of contents | Indexes | Evaluating Content Management Systems Based on Information Chunk Size | |||
| Abrams, Marc Blacksburg Computer Science Department, Virginia Tech USA | Marc Abrams |
| Associate Professor |
| Computer Science Department, Virginia Tech |
| Mail Code 0106
Blacksburg
(Virginia)
USA
(24061)
Email: Abrams@vt.edu |
| Biography |
| Blacksburg Phanouriou, Constantinos USA Universal Interface Technologies | Constantinos Phanouriou |
| Ph.D. Candidate |
| Universal Interface Technologies |
| P.O.Box 0825
Blacksburg
(Virginia)
USA
(24063-0825)
Email: phanouri@universalit.com |
| Biography |
| UIML User Interface XML handheld devices mobile devices | Constantinos Phanouriou is a Ph.D. candidate in Computer Science at Virginia Tech. He is also a co-founder of Universal Interface Technologies and co-developed the User Interface Markup Language, UIML. His research focuses on markup languages for user interfaces. |
Abstract |
Introduction |
Problems faced by UI Implementers |
Markup Languages for Graphical User Interfaces (GUIs) |
Markup Languages for Handheld and Wireless |
WML | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Markup Languages for Voice |
VoiceXML | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Device-Independent Markup |
Terminology |
User Interface Markup Language |
UIML - Purpose |
Deploying UIML |
| A UIML document can be used in one of several ways. First, it can be stored on a server (see Figure 1). When a user invokes an application, the UIML document either is compiled to a target platform's language (e.g., to WML, or to C++), or it is interpreted while the user interacts with the interface. Interpretation is what a Web browser does with HTML. Compilation on the server side is mandatory for devices that cannot download applications, such as cellular phones, and where memory is limited. Interpretation is more flexible; for example our Java interpretive renderer permits the entire UIML interface to appear as a Java bean, so that the interface may be manipulated programmatically by the application logic. UIML can also be used without a server; in this case UIML or the compiled code or markup language is installed along with the application logic on end-user devices. At runtime, the rendered interface directly communicates with the application logic. |
| An advantage of running an interpreter on the client side is that it avoids the need to send bulky executable code to devices. For example, Java applets today are time consuming to load over the Internet. In contrast, a Java interpretive renderer installed on a desktop computer requires only UIML to be transmitted over the Internet. UIML is a small text file compared to the equivalent executable code, just as a form in HTML requires less bytes than a Java applet implementing the same form. |
| Another advantage of sending UIML instead of executable code over networks is security. UIML is a declarative language, which means it describes what needs to happen but not how it happens. Thus, UIML itself, like HTML, is less likely to contain a virus or launch an attack on a client than executable code. However, scripting or interconnection to application logic used with UIML (just as HTML used with client scripting or CGI scripts) is vulnerable to viruses or attack. |
UIML - Main Elements |
| There are five main elements in a UIML document: |
|
UIML as a meta-language |
| UIML can be viewed as a meta- or extensible language, analogous to XML. UIML does not contain tags specific to a particular user interface toolkit (e.g., <WINDOW> or <MENU>). Instead, it uses a set of generic tags (e.g., <part>, <property>). |
| As discussed earlier, UIML captures the elements that are common to any user interface: an enumeration of the user interface parts, events that occur for those parts, presentation style, content, and interconnection to application logic. The UIML author specifies instance and class names of their own choice for interface parts and events. These names are mnemonics for the interface implementor. The UIML document specifies a mapping of those names to a vocabulary specific to a particular target platform. For example, if the target is Java AWT, the vocabulary might consist of the java.awt and java.awt.event class names, such asFrame , Menu , and Button . If the target is WML, the vocabulary might be tag names, such ascard . The vocabulary of target platforms is not a part of UIML. That vocabulary only appears in UIML as the value of attributes in UIML. Thus UIML only needs to be standardized once, and different constituencies of users can define vocabularies that are suitable for various toolkits independently of UIML. In addition to creating vocabularies for particular toolkits (e.g., Java AWT), a vocabulary for a generic classes of toolkits (e.g., mapping to any graphical user interface) could be devised. Or new vocabularies can be defined as new devices and user interface technologies are created in the future. |
| To illustrate, the interface implementor might write this in UIML: |
<part name="Line" class="MenuItemOrIcon"> |
| The nameMenuItemOrIcon is a mnemonic because the implementor is thinking that this class of parts could be rendered as a menu item or as an icon in two different presentations. But they could have used any name in place ofMenuItemOrIcon . In one presentation of the interface using Java AWT, the style element may then map this to a java.awt.MenuItem as follows: |
<style>
<property class="MenuItemOrIcon" name="rendering"
value="MenuItem" />
...
</style>
|
| A UIML document also includes an element, called peers , that enumerates the mapping from property values to specific tags or objects in the target platform: |
<peers>
<presentation name="Java-AWT">
<component name="MenuItem" maps-to="java.awt.MenuItem">
</presentation>
...
<peers>
|
| To summarize, UIML uses three levels of names for interface parts and events. The first is chosen by the UIML author. The second name is in the style element and maps the mnemonic to an abstract widget name (e.g., MenuItem). The second level allows a mapping from one abstract set of names (e.g., "BigWindow") to multiple platforms (e.g., MFC or Java Swing) without modifying the rest of the interface description. Finally, the third name in thepeers element is part of a toolkit-specific vocabulary and maps the abstract widget name to a name of a widget from the target platform (e.g., java.awt.TextField). |
UIML Architecture |
| Here is a skeleton of a UIML document: |
<?xml version="1.0"?>
<!DOCTYPE uiml PUBLIC
"-//UIT//DTD UIML 2.0 Draft//EN"
"http://uiml.org/dtds/UIML20.dtd">
<uiml>
<head> <meta> ... </meta> </head>
<peers>
<presentation> <component> ... </component> </presentation>
<logic> <component> ... </component> </logic>
</peers>
<template> ... </template>
<interface> ... </interface>
</uiml>
|
| Thehead element contains metadata about the current UIML document. Elements in the head element are not considered part of the interface, and have no effect on the rendering or operation of the user interface. The peers element contains the mappings between abstractions in the interface description (i.e., interface parts, properties, events, and methods) and their actual implementations (i.e., toolkit widgets and attributes, platform events, and application logic components). This element specifies the vocabulary for toolkits to which UIML is mapped. Thetemplate element allows reuse of interface elements. When an element appears inside a template it can be included ("sourced") elsewhere in a UIML document. Finally, theinterface element contains the interface description. For complete description of all the UIML elements and syntax, please see UIML 2.0 [9]. |
| Here is a skeleton of the interface element: |
<interface> <structure> <part> ... </part> </structure> <style> <property> ... </property> </style> <content> <constant> ... </constant> </content> <behavior> <rule> ... </rule> </behavior> </interface> |
| Thestructure element enumerates a set of interface parts and their organization for various platforms and devices. Thestyle element defines the values of various properties associated with interface parts. The content element associates words, sounds, and images with interface parts to facilitate internationalization or customization for different user groups. Finally, the behavior element enumerates a set of rules that describe how the user interface should react on different stimulus (i.e., from user, device, or the application logic). |
| The syntax used to define style in UIML has undergone evolution. The first version of UIML [8] used CSS-like style elements. However, there were certain assumptions in CSS versus UIML that did not fit each other. First, the CSS property catalog is biased toward HTML's printed page model. Second, CSS implements inheritance according to the structure of a document as represented by the HTML tree. In contrast, there are two representations of a user interface in UIML: logical and physical. The logical representation is the tree represented by thestructure element. The physical representation exists when UIML is either interpreted or compiled to a target platform. The target platform may have inheritance rules of its own. For example, font settings may or may not be inherited by components that are added containers in various GUI toolkits. After profiling performance of our own UIML rendering engine for Java, we found that enforcing a CSS inheritance produced a significant run-time expense. Third, CSS specifies the properties of tags in an HTML document. In contrast, UIML is a meta-language, and the tags have no properties. Instead the attributes ofname and classes in UIML are associated with style. Finally, there is the aesthetic consideration that CSS uses a dissimilar syntax to XML. For these reasons, we abandon CSS in the UIML2 specification. |
| Another option was to use XSL. XSL's vocabulary for specifying formatting semantics is again biased toward the printed page model of HTML. For example the formatting objects are things like "page-number" and "table-row", and XSL's formatting model is defined in terms of rectangular areas and spaces. This does not fit UIs on all devices (e.g., voice-based UIs). UIML is device-independent and the page model is only one of many possible renderings for a user interface. Thus if we used XSL (or CSS) we would be faced with adding new vocabularies to fit different types of devices. That could be done, but it would not be part of the CSS and XSL specs, unless those specs were modified. Having said all this, it may be useful if one could still choose to use a CSS or XSL style sheet with a UIML document, for example if one is mapping UIML to HTML. |
| The remaining section is the behavior element: |
<behavior>
<rule>
<condition>
<event .../>
</condition>
<action>
<property ...> ... </property>
<method ...> ... </method>
<event ...> ... </event>
</action>
</rule>
...
</behavior>
|
| The behavior element contains one or more rules. Each rule consists of a condition, triggered either when an event occurs, or when an event occurs and an attribute of the event has a specified value. When triggered, the action associated with the condition is executed. The action could change the property of interface parts, invoke a function in a script, or call a function or method in the application logic. |
Reusable Interface Components |
| UIML enables interface implementors to reuse parts or their entire user interface with the template element. For example, many UIs for electronic commerce applications include a credit-card entry form. If such a form is described in UIML as a template, then it can be reused multiple times either within the same UI or across other UIs. This reduces the amount of UIML code needed to develop a UI and also ensures a consistent presentation across enterprise-wide UIs. Users tend to make fewer mistakes and are more efficient when presented with familiar UIs. |
| Here is an example of a template for a simple credit card entry form (see Appendix for full example): |
<template name="CreditCard">
<part name="CreditContainer" class="CreditDialog">
<style>
<property name="title">Credit Card Entry Form</property>
</style>
<part name="CreditNum" class="number"/>
<part name="AcceptNum" class="Accept">
<style>
<proprety name="content">Accept</property>
</style>
</part>
</part>
</template>
|
| A template element is like a separate branch on the UIML tree (think of a DOM tree [13]). A template branch can be joined with the main UIML tree anywhere there is a similar branch (i.e., the first and only child of template must have the same tag name as the element on the UIML tree where the joined is made). The interface implementor has three choices on how to source the template element with another element, illustrated in Figure 2. The first choice is "replace." All the children of the element on the main tree that sources the template are deleted, and in their place all the child nodes of the template element are added (see Figure 2a). The second choice is "append." All the children of the element on the main tree that sources the template are kept, and all the child nodes of the template element are added then to the list too (see Figure 2b). To avoid name conflicts, the names of the child nodes of the template element are appended with the name given to the template before they are added (e.g., name = "templateName.originalName"). The last choice is "cascade." This is similar to what happens in CSS. The children from the template are added to the element on the main tree but if there is a name conflict (e.g., two elements with the same name), then the child of the element on the main tree is retained (see Figure 2c). |
| Here is an example of a UIML fragment that uses the above template (assume the template is stored in a file called templates/credit.uiml on an HTTP server): |
<structure>
<part ...>
...
<part name="MyCredit" how="replace"
source="http://server/templates/credit.uiml#CreditCard"/>
</part>
</structure>
<style>
<property name="rendering"
part-class="MyCredit.CreditDialog">Dialog</property>
</style>
|
| In the above example, if the template was in the same file as the interface description, then source would be set to "#CreditCard". Elements inside a template can source other templates. |
| The elements inside the template are accessible from the element that sources them. Thus, you can specify style, content, and behavior information for the template and in effect customized it. In the above example, the rendering property for the dialog in the template was described outside the template. |
Mapping UIML to the target device |
| As mention earlier, UIML does not contain any device-specific information, thus cannot be rendered as is. The peers element provides mappings from interface elements to actual device-specific components that can be rendered (presentation) or executed (logic). |
| Here is an example for mapping the above credit card dialog to Java AWT, WML, and VoiceXML: |
<peers>
<presentation name="WML">
<component name="Dialog" maps-to="wml:card"/>
</presentation>
<presentation name="VoiceXML">
<component name="Dialog" maps-to="vxml:form"/>
</presentation>
<presentation name="Java-AWT">
<component name="Dialog" maps-to="java.awt.Dialog"/>
</presentation>
</peers>
|
| A nice feature in having the user interface generated from UIML is that you can achieve a similar looking interface across platforms (e.g., enforce the same look-and-feel for an application and override the underlying environment) by suitable setting of style properties and peers. Alternately, you could achieve a totally different looking interface on the different platforms or devices (e.g., a text-based vs. graphical on a PC device). |
Dynamic Interface Components |
| Dynamic Interfaces are interfaces that are generated on-the-fly and are usually custom-made for each user or device. There are two reasons why dynamic interfaces are becoming very popular. First there is a plethora of devices available in the market today and users maybe accessing an application with anyone of them. To make things worst, there is a plethora of technologies available for each device. For example, HTML is enhanced with EcmaScript, Java applets, VRML, and other plug-in technologies. User devices usually support only a small subset of them. Second, commercial applications today offer an enormous amount of functionality but individual users access only a fraction of them. Also, certain functionality may need to be restricted to certain user groups only (e.g., administration tasks), handicapped users may require accessibility features, internationalization requires different vocabularies, etc. |
| UIML elements | In UIML there are two ways in which the user interface can be tailored to the device/end user. First, using multiple structure/style/content/behavior sections gives several alternatives to the user. At runtime, the user may specify the names of each section they want to use (e.g., a simple structure with a graphical style and Greek content) and get a custom interface. Second, UIML can be dynamically generated from a database (see Figure 3). An interface server can query the client for a list of device features and/or user preferences and dynamically generate the UIML code for the interface from a database query. The user gets a tailored UI that takes advantage of the technologies supported by the device without overloading the network or the device with unsupported code. |
|
Conclusions |
| In this new world of many interface technologies on many types of appliances, it is too time consuming to hand-code a user interface for each appliance. This motivated the development of the User Interface Markup Language (UIML) to describe user interfaces in an appliance-independent manner. UIML is rendered into a usable interface on an appliance either through interpretation or compilation to another markup or programming language. The renderer might be an application installed on the client, a Web browser plug-in, or a compiler on a server. |
| UIML permits a very abstract description of a user interface, which is then mapped with style elements to a particular device. A challenge in the design of a general-purpose language like this is to balance the expressive power of the language with simplicity. UIML 2.0 has a limited number of tags and are listed in Table 1. |
| One design point that often raises questions in UIML is why the language uses its own style sheets instead of CSS or XSL. The reasons were discussed earlier. But our experience has led us to the following conclusion: It would be better if the W3C's style sheet standards were meta-languages . By this we mean that the CSS and XSL specifications would be more powerful if the vocabulary for formatting objects and style properties wasnot part of the specification. In this way the style sheets could be adapted to any type of device without modifying the core CSS and XSL specifications, to permit use on user interfaces available today or invented in the future. |
| The latest version of the UIML 2 specification is available in [9]. To learn more about UIML, or to obtain the source code and executable of a rendering engine that interprets UIML to create Java AWT and Swing interfaces, see the examples and tutorials available at uiml.org. |
References |
|
Appendix. A Complete UIML Example |
| Figure 4 shows two possible renderings of the credit card template. On the left is a Java-AWT dialog and on the right is a WML card. |
| Given below is the complete UIML document used for the example in the body of this paper. |
<?xml version="1.0"?>
<!DOCTYPE uiml PUBLIC
"-//UIT//DTD UIML 2.0 Draft//EN"
"http://uiml.org/dtds/UIML20.dtd">
<uiml>
<head>
<meta name="Description"
content="Use of templates for CreditCard entry form"/>
<meta name="Author" content="Constantinos Phanouriou"/>
<meta name="Email" content="uiml-editor@uiml.org"/>
</head>
<peers>
<presentation name="WML">
<component name="Dialog" maps-to="wml:card"/>
<component name="TextField" maps-to="wml:input"/>
<component name="Button" maps-to="wml:DO type='ACCEPT'"/>
<component name="InputEvent"
maps-to="wml:event type='onenterforward'"/>
</presentation>
<presentation name="VoiceXML">
<component name="Dialog" maps-to="vxml:form"/>
<component name="TextField" maps-to="vxml:prompt"/>
<!-- Button does not have a rendering in Voice -->
<component name="Button" maps-to="E;/>
<component name="InputEvent" maps-to="vxml:filled"/>
</presentation>
<presentation name="Java-AWT">
<component name="Dialog" maps-to="java.awt.Dialog"/>
<component name="TextField" maps-to="java.awt.TextField"/>
<component name="Button" maps-to="java.awt.Button"/>
<component name="InputEvent"
maps-to="java.awt.event.ActionEvent"/>
</presentation>
<logic name="HTTP">
<component name="CreditApp">
<method name="SendCredit"
maps-to="http://<server>:port/cgi-bin/acceptCredit.pl?">
<param name="cnum"/>
</method>
</component>
</logic>
<logic name="Java">
<component name="CreditApp" maps-to="myBiz.creditApp.class">
<method name="SendCredit" maps-to="acceptCredit">
<param name="cnum"/>
</method>
</component>
</logic>
</peers>
<template name="CreditCard">
<part name="CreditContainer" class="CreditDialog">
<style>
<proprety name="title">Credit Card Entry Form</property>
</style>
<part name="CreditNum" class="number"/>
<part name="AcceptNum" class="Accept">
<style>
<proprety name="content">Accept</property>
</style>
</part>
</part>
</template>
<interface>
<structure>
<part name="ECommerceApp">
<!-- UI description -->
<part name="MyCredit" source="#CreditCard"/>
</part>
</structure>
<style>
<property name="rendering" part-class="MyCredit.CreditDialog">
Dialog</property>
<property name="rendering" part-class="MyCredit.number">
TextField</property>
<property name="rendering" part-class="MyCredit.Accept">
Button</property>
<property name="rendering" event-name="InputEvent">
InputEvent</property>
<property name="rendering" method-name="SendCredit">
SendCredit</property>
</style>
<behavior>
<rule>
<condition>
<event name="InputEvent" part-name="MyCredit.AcceptNum"/>
</condition>
<action>
<method name="SendCredit">
<param name="cnum">
<property name="content"
part-name="MyCredit.CreditNum"/>
</param>
</method>
</action>
</rule>
</behavior>
</interface>
</uiml>
|
| Using XML in a generic model of mediators | Table of contents | Indexes | Evaluating Content Management Systems Based on Information Chunk Size | |||
