OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

uiml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Materials for the October TC meeting.

As part of the OASIS UIML TC meeting today we will discuss some advanced uses of templates and explore how we can accelerate the standardization of UIML.   If possible, please review the materials below before the meeting. 


Advanced Template topics:

There are two topics relating to templates that we want to discuss: 1) the parameterization of templates so that they may affect items outside of the template, and 2) optional template elements that can be removed by a sourcing document without removing them from the template.


Issue 1 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.


Issue 2 involves the deletion of 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. 


Solutions to both of these issues will help to further enhance the descriptive and representational power of UIML.  We will discuss mechanisms for implementing them in the TC meeting today.


Accelerating Standardization:
Our TC charter needs to be revised to reflect the work we have done and any new directions we plan to follow.  The original charter is included below for reference.

The charter for this TC is as follows.


User Interface Markup Language (UIML) Specification Technical Committee

Statement of Purpose

The purpose of the User Interface Markup Language (UIML) Specification Technical Committee is to develop a specification for an abstract meta-language that can provide a canonical XML representation of any user interface (UI). The language should be capable of specifying the requirements, design, and implementation of any UI.

The committee will use the UIML3 specification created by Virginia Tech's Center for Human Computer Interaction, Harmonia, Inc., and other organizations on uiml.org as a starting point [1]. The owners/creators of this specification claim no intellectual property with regard to UIML and will not seek licensing reparation for its use in this TC, nor will they seek ownership of any work produced by the TC.

The TC differs in scope from other committees and working groups that address concrete UI implementation languages (e.g., assembly language, C, C++, CSS, Java, HTML, VoiceXML, WML, XForms, XHTML, XSL-FO). Instead, this TC focuses on an abstract language, UIML, which expresses UIs at a higher level than the concrete languages. UIML's goal is to subsume in expressive power all concrete languages, and to permit efficient mapping from UIML to any concrete language.

The TC has a secondary purpose -- to use UIML to bridge UI-related fields:

A general motivation for a canonical UI representation language is to accelerate the development of tools for UI development. If practitioners from these fields build tools with UIML, then the tools can interoperate. Just as XML made toolbuilders more efficient (because tools built for XML work for any XML vocabulary), so can UIML make UI toolbuilders more efficient (because tools built for UIML work for any vocabulary representing any concrete UI implementation language). Thus the TC's work will serve to assemble the jigsaw puzzle pieces of UI and HCI technology that have been created.

The TC will evaluate UIML3 and other UI initiatives to formulate a plan for creation of a specification, develop the specification, create compliance tests and implementations, and submit the specification to the OASIS membership for approval.

Relationship to Existing Activities:

Many efforts related to use of XML to describe UIs are underway throughout the industry. The following work may be relevant to this TC:

List of Deliverables

Optional deliverables


Thank you!

James Helms

Director of Research and Development
Harmonia, Inc.
P.O. Box 11282
Blacksburg, VA 24062

Office: (540) 951-5900 x 3
Cell: (540) 558-9722

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]