Materials for the October TC meeting, Part II.

[James Helms <jhelms@harmonia.com>]

The following is a list of steps we must undertake to have UIML adopted as a OASIS standard.  This list is distilled from the instructions on the OASIS website.  For a full explanation please go to http://www.oasis-open.org/committees/process.php#stand_approv_process.  Please see the bottom of thise e-mail for an implied timeline from these instructions.

 

Update the TC Charter:

-- Requires a Special Majority Vote (2/3 of the voting members for, less than 1/4 against)

 

Approve a Committee Draft
--  The TC may at any stage during development of a specification approve the specification as a Committee Draft. The approval of a Committee Draft shall require a Full Majority Vote of the TC (greater than 1/2 of the total voting members approve). The TC may approve a specification, revise it, and re-approve it any number of times as a Committee Draft.

Conduct a Public Review
-- The decision by the TC to submit the specification for public review requires a Full Majority Vote.

-- The public review must be announced by the TC Administrator on the OASIS members email list and optionally on other public mail lists; the TC Administrator shall at the same time issue a Call For IPR Disclosure.

-- Comments from non-TC Members must be collected via the TC's archived public comment facility; comments submitted through any other means shall not be accepted. The TC must track the comments received as well as the disposition of each comment.

-- No changes may be made to the Public Review Draft during a review. If changes are required the specification must be withdrawn from review then resubmitted.

-- The TC may conduct any number of review cycles (i.e. approval to send a Committee Draft to Public Review, collecting comments, making edits to the specification, etc.). The first public review of a specification must take place for a minimum of 60 days, and any subsequent reviews must be held for a minimum of 15 days. Changes made to a specification after a review must be clearly identified in any subsequent review, and the subsequent review shall be limited in scope to changes made in the previous review. Before starting another review cycle the specification must be re-approved as a Committee Draft and then approved to go to public review by the TC.

-- If Substantive Changes are made to the specification after the public review, whether as a result of public review comments or from Member input, then the TC must conduct another review cycle. The specification may not be considered for approval by the TC as a Committee Specification until it has undergone a review cycle during which it has received no comments that result in Substantive Changes to the specification.

 

Approve a Committee Specification
-- The approval of a Committee Specification shall require a Special Majority Vote.

-- The TC Chair shall notify the TC Administrator that the TC is ready to vote on the approval of the specification, and provide to the TC Administrator the location of the editable versions of the specification files. The TC Administrator shall set up and conduct the ballot to approve the Committee Specification.

 

Approve an OASIS Standard
-- A TC may resolve by Special Majority Vote to submit the Committee Specification to the membership of OASIS for consideration as an OASIS Standard.

-- Upon resolution of the TC to submit the specification, its Chair shall submit the following items to the TC Administrator:

1. Links to the approved Committee Specification in the TC's document repository, and any appropriate supplemental documentation for the specification, both of which must be written using the OASIS templates. The specification may not have been changed between its approval as a Committee Specification and its submission to OASIS for consideration as an OASIS Standard, except for the changes on the title page and running footer noting the approval status and date.

2. The editable version of all files that are part of the Committee Specification;

3. Certification by the TC that all schema and XML instances included in the specification, whether by inclusion or reference, including fragments of such, are well formed, and that all expressions are valid;

4. A clear English-language summary of the specification;

5. A statement regarding the relationship of this specification to similar work of other OASIS TCs or other standards developing organizations;

6. Certification by at least three OASIS member organizations that they are successfully using the specification;

7. The beginning and ending dates of the public review(s), a pointer to the announcement of the public review(s), and a pointer to an account of each of the comments/issues raised during the public review period(s), along with its resolution;

8. An account of and results of the voting to approve the specification as a Committee Specification, including the date of the ballot and a pointer to the ballot;

9. An account of or pointer to votes and comments received in any earlier attempts to standardize substantially the same specification, together with the originating TC's response to each comment;

10. A pointer to the publicly visible comments archive for the originating TC;

11. A pointer to any minority reports submitted by one or more Members who did not vote in favor of approving the Committee Specification, which report may include statements regarding why the member voted against the specification or that the member believes that Substantive Changes were made which have not gone through public review; or certification by the Chair that no minority reports exist.

-- The above submission must be made by the 15th of any month to the TC Administrator, who shall have until the end of the month to complete administrative processing and checking for completeness and correctness of the submission. If the submission is incomplete it shall be rejected but may be resubmitted at a later time.

-- In votes upon proposed OASIS Standards, each OASIS organizational member shall be entitled to cast one vote. Votes shall be cast via the publicly archived electronic voting facility supplied by OASIS. Ballots shall be publicly visible during voting and may be changed up until the end of the voting period. The results of a vote on a proposed standard shall be provided to the membership and to the TC no later than seven days following the close of the voting period.

-- If at the end of the voting period at least 15 percent of the voting membership has voted to approve the proposed standard, and if no votes have been cast to disapprove the proposed standard, it shall become an OASIS Standard immediately following the end of the voting period. However, if negative votes amounting to less than 15 percent of the voting membership have been cast, the TC shall be notified of the negative votes, after which the TC shall have 30 days to take one of the following actions by Resolution of a Special Majority Vote: (a) request the TC Administrator to approve the specification as submitted despite the negative votes; (b) withdraw the submission entirely; or (c) submit an amended specification, in which case the amended submission shall be considered as if it were a new submission, except that information regarding previous votes and any disposition of comments received in previous votes shall accompany the amended submission.

Timeline:

Approval on Committee Draft - Need to address open issues first (90 days?)
Conduct Public Review - (minimum of 60 days)
Approve Committee Spec - (~ 15 days)
Approve as OASIS Standard - Need certification from three Organizational Member that they are using the specification  (Voting period minimum 30 days)

 

Thanks

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

---

From: James Helms [mailto:jhelms@harmonia.com]
To: Jim Helms [mailto:jhelms@harmonia.com], OASIS UIML TC [mailto:uiml@lists.oasis-open.org], Marc Abrams [mailto:mabrams@harmonia.com], Jean Vanderdonckt [mailto:vanderdonckt@isys.ucl.ac.be]
Cc: limbourg@acm.org, kris.luyten@uhasselt.be, jo.vermeulen@uhasselt.be
Sent: Mon, 24 Oct 2005 10:35:46 -0400
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.

 

#BEGIN CHARTER

The charter for this TC is as follows.

Name

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:

• Techniques from the Human Computer Interaction field. These include UI models, transformational techniques, techniques for computer automation of UIs, usability engineering, generalization of the Model-View-Controller, and new UI metaphors.
• UI designers that want to think in terms of domain-specific abstractions (e.g., navigation maneuver for an automobile UI, material path for a factory automation UI), rather than at a widget level.
• UI designers that want a way to capture author intents and map UIs to different devices to create accessible UIs.
• Techniques to internationalize UIs. Techniques that help integrate UIs with Web Services (e.g., WSDL).

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:

• Many W3C Working Groups and Activities, including Accessibility, CSS, Device Independence, Voice, XForms, XHTML
• Mozilla XUL
• OASIS HumanMarkup TC

List of Deliverables

• Assessment of how UIML fits other committees and working groups addressing user interfaces (projected for completion 90 days after first meeting)
• List of open issues in the UIML 3.0 specification (projected for completion 120 days after first meeting)
• Revised specification based on issues list (projected for completed 240 after first meeting)
• Implementations of the specification by different parties
• Compliance test suite
• Best implementation practices
• Revised Specification based on implementation experience

Optional deliverables

• Documents describing requirements for UIML
• Analysis of using UIML to make interfaces accessible
• Document giving UIML examples 

#END CHARTER 

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