V2-ResD-PP2.html
Project Proposal to Develop a New Standard
Protocol to Facilitate Operation of Information and Electronic Products
through Remote and Alternative Interfaces and Intelligent Agents:
Resource Descriptions
_____
1. Source of the Proposed Project
1.1 Title
Protocol to Facilitate Operation of Information and Electronic Products through
Remote and Alternative Interfaces and Intelligent Agents: Resource Descriptions
1.2 Date Submitted
January 27, 2004
1.3 Proposer(s)
The INCITS Information Technology Access Interfaces Technical Committee (INCITS/V2).
Four organizations (IBM, NIST, Panasonic, & Unisys) are members of both
INCITS/V2 and the INCITS Executive Board.
2. Process Description for the Proposed Project
2.1 Project Type (Development or Revision)
Development ("D")
2.2 Type of Document
Standard
2.3 Definitions of Concepts and Special Terms
See attached: Terms of Reference
2.4 Expected Relationship with Approved Reference Models, Frameworks, Architectures,
etc.
There are a number of existing protocol and modeling activities being undertaken
by the Internet Engineering Task Force (IETF), the World Wide Web Consortium
(W3C), and other consortia and specification development activities that
we are coordinating with. We are working with INCITS/L8 to ensure that
necessary data definitions, metadata, as well as shared data registry and
registration authority definitions are specified correctly and similarly
with INCITS/T4 to ensure that security and privacy issues are appropriately
addressed.
2.5 Recommended INCITS Development Technical Committee (Existing)
The INCITS Information Technology Access Interfaces Technical Committee (INCITS/V2).
2.6 Anticipated Frequency and Duration of Meetings
INCITS/V2 meets 4 times a year at various locations throughout the U.S. in
2 to 4 day face to face plenary meetings. Working meetings are held
as needed by different ad hoc teams. These meetings are held by telephone
conference, video conference, and other means when feasible to save time
and resources and to allow maximum participation by the broadest spectrum
of interested parties. Over 50 of these working meetings have taken
place over the last year.
2.7 Target Date for Initial Public Review (Milestone 4)
April 15, 2004
2.8 Estimated Useful Life of Standard or Technical Report
At least 5 years.
3. Business Case for Developing the Proposed Standard or Technical Report
3.1 Description
This proposed American National Standard will be one in a series supporting
the development of Universal Remote Consoles (URCs). The goal of this
set of standards is to provide a framework of components that combine to
enable remote User Interfaces and remote control of network accessible electronic
devices and services through a Universal Remote Console (URC).
The V2 Technical Committee is developing a set of standards for the discovery,
selection, configuration, and operation of user interfaces and options.
The purpose of these standards is to facilitate the development and deployment
of a wide variety of devices (from different manufacturers) that can act
as Universal Remote Consoles (URCs) for an equally varied range of devices
and services (called "Targets"). In other words, the standards
will allow users to control any number of Electronic and Information Technology
devices in their environment.
The potential Targets include both devices and services. They may range
from things as simple as a light switch and thermostats, to more complex
items such as audio visual equipment, home appliances, electronics in a car
or other constrained or specialized environment, web-based services, and
any other devices or services that can be controlled electronically (or via
Communications or Information Technology -- CIT).
Targets may be in the same location as the individual who desires to control
the Target through the URC, or the Target can be at any distance from the
URC/user, as long as there is some type of network connection between the
URC and the Target. This is possible since a URC provides the user
with all of the necessary controls as well as the prompts and other information
displayed by the Target.
URC functionality could be provided by common devices such as personal computing
and Information Technology devices (e.g. laptops, PDAs), telecommunications/WAP
devices (e.g. cell phones), etc. They could also be functions implemented
in assistive technology devices, or they could be devices that were specially
built to function as Universal Remote Consoles. They may also be devices
that were built to function primarily as Remote Consoles for a particular
family of products (e.g. a Remote Console designed to control components
of an integrated home audio-visual system), but would also serve to control
any other device that is (V2) URC compatible. They are similar in behavior
to universal remote controls today, except
a) they have much greater function and scope,
b) they synchronize with the Target in both directions (i.e. they can display
the current status of the Target),
c) they don't need to be programmed by the user, (since they will automatically
discover devices that are controllable in a user's vicinity, discover the
abstracted user interface of the Targets and present it in the way preferred
by the user), and
d) depending on the networking technology used, they may be used out of sight
of the product they are controlling.
The output interfaces provided by URCs could be all visual, all tactile,
or all verbal in nature (or any combination thereof), because the (V2) URC
specifies the content of a Target user interface independently from the form
in which it is presented. Similarly and for the same reason, the control
interfaces may be by voice, keyboard, mouse or any other available technology.
Thus, URCs could be designed that an individual could talk to and, through
the URC, the user could have speech access to any (V2) URC compatible Target
listed above without any of these Targets having any voice recognition or
voice control functionality themselves. A person might, therefore,
be able to say to their URC, "Record channel 12 and show me 'Law and Order'".
Or they could be laying in bed and say, "Set the alarm to 6:30 AM, turn the
coffee on at 6:00 AM, and turn on the home security system". Or, if
one's spouse is already asleep, a person could pick up their PDA or any other
(V2) URC compatible URC device and accomplish these same tasks silently either
by calling up control panels or by issuing the instructions in writing. (The
(V2) URC standard does not provide the natural language control, but would
provide all of the information and control necessary for control by a natural
language processing URC.)
The purpose of the specification on Standard Resource Descriptions is to
define the syntax for describing Resources relevant to the user interface
of a device or service ("Target"). These Resources include text elements
of a user interface such as labels, help text, keyboard shortcuts (access
keys) and associated words (keywords). They may also include non-text
elements such as icons, sounds or videos. A Resource makes reference
to a specific element in a Socket (described in a User Interface Socket Description),
to a specific element in a (V2) Target Properties Sheet, or to a specific
element in a (V2) Presentation Template.
This document provides the specification for development of an AIAP Standard
Resource Description. The following additional documents have been
defined separately and specify other specific languages and components of
the (V2) URC standard:
Universal Remote Console (URC)
User Interface Socket Description
Presentation Templates
Target Properties Sheet
3.2. Existing Practice and the Need for a Standard
No standard or specification exists for defining a user interface (UI) for
an arbitrary electronic or information technology device or CIT service that
is independent of mode of UI rendition or instanciation, along with the means
for communicating such definitions and using them to achieve remote control
of the device or service. Such mode independent UI descriptions together
with robust specifications for UI rendition and instanciation , defining
a "Universal Access Bus," are essential for simplifying and normalizing our
increasingly complex, increasingly computer dominated environment.
The existence of such a universal access bus for consumer products, environmental
controls, appliances, web services, etc. will also benefit people with disabilities
and the aging population by helping organizations meet state and Federal
requirements for universal access to services, data, and information.
3.3. Implementation Impacts of the Proposed Standard
3.3.1 Development Costs
This Standard will be developed through the voluntary and cooperative efforts
of INCITS Information Technology Access Interfaces Technical Committee (INCITS/V2)
members. No significant development costs are anticipated.
3.3.2 Impact on Existing or Potential Markets
There is a burgeoning market already for personalization of content and appearance
on the World Wide Web, with regard to small handheld devices and for commercial
sales purposes. Companies such as IBM, ATG and Vignette, among many
others, have products and services for this explicit purpose. This
market is expected to grow considerably in the next 3 years. There
is also a movement in the Web to provide sites of interest to people
with disabilities (e.g., HalfthePlanet, WeMedia, CanDo) and the aging population
(e.g., SeniorNet), and attempts to bring the W3C WAI recommendations into
these. Alternative interfaces to meet these needs, whether pre-constructed,
adapted or constructed on the fly, are a form of personalization.
Another rapidly emerging segment of technology is that of pervasive computing,
whereby intelligent devices of all sorts are distributed into the living
environments of home, shopping, and other activities involving mobile systems.
Of particular note are the numerous offerings in:
Unified messaging/mobile computing (eFax, Hotmail), providing a central information
net-access point for one's messaging needs;
Net-based information stores for people's core documents/pictures (Freespace,
Apple iTools);
Transcoding/reformatting services for various devices (Everypath, YahooMobile,
IBM);
Home automation & multi-access point management (Sony, Echelon, Microsoft,
IBM)
Personalization of content & related marketing data (Vignette, NetPerceptions)
This follows the burgeoning of wireless technology from companies such as
Qualcomm, Nokia, Ericsson, and Motorola, to mention but a few, as well as
activities such as the Wireless Application Protocol Forum (WAPForum) and
the Salutation Consortium in promoting applications for wireless devices.
Handheld devices such as the 3Com Palm and the Pocket PC are targeted at
the mobile computing environment. Another important factor in the wireless
environment is the Bluetooth RF infrastructure for which a very substantial
number of manufacturers are building compatible devices.
Whereas these services look towards increasing access for user's critical
information, they rely on end-users to configure, change, or maintain configurations
for their access. In addition, the burden of incorporating
multiples of these offerings into a daily regimen is taxing on the user,
and certainly highly error-prone. The key shortfall, however, rests
in the personalization of the user's interaction with each of these separate
systems, and the changes and dynamics that individual users' will need to
effectively coordinate and use these services effectively. This can
be made especially difficult for a user with a disability or who is aging.
To make these systems truly usable, service providers must bridge the user's
networks (office, mobile, home); the user's devices (phone, web-pad, computer);
and the user's information spaces (email, documents, news/information).
Key to interaction across devices and information spaces is the ability to
provide the solution in a ubiquitous form factor. Two related initiatives
are needed:
Spreading the user preference initiators throughout devices and information
systems via involvement by system-on-a-chip manufacturers, device manufacturers,
and mobile code technology.
Appending additional services onto application servers or platforms to provide
a richer, personalized user experience.
Moreover, there is an abundant market for third-party developers to build
products that will carry out interface transformations for content, appearance
and user controls and to build applications that lend themselves to interface
selection or transformation. Many of these already exist. Netscape
has released its Versions 6 browser which permits widespread modification
of both its operating interface and the content appearing on it, through
a language called XUL (extensible User interface Language). There is
also another language called User Interface Markup Language that uses Sun
Microsystems’ Java Swing for modifying rendering of interface elements.
Both of these languages are compatible with and expressible by the W3C language
XML. Sun is also pushing its Jini connection technology as a means
of mediating access to alternative interfaces (the proposed standards would
run over Jini). Other venues for the standard include the Salutation
Consortium’s Salutation architecture, HomeAPI/Universal Plug and Play, and
other home networking technologies.
3.3.3 Costs and Methods for Conformity Assessment
The document will contain requirements for conformity pertaining to each
component of the standard. These requirements can be used to test conformance
with the standard.
Conformance will be determined by industry interoperability testing methods.
The costs for such testing will be born by the component (URC or Target)
developer or manufacturer.
3.3.4 Return on Investment
The return on investment for this development is expected to be high, due
to the complexity and cost to individuals and their employing organizations
of using the current methods of interface configuration in the areas
covered by the proposed Standard.
3.4 Legal Considerations
3.4.1 Patent Assertions
Calls have been made to identify assertions of patent rights in accordance
with the relevant INCITS, ANSI and ISO/IEC policies and procedures. At this
time, INCITS/V2 members are unaware of any patent assertions that may be
made.
3.4.2 Dissemination of the Standard or Technical Report
Drafts of this document will be disseminated electronically. Dissemination
of the final Standard will be restricted as the document becomes the property
of INCITS, ANSI, or ISO/IEC.
4. Related Standards Activities
4.1 Existing Standards
There are no known protocols at the Human Computer Interface.
4.2 Related Standards Activity
HFES
ISO/IEC JTC 1 SC 35 User Interfaces
Note: as the U.S. TAG to ISO/IEC JTC 1 SC 35 User Interfaces, INCITS/V2 will
be working closely with the International community to ensure the broadest
possible acceptance of the standards. We intend to submit a parallel
NP for development of a multipart ISO/IEC International Standard.
4.3 Recommendations for Close Liaison
W3C/WAI Protocols and Formats WG
INCITS/L8
INCITS T4 (security)
UPnP
Jini
Dublin Core Metadata Initiative
W3C RDF Core Working Group
W3C XForms Working Group
5. Units of Measurement used in the Standard
Not Measurement Sensitive