UIML and XForms

Subject:   [uiml-discuss] UIML and XForms
From:      James Helms <jhelms@harmonia.com>
To:        uiml-discuss@lists.oasis-open.org
Date:      Mon, 26 Aug 2002 18:00:32 -0400

Hello all,

Here it is! The first article in our series of UIML comparisons! Please take a minute, read it, and send your comments and questions to this list. Remember that this article is not the "final word" on the UIML and XForms topic and any input you have is valuable!

UIML and XForms. By Marc Abrams [the majority of this article]

On the surface, UIML and XForms appear to be very similar technologies and there are some areas where they address similar problems. Therefore, it is instructive to compare their solutions. In terms of a Venn diagram, the range of UIs (user interfaces) you can describe with XForms is a strict subset of those you can describe using UIML. In fact, UIML can be used to define interfaces that represent not only the XForms sections of the UI, but also the XHTML in which the XForms tags are embedded. Basically UIML provides flexibility in form and function that can be used to represent any UI. However a synergy should exist between UIML and XForms, so it will be useful to explore the differences between the two technologies and discover where they complement each other.

UIML and XForms were designed from different worldviews:

XForms originated to enhance forms in Web pages; to overcome many of the limitations in look, feel, and functionality of the <form> and related tags from HTML; to provide a more sophisticated model of interaction between the server and the browser; to introduce types so that form input can be validated; and later to support form deployment on different devices. XForms had to build on the concepts in HTML forms to be familiar to the Web community and to provide a smooth transition from today's authoring tools, browsers, and servers to XForms enabled pages.

UIML's initial design perspective emerged from a 'clean sheet of paper' unhindered by any metaphors, and was formed by asking very fundamental questions of what information is required to describe any user interface, regardless of device, interface metaphor, or widget set. The language design goal of UIML was to provide a meta language powerful enough to subsume the concepts in every language ever designed to describe or implement user interfaces. This means that UIML would be capable of defining a canonical representation of any UI. The ability to create the canonical representation of any UI allows a vision of a world in which every researcher or product company whose technologies fuel e-business can interchange and interoperate by using UIML as the common interchange language. This is very important to facilitating the use of results coming out of the HCI community in models and transforms. For example, if HCI people designing transforms created UIML-to-UIML transforms, they could potentially be applied no matter whether the UI is ultimately translated to Java or XForms. Similarly, UIML can be used to serve as an intermediary so that transforms designed by one researcher from a language or model to UIML can be used in conjunction with transforms designed by another researcher from UIML to another language or model. An example of this is shown in work by Ralph Miller and Scott P. Overmyer, where they translate a meta-language called Requirements Element Language (REL) into UIML and back. In contrast, XForms has a more immediate objective, and is not powerful enough to serve as this universal interchange representation.

UIML touches on issues that were not familiar for the HTML world.

First, UIML provides strict separation or factorization of the user interface elements. For example, the words, pictures, videos and other content of the UI should be separated from the UI structure for other concerns. This is not done in XForms. Instead, XForms enforces a separation of instance data from UI controls. The UI controls still encapsulate all content of the UI, meaning that label text and UI control content are still integrated into the UI control. This can make internationalization difficult. More generally, UIML is based on an extension to the Model/View/Controller model, called the Meta Interface Model (See http://scholar.lib.vt.edu/theses/available/etd-08122000-19510051/unrestricted/PhanouriouETD.pdf for details). The MIM provides a six-way separation: UI structure, presentation style, content, behavior rules, connection of the UI to whatever code is outside of the UI (e.g., business logic), and mapping of the vocabulary used for class/property/event names to widget set or XML tags to which the UI is mapped.

Second, UIML can describe any method of connection between the UI and whatever the UI "talks to". In particular, UIML should describe the wiring of the UI to business logic that uses a procedure call model, or a Web services server that uses SOAP; or a web server using HTTP GET and PUTs; or a publish/subscribe protocol using events to push content to the UI; and so on. In contrast, XForms builds on the HTTP GET/PUT model of the Web.

Third, UIML allows any UI metaphor (e.g., card-based, Web form-based, desktop GUI application, voice dialog, 3D immersive environments, etc.). In contrast, XForms is restricted to the web-forms model of interaction.

Fourth, UIML should capture author intent. This is possible by allowing descriptions of UIs expressed using abstractions of the author's choice, rather than the choice of the language designer or widget designer. For example, someone designing a course or training may want to think in terms of a UI that has an outline, a list of objectives, prerequisites, etc.. A UI designer for autos may think in terms of steering wheel buttons, driver alerts, etc. A UI designer for displays in factory automation may think in terms of the flow of the manufacturing process. If these UI designers use a traditional UI development tool (e.g., Visual Basic, Dreamweaver, Forte), they are forced to translate their thinking to the level of VB or HTML form or Java widgets, because the palette they use to design the UI contains widgets. In contrast, because UIML is a meta-language to which one adds a vocabulary, one can devise vocabularies specific to course designers versus auto designers versus an industrial engineer and so on, which represent the author intent independently of the particular widgets used with a particular target language or device. This view is not really captured in XForms.

Fifth, UIML should support behaviors, so that much of the JavaScript in traditional web pages can be described in a device-independent form. In contrast, XForms uses XEvents. The event-based description format used in UIML was based on research in the UIMS literature such as Hartson and Hix's 1993 book User Interface Development: Ensuring Usability through Product and Process. In UIML, interface authors can define a set of rules, like a rule-based system, that are stated in terms of conditions and actions. These rules are (1) separated from the rest of the UI, and (2) described in a device-independent format. These rules define a rulebase from which rules are selected as their conditions are met.

Sixth, UIML vocabularies have been created to represent UIs in many languages: Java, C++ for QT widgets in Linux, C++ for an embedded system, C with PalmOS, VoiceXML, WML, HTML, CSS, and Visual Basic. This may be a wider range of targets than envisioned for XForms.

To summarize, UIML is an XML schema targeted to serve as a universal interchange format that can represent any UI - regardless of UI metaphor, language, operating system, and device. On the other hand, XForms is an 'XML application that represents the next generation of forms for the Web'. XForms provides a vast improvement on HTML Forms and begins to address many of the problems with facilitating interaction with remote systems. Ultimately XForms is tremendously helpful for UIML, because mapping UIML to XForms is much easier mapping UIML to HTML forms.

 
[Posted by] James Helms
 
Director of Services
Harmonia, Inc
Phone: (540)  951-5900 ext 6

Prepared by Robin Cover for The XML Cover Pages archive. See "XML Markup Languages for User Interface Definition."

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	UIML and XForms Subject: [uiml-discuss] UIML and XForms From: James Helms <jhelms@harmonia.com> To: uiml-discuss@lists.oasis-open.org Date: Mon, 26 Aug 2002 18:00:32 -0400 Hello all, Here it is! The first article in our series of UIML comparisons! Please take a minute, read it, and send your comments and questions to this list. Remember that this article is not the "final word" on the UIML and XForms topic and any input you have is valuable! UIML and XForms. By Marc Abrams [the majority of this article] On the surface, UIML and XForms appear to be very similar technologies and there are some areas where they address similar problems. Therefore, it is instructive to compare their solutions. In terms of a Venn diagram, the range of UIs (user interfaces) you can describe with XForms is a strict subset of those you can describe using UIML. In fact, UIML can be used to define interfaces that represent not only the XForms sections of the UI, but also the XHTML in which the XForms tags are embedded. Basically UIML provides flexibility in form and function that can be used to represent any UI. However a synergy should exist between UIML and XForms, so it will be useful to explore the differences between the two technologies and discover where they complement each other. UIML and XForms were designed from different worldviews: XForms originated to enhance forms in Web pages; to overcome many of the limitations in look, feel, and functionality of the <form> and related tags from HTML; to provide a more sophisticated model of interaction between the server and the browser; to introduce types so that form input can be validated; and later to support form deployment on different devices. XForms had to build on the concepts in HTML forms to be familiar to the Web community and to provide a smooth transition from today's authoring tools, browsers, and servers to XForms enabled pages. UIML's initial design perspective emerged from a 'clean sheet of paper' unhindered by any metaphors, and was formed by asking very fundamental questions of what information is required to describe any user interface, regardless of device, interface metaphor, or widget set. The language design goal of UIML was to provide a meta language powerful enough to subsume the concepts in every language ever designed to describe or implement user interfaces. This means that UIML would be capable of defining a canonical representation of any UI. The ability to create the canonical representation of any UI allows a vision of a world in which every researcher or product company whose technologies fuel e-business can interchange and interoperate by using UIML as the common interchange language. This is very important to facilitating the use of results coming out of the HCI community in models and transforms. For example, if HCI people designing transforms created UIML-to-UIML transforms, they could potentially be applied no matter whether the UI is ultimately translated to Java or XForms. Similarly, UIML can be used to serve as an intermediary so that transforms designed by one researcher from a language or model to UIML can be used in conjunction with transforms designed by another researcher from UIML to another language or model. An example of this is shown in work by Ralph Miller and Scott P. Overmyer, where they translate a meta-language called Requirements Element Language (REL) into UIML and back. In contrast, XForms has a more immediate objective, and is not powerful enough to serve as this universal interchange representation. UIML touches on issues that were not familiar for the HTML world. First, UIML provides strict separation or factorization of the user interface elements. For example, the words, pictures, videos and other content of the UI should be separated from the UI structure for other concerns. This is not done in XForms. Instead, XForms enforces a separation of instance data from UI controls. The UI controls still encapsulate all content of the UI, meaning that label text and UI control content are still integrated into the UI control. This can make internationalization difficult. More generally, UIML is based on an extension to the Model/View/Controller model, called the Meta Interface Model (See http://scholar.lib.vt.edu/theses/available/etd-08122000-19510051/unrestricted/PhanouriouETD.pdf for details). The MIM provides a six-way separation: UI structure, presentation style, content, behavior rules, connection of the UI to whatever code is outside of the UI (e.g., business logic), and mapping of the vocabulary used for class/property/event names to widget set or XML tags to which the UI is mapped. Second, UIML can describe any method of connection between the UI and whatever the UI "talks to". In particular, UIML should describe the wiring of the UI to business logic that uses a procedure call model, or a Web services server that uses SOAP; or a web server using HTTP GET and PUTs; or a publish/subscribe protocol using events to push content to the UI; and so on. In contrast, XForms builds on the HTTP GET/PUT model of the Web. Third, UIML allows any UI metaphor (e.g., card-based, Web form-based, desktop GUI application, voice dialog, 3D immersive environments, etc.). In contrast, XForms is restricted to the web-forms model of interaction. Fourth, UIML should capture author intent. This is possible by allowing descriptions of UIs expressed using abstractions of the author's choice, rather than the choice of the language designer or widget designer. For example, someone designing a course or training may want to think in terms of a UI that has an outline, a list of objectives, prerequisites, etc.. A UI designer for autos may think in terms of steering wheel buttons, driver alerts, etc. A UI designer for displays in factory automation may think in terms of the flow of the manufacturing process. If these UI designers use a traditional UI development tool (e.g., Visual Basic, Dreamweaver, Forte), they are forced to translate their thinking to the level of VB or HTML form or Java widgets, because the palette they use to design the UI contains widgets. In contrast, because UIML is a meta-language to which one adds a vocabulary, one can devise vocabularies specific to course designers versus auto designers versus an industrial engineer and so on, which represent the author intent independently of the particular widgets used with a particular target language or device. This view is not really captured in XForms. Fifth, UIML should support behaviors, so that much of the JavaScript in traditional web pages can be described in a device-independent form. In contrast, XForms uses XEvents. The event-based description format used in UIML was based on research in the UIMS literature such as Hartson and Hix's 1993 book User Interface Development: Ensuring Usability through Product and Process. In UIML, interface authors can define a set of rules, like a rule-based system, that are stated in terms of conditions and actions. These rules are (1) separated from the rest of the UI, and (2) described in a device-independent format. These rules define a rulebase from which rules are selected as their conditions are met. Sixth, UIML vocabularies have been created to represent UIs in many languages: Java, C++ for QT widgets in Linux, C++ for an embedded system, C with PalmOS, VoiceXML, WML, HTML, CSS, and Visual Basic. This may be a wider range of targets than envisioned for XForms. To summarize, UIML is an XML schema targeted to serve as a universal interchange format that can represent any UI - regardless of UI metaphor, language, operating system, and device. On the other hand, XForms is an 'XML application that represents the next generation of forms for the Web'. XForms provides a vast improvement on HTML Forms and begins to address many of the problems with facilitating interaction with remote systems. Ultimately XForms is tremendously helpful for UIML, because mapping UIML to XForms is much easier mapping UIML to HTML forms. [Posted by] James Helms Director of Services Harmonia, Inc Phone: (540) 951-5900 ext 6 Prepared by Robin Cover for The XML Cover Pages archive. See "XML Markup Languages for User Interface Definition."