1.3 A Communications Protocol to Support Universal Accessibility in Information Technology
7. Some Related Standards, Technology and Research
A UI4ALL white paper by Constantine Stephanidis, et al.[3], expresses Research and Development Activities required to realize the goals of user interfaces for all, especially including persons with disabilities. Among these are:
Adaptation refers both to the system's capability to tailor aspects of its interactive behavior prior to an interactive session in anticipation of a user's needs (adaptability) as well as to run-time dialog enhancements on the basis of dynamically acquired and maintained knwledge reagarding the user. Individualization implies additional capabilties on the part of the system, such as transparency and modifiability of a system's knowledge about the user.
The new architectures must account for properties of environments of use, including interoperatbility, adaptation, cooperation, intelligence, portability, scalability and modifiability.
A further shift away from the desktop paradigm is emerging, to a paradigm of computer intelligence distributed in the living environment, necessitating delegation-oriented activities. Collaboration and cooperation will enable humans to seamlessly perform joint activities, independent from geographic location, specific characteristics of hardware or software used, and differences in language or culture.
|
The intent of this document is to outline requirements for a communications protocol which will support the first of these Activities through promoting and utilizing the remaining Activities. This document is not concerned with with the explicit transformation of user interfaces, nor with the design of hardware or software designs needed to effect such transformations. Rather the focus is upon providing a standard means of conveyance of profiles, or self-descriptions, of user interface preferences (e.g., which may express the accommodation needed for a disability), operating contexts and constraints, and system/device capabilities for matching/negotiation decisions toward configuration and operation to support the desired interaction. The standard would provide the concise definitions of service interfaces, message formats, and the information structures and behavior required to realize the conveyance of profiles in a wide variety of architectures and technologies. Detailed descriptions of preferences, operating contexts, constraints, and capabilities is beyond the scope of this document, but discussion is provided here to enable the reader to obtain some sense of what these entail. |
Explicit negotiation, rather than simple atttribute/capability matching may be required in some systems. For example, in ATMs and public kiosks, there may be many hundreds of different people who use the device per day. Each of these persons would have their own particular way (plus local environmental conditions) of interacting with the system, so that many different profiles would need to be negotiated. Contrast this with a PC which may have only one user, with an essentially non-varying environment. Here the negotiation may need to be done only once, when the system is brought up. However, if the PC is on a network, then a negotiation may be necessary with each different system on the net with which the person wants to interact. Now consider a home network in which each person in a home has their own preferred way of interacting with the appliances: children different than parents, different than grandparents, different than family member with disability. Negotiation may be necessary as each new appliance (or new person) is added, but after that operation can use profiles extracted immediately from a local repository. However, if a new family should happen to move into the house, negotiation would have to begin anew.
The way that the protocol is intended to operate implies a general architecture for support and realization. This architecture is not intended to supplant existing or envisioned architectures, but rather to supplement them with universal accessibility. The architecture and protocol need to work with everything from hand-held devices to ATMs and kiosks, from home consumer electronics networks to global virtual enterprise networks. The architecture is not a "plug-and-play" architecture, but it could be implemented within such architectures. Some realizations (various interpretations) of the architecture might be distributed in nature, using agents along with CORBA, DCOM, RMI or other distributed access methods, while others could be built using local program calls and table lookups.
|
Because of the wide range of realizations, the protocol should not be thought of as a single entity. Instead, it should be considered to be a family of procedures of various complexities, each based around common service interface descriptions, message and data formats, and general behavior. Each member of the family might be targeted to an environment of given complexity and expected purpose. For example, the protocol family member for home networks might be far simpler than that for a virtual enterprise, because of the differences in assumptions of system and interaction complexity, operation and information exchange. |
To determine an approach for development of the protocol, i.e., adopt, adapt or invent, more than twenty emerging technologies and architectures were examined for suitability, at least in some respect, upon which to base the protocol. The following were general criteria used to judge suitability and completeness.
The technological areas examined are in Section 7. Nearly all of these areas have something to contribute, perhaps three of them more than the others: Salutation [4], NIIIP [5] and JetSend [6]. None of these is "universal" in any sense, but they are not intended to be. Of the three, JetSend and Salutation are closer to being extensible to universality, even though both are far less sophisticated than NIIIP. Both NIIIP and Salutation would require very significant rewrites to serve the purpose of the protocol sought. JetSend has a language for description of data types and structures that is focused on device-level descriptions. However, the language should be extensible and usable for other descriptions, since it is hierarchical. The JetSend negotiation protocol is similar in outline to what is required here, and might be easily extended for non-complex (e.g., one-on-one) situations. Extending the JetSend protocol for more complex cases would require a significant rewrite. On the other hand, it would not seem to be overwhelmingly difficult to adapt any of the three architectures to include the desired protocol. In actuality, this approach is what is needed: a protocol that can be included, in some form or another, in every architecture, with suitable modifications for intgeration..
Protocols suitable for direct adoption do not appear to be available in any of the technical approaches surveyed. Sun Microsystems' Jini [7], for example, provides some of the functionality needed, but leaves significantly many of the details to the implementor and would serve better as infrastructure for the desired protocol. (Note: JetSend is intended to operate above the level of Jini). A protocol for attribute matching exists in the Salutation, the JetSend and the Jini specifications. But the Salutation and JetSend protocols are not sophisticated enough to cover negotiation using agents, as might be necessary in an Internet setting, without considerable rewriting. The Jini protocol, as already noted, requires considerable design detailing, particularly regarding agents. A very sophisticated set of protocols exists in the NIIIP specification which does use agents for negotiation of some preferences, but these preferences have to do with business rules rather than user interface preferences. The agents and the message formats would have to be rewritten. Also, the state machines may also have to be redesigned to meet the proper sequence of protocol events.
Another possible source of difficulty with both Salutation, JetSend and NIIIP protocols is that they are designed for particular environments. This means that certain assumptions about where a protocol operates within an architecture (e.g., what "level") may prevent that protocol from being easily integrated into another architecture with different assumptions, even when the architectures are targeted for the same purpose. For example, in Salutation and JetSend, there is a protocol and mechanism for matching attributes and capabilities, a central feature of the architecture sought. However, this operates near the devices and does not appear to include the user interface, although it could be modified to handle it. JetSend, on the other hand, appears to operate at the right level, but assumes that devices are communicating without any other intervention. JetSend has no relationship to a user interface, so that protocol service interfaces ("API"s) will have to be constructed. Protocol service interfaces--and possibly state machines--may require significant rewriting in order to successfully integrate a Salutation protocol into an architecture for which it was not designed. JetSend should be rather easier to integrate, but not without some development costs. Consequently, adaptation may be possible if the cost of rewriting is less than that of just designing a new protocol based upon the functionality of an existing protocol. It must be borne in mind that the protocol desired must be usable, in some form, in every architecture of interest, not just in a narrow market interest.
A possible approach rather than outright invention is synthesis. This results in a new protocol, one which is built upon previous design work but without architectural "legacy". For example, the Salutation, JetSend and NIIIP approaches might be studied to garner the functionality, tools (e.g., JetSend's description language) and formats that would be combined toward forming the desired protocol. Changes in state machines necessary to conform to new protocol service interfaces would be undertaken and new message formats would be created as necessary would be created. In order to accomplish this, a more detailed requirements document than the present one is needed. This would specify the information to be conveyed, the structure of service interface primitives required, expected behavior (i.e., abstract state machine) and architectural frameworks necessary to realize proper operation. This extended requirements document would evolve from the present document with inclusion of material from existing technology (e.g., Salutation, JetSend, Jini and NIIIP). The challenge will be to write the protocol abstractly enough that it can be incorporated into a wide variety of architectures. One way to do this is to use simpler models (e.g., JetSend or Salutation) for the simpler environments and NIIIP for the more complex ones. This begins to addresses the goal of a family of protocols of common functionality, and helps to alleviate the scaling problem.
Scaling is another concern that must be carefully considered. Some approaches are not intended to scale up (or down) and the universal accessibility architecture and protocols must be able to scale to any architecture. Consequently, the choice of the model for them is crucial. Further study is needed to determine the scaling properties of candidates for synthesis or adaptation.
The picture below is intended to represent controlling a FAX using a PC as an accessor. The task is to send a FAX of a document that is not already in digital form (i.e., on paper), so that a FAX internal to the PC is not an option. The PC has software that can control the FAX and can adapt its screen presentation to the user, through larger fonts, different contrasts, different layouts, etc. It could also have speech input and output, a touchscreen, headtracker, eyetracker or a haptic pad for control inputs, depending upon its users. These could be connected to the PC via a TAP as in Archimedes, but a more flexible approach would be to use an IR or RF link for those personal devices that would have to plug into the PC. This would alleviate, for example, a person who has a mobility disability from having to plug in a headtracker each time just to send a FAX. The software would permit a person (perhaps a system administrator-type) to select and setup the preferences for any user in any of these access media. These would be just stored on the PC and called up whenever the user came to send a FAX. If each user were given an identifier device that linked to the PC via an IR or RF link, the preferences could be brought from the repository without transferring them from an external source. There would be little need for negotation. A protocol (in green on the picture) such as that in Salutation (or Jini or Chai or Universal Plug and Play or ...) coupled to the application would be used to actually control the FAX. The FAX and PC are shown connected by a LAN. They could be connected directly, but then the FAX might not be physically available to everyone, and an added advantage is that more than one PC can be connected to the FAX via the LAN. In may ways, this example is not very different from the Home Automation example below.
The example above can be extended in many ways. For example, suppose that there are several computers all linked to server via a LAN and any one of these is to be used by temporary employees who are to enter data into a database. A given employee may not be assigned the same computer every day (they could be assigned as they arrive). For employees with no disability, this is not a problem, in general, but the person with a disability could have a difficulty in using a different computer every day. The baseline Archimedes solution would physically plug the user's device and accessor into the computer, but this would have to be done anew every day. But if the coupling were RF- or IR-based, then the user would only have to be in proximity to the computer to link with it. The user's preferences could be pre-loaded into the server and negotiation (if needed) would take place between the server and the client machine. The user would be indentified through the accessor link to the computer. Other non-disable users could also have their own preferences enable in a similar way--their identifier device might just be smaller.
With existing technology and the accessibility preferences, it is possible to make Web pages more accessible than they are now or are proposed to be. This does not obviate the need for more accessible interfaces on browsers [10], but instead provides for more accessible content. This might be accomplished through the use of XML Schemas. A Schema would provide the structure of the content of the page, with tags to be interpreted by the client according to preferences. In realization, activating a link (aka "clicking") would cause the HTTP to be captured by a proxy, which would insert its own locater in place of that of the client, much as is done with a firewall. The server would respond with an XML Schema of the page to be accessed. The proxy would interpret this in terms of the preferences provided to it by the client. The interpretation would be returned to the server which would then build style sheets according to the interpretation provided. In general, this would be difficult to do, because of the wide range of possibilities in XML Schemas and in interpretations. However, for certain areas that expect wide usage, such as public information or commercial sales, and therefore emphasizing accessibility, there should be conventions and these could be represented as capabilities to be negotiated by the proxy and server along with preferences. For example, for a blind person, text might be interpreted by the proxy as requiring a reader. But this need not be a conventional screen reader. The server could provide an applet along with the text that reads the text through the client machine's speakers. The applet might be activated by a mouse moving over a "hot" screen area. This can be done now with Java and JavaScript. Other presentation objects might become common and reusable, like JavaBeans, so that conventional interpretations might be had.
A public kiosk poses special problems for universal accessibility because it must be adaptable to any person who comes up to it. This means that it must have a wide variety of input and presentation media available for people who can get close to it and for those who cannot. In the latter situation a kiosk must be able to get input from a user's accessor device and to be able to provide that device with presentation material as well. Consequently, negotiation of preferences and capabilities is critical, especially since the likelihood of repeat encounters with a given person are vanishingly small. The diagram below shows how the the kiosk might be configured for universal accessibility. None of the kiosk's components that it ordinarily uses for conveying information--"show" software, databases, communications to servers, etc.-- are shown on the diagram.
At the bottom of the diagram are two accessors, one connecting to the kiosk via and RF link and the other through an IR link. (This does not represent that both accessors must be present or that both take part in negotiation). A person with no disability might also come up to the kiosk and use it in the conventional manner (i.e., default preferences); this is not shown. A proxy will be needed if the accessor is simple and would be part of the kiosk system. This would be analogous to the case where preferences or other identifying data were input via a smart card: something must process the card-reader output. On the other hand, an accessor might be powerful enough to be its own proxy, in which case the RF or IR link would be on the kiosk-side of the proxy. In this case, the accessor might indicate in the initial handshake that it does not need a proxy.
The kiosk handles all negotiation, since it will, in most cases, be configuring its input and presentation elements for the session. It also maintains repositories for preferences and configurations. There might also be an agent which examines the repositories to learn of accessor, preference and configuration patterns, in order to make the negotiations and configuration more efficient.
Below is a diagram showing how HomeAPI might be made "universally accessible". The Accessor Attachment Network could be a separate network, such as IR, or it could be an adaptation of the Home Network that supports the HomeAPI device connectivity. The Accessors would be personal devices that each different person might use, with personal interface elements (e.g., speech input) attached to it or built into it. Assuming that the Accessors are not "smart" enough on their own to handle the communication with the Control PC, there is a proxy for that purpose. The proxy is shown as a device external to the Control PC, but it could as easily be internal to it. Accessors and proxy might be supplied by an assistive technology vendor. In the Control PC the preference sets are in a repository. These sets might be communicated in through the proxy, in which case the accessibility protocol would handled by the proxy, or the preferences could be entered through the PC's conventional inputs (this might be done with a special application). Because of the power of the PC, transformation would take place in the PC, and the results transmitted via the accessibility protocol's Operation Service to the Accessors via the proxy. Unless new devices are added, new people or people with new preferences are added, there will be little need to negotiate. The Control PC could handle all these negotiations in any case, since it has access to the all the device properties via HomeAPI.
In this example, the accessibility protocol is minimal, consisting mainly of the data structures for the preference sets and the interfaces mapping the accessors functions to the HomeAPI control protocols. Although accessibility is shown separately here, the open nature of the HomeAPI specification suggests that there is no reason that accessibility cannot be built directly into a HomeAPI implementation.
Handheld and other mobile computing devices are expected to be at the center of ubiquitous computing as it evolves over the next few years. This has been accelerated lately by the advent of very small RF transmitters and receivers, small processors and storage, and PCS services. Much of the infrastructure to support universal accessibility protocols already exists or is being developed (see AirJava, for example) as part of the need for universal roaming with mobile devices. The diagram below shows how universal accessibility might be incorporated in to geographic computing. The diagram is an adaptation of a diagram in a Salutation white paper [5] on geographic computing, by Robert Pascoe.
In many ways, this usage is similar to that of the Kiosk (above). The Local Server is analogous to the Kiosk and the mobile device to the Accessor. In fact, we can expect that mobile devices might be used as Accessors for all kinds of systems linked by wireless communications. The main difference between the mobile computing example and the Kiosk is that the Local Server is not likely to have any presentation media of its own, since it will probably be some distance away from the handheld device and remain so for the session. Consequently, any interface adaptation will appear on the mobile device, but may be configured by the Local Server and downloaded to the mobile device. Also in contrast to the Kiosk, mobile device interaction and access policy data is typically shared among the servers in the system for security and efficiency reasons, so that over time a user's preferences will become widely distributed and there would less of a need for negotiation.
There are an enormous number of ways that the military might use the accessibility protocol, from tactical situations,as depicted below, to 21st Century Command Posts. The Army has been conducting research for some time on interface adaptation on the basis of the rank, speciality, mission, experience and situation of the user. Aircraft coordinating fighters and bombers in the Persian Gulf and Kosovo routinely employ preferences for users of the onboard workstations, according to mission responsibilities and personal criteria. The Navy has a pratical need for preference-based interfaces in ship sensor software for navigation that it shares with the Coast Guard.
The situation shown below involves a command/analysis center, tanks, helicopters and troops in the field, A-10 "Tankbuster" aircraft in the air, with coordination and missile warning provided by an AWACS aircraft, all linked via satellite (or other communication). Each of these entities will have a need for a different view and control of information than the others, because of the differences in activity, mission responsibilities, locales, and rates of movement. For example, in viewing a map, the soldier in a tank will need to know the terrain he is to traverse, so he may prefer a contour map. If he is an enlisted man, he will not need the tactical information on the map that his commander requires. Because of the noise in a tank and the near-constant use of the hands, the soldier will probably use speech input from a helmet-mounted microphone to bring up maps and other information. In contrast, a helicopter pilot will be more concerned with features on the ground by which she can navigate than with specific contours, because she will be moving over the ground at a faster speed than the tank moves, and because tanks can be impeded by contours and helicopters generally are not. But similar to the soldier in the tank, the chopper pilot's hands are likely to be busy and the noise level will be high.
In the command center, maps of all sorts will be displayed along with a wide variety of other tactical (and possibly strategic) information. There will be a number of personnel in the center of various ranks, specialties, experiences and responsibilities. A general standing in a command theater might bring up a display simply by a gesture or spoken command, in his preferred manner. This would require visual and voice tracking to implement the multimodal coordination. A major seated at an analysis desk might use a touchscreen and speech input to control her analysis.
The diagram below shows a simplified approach to preference-based digital map retrieval. In this scenario it is assumed that there will be no negotiation, since map retrieval preferences for a given individual in a given situation are not likely to vary. The preference sets for each individual can be pre-loaded into a database. However, the format of records and the messages needed to pre-load the preferences would be those of the accessibility protocol. The preference set for an individual can be selected before the mission is begun. Because an individual in combat may become incapacitated, it is useful for other persons to be able to bring up their own preferences to continue the mission. There is no need for discovery in general in this scenario, since the databases will be at fixed logical locations--simple lookup will do. In the diagram the grey boxes denote the accessibility preference services while the rose boxes denote the operational protocols.
It is worth noting that the military devotes a certain amount of its technological research to applications that potentially will accommdate users with disabilities, as a matter of policy.
The diagram below shows an arrangement of preferences in an E-Commerce setting. Three users are represented, but any number could participate in the activity. This setting could also represent a role-playing game, with the Public Preferences being realized as character attributes. In an E-Commerce realization, the Public Preferences are views of what each user has to offer in trading, price, etc. For example, the "red" user has products with prices that are preferred, but wants to present a different view (the shape and shade of the color blob in the Presentation Plane) of these to the "green" and "blue" users, perhaps based upon prior knowledge that "red" has about "blue" and "green". This knowledge, plus the context of the setting (there might be a different approach that "red" would take if "yellow" and "purple" were playing) adhere to the model of preferences outlined earlier in Section 4: preferences within a context and constraints. What is different is that the task, negotiation, is defined in terms of transactions--as Interaction Functions--as discussed in Section 4. This implies that the accessibility formats and protocol could be used at two levels in this system: for private preferences, in the "accessibility" sense; and for supporting the "higher" level E-Commerce activities. Thus, an architecture such as described by the NIIIP could be used to build the system and the accessibility protocols and formats added to provide the preference functionality.
The descriptions below of technologies and research were for the most part derived by editing the descriptions provided on Web sites by the cognizant organization or vendor. There is no particular rationale for including or excluding any technology or product. The list is not the result of any exhaustive search and is intended only to represent a segment of representative, related products or consortium efforts, for the purpose of ascertaining the availability of approaches that could be used for adoption or adaptation in the development of the accessibility protocol.
The Object Management Group (OMG) has defined the Common Object Request Broker Architecture (CORBA) which allows applications to communicate with one another no matter where they are located or who has designed them. The Object Request Broker (ORB) is middleware that establishes the client-server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. In so doing, the ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems. The Internet Inter-ORB Protocol (IIOP), like HTTP, uses the Internet as a backbone, and provides exchange mechanisms for CORBA-defined messages for interoperability.
Microsoft's Distributed Component Object Model (DCOM) is a protocol that enables software components to communicate directly over a network in a reliable, secure, and efficient manner. DCOM is designed for use across multiple network transports, including Internet protocols such as HTTP. DCOM is based on the Open Software Foundation's DCE-RPC spec and will work with both Java applets and ActiveX components through its use of the Component Object Model (COM). DCOM is location independent, meaning that an application can combine related components into machines that are "close" to each other onto a single machine or even into the same process. Components can run on the machine where it makes most sense: user interface and validation on, or close to, the client; database-intensive business rules on the server, close to the database. DCOM is also language-independent.
Sun's Java-based Remote Method Invocation (RMI) enables the programmer to create distributed applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. A Java program can make a call on a remote object once it obtains a reference to the remote object, either by lookup in the bootstrap naming service provided by RMI or by receiving the reference as an argument or a return value. Java RMI allows developers to treat remote objects very much like normal Java objects. Sun has released several interfaces that work on top of RMI, including Transactions, Leases, and Distributed Events. Access to multi-language environments is accomplished through an IIOP-compliant (Internet Inter-ORB Protocol) subset of Java RMI which allows access to legacy systems.
Softwire's iBus is an intelligent, Java-based communications infrastructure, organizing multiple middleware approaches, Knowledge Management technologies, and communication protocols into a unified whole. iBus supports Asynchronous Push, through transmission by IP multicast, TCP, or by a combination thereof, and Synchronous Pull, a request-and-reply style communication, much like RMI or CORBA, and operates above both TCP and IP multicast. In contrast to RMI and CORBA, iBus allows a pull request to be issued on more than one receiver for fault-tolerance and load sharing. Another feature of iBus is a protocol composition framework that permits choosing types of service needed for an application. The quality of services (QoS) offered are reliable IP multicast using negative acknowledgments, unreliable IP multicast, TCP communication, data encryption, and failure notification, among others. The protocol framework can also be extended with other (not yet unsupported) qualities of services, permitting iBus to work over various communication media--IP Multicast, TCP, Infrared, RDS, GSM, Satellite, etc. iBus readily scales, permitting objects to join and leave a group dynamically.
Sun Microsystems' Jini technology provides simple mechanisms which enable devices to plug together to form an impromptu community without any planning, installation, or human intervention. Each device provides services that other devices in the community may use. Jini technology defines a set of protocols for discovery, join, and lookup, and also a leasing and transaction mechanism to provide resilience in a dynamic networked environment. The Jini connection infrastructure is small enough that a community of devices enabled by Jini connection software can be built out of the simplest devices. In general, Jini only provides connectivity among systems which run the Java Virtual Machine (JVM), but devices or systems which do not run the JVM can be connected and operated via proxies which do run the JVM. Jini uses Remote Method Invocation (RMI) for object communication.
The National Industrial Information Infrastructure Protocols (NIIIP) Consortium is a team of organizations that has entered into a cooperative development agreement with the U.S. Government to develop open industry software protocols that will make it possible for manufacturers and their suppliers to effectively interoperate as if they were part of the same enterprise, even though many of these interactions are unscheduled, occur between both sophisticated and relatively unsophisticated users who utilize a wide range of computer systems, operating environments, and business processes. The NIIIP will allow individuals, enterprises and organizations, or their subdivisions, to assemble themselves into Virtual Enterprises in order to provide products, services, or solutions without being constrained by the use of different data, processes, information technologies or computing environments.
Concordia, a product of Mitsubishi Electric's Information Technology Center, provides a middleware infrastructure for the development and management of mobile agent applications. Another Mitsubishi Product, Multi-Enterprise Links-by-Agents (MELBA) integrates applications across multiple enterprises as well as within a single heterogeneous environment in a company. Application plug-ins function as the interface for each application avoiding any application-specific interface programming. Concordia does not require persistent network connections, allowing asynchronous and one-way connections over low-cost communications facilities or the public Internet. An Agent Server ensures robust operation and reliable transport of agents and events using a two-phase commit protocol. The mobile agents are Java-based and are platform independent to the extent that a Java Virtual Machine is available on the system at which an agent is targeted.
The Open Agent Architecture (OAA), is focused on building distributed communities of agents--software processes that register the services they can provide in an acceptable form, that speak the Interagent Communication Language (ICL), and share common functionalities, such as the ability to install triggers, manage data in certain ways, etc. The ICL is a logic-based declarative language capable of representing natural language expressions. Agents can communicate using simultaneous, multiple (natural) input modalities--from gestures, speech, drawing, handwriting, or a standard graphical user interface. The agents compete and cooperate in parallel to translate the user's request into an ICL expression to be handled. These techniques, with a special class of agents which reason about the agent interactions necessary for handling a given complex ICL expression, allow human users to closely interact with the ever-changing community of distributed agents. The agents are also mobile with lightweight user interfaces which can run on handheld PDA's and most applications can be run through a telephone-only interface.
Universal Plug and Play is an open standard technology for transparently connecting appliances, PCs, and services by extending Plug and Play to support networks and peer-to-peer discovery and configuration. This paper introduces the standards-based, flexible architecture for Universal Plug and Play and provides an overview of the basic principles and elements of Universal Plug and Play. The Universal Plug and Play Forum is an industry group of companies promoting Universal Plug and Play networking protocols and device interoperability standards. Universal Plug and Play members will work with Microsoft to enable device-to-device interoperability by promoting Universal Plug and Play protocols and cooperatively developing and contributing XML schemas for device description, naming and HTML-based control.
Salutation is a "plug and play" architecture that has found primary application in interconnecting office devices (FAX, phone, computers, etc.) It features a structure similar in some respects to the Universal Accessibility Architecture and Protocol described in this document. It may be possible to extend Salutation to cover the functionality of the Universal Accessibility Architecture and Protocol. In particular, for broader scope of usage than is current with Salutation, it would require the addition of a Transaction Service, a more comprehensive set of protocols for task operation, and the ability to include agents and proxies. However, for the current scope of usage, Salutation might require only the inclusion of more comprehensive preference descriptions and selection (plus any interface transformations necessary, to complete the intent of universal accessibility). Salutation-Lite [6] is an adaptation of Salutation for hand-held and palm computers, to enable "geographic" [7] computing
Bluetooth is a proposed Radio Frequency (RF) specification for short-range, point-to-multipoint voice and data transfer. Bluetooth can transmit through solid, non-metal objects. Its nominal link range is from 10 cm to 10 m, but can be extended to 100 m by increasing the transmit power. It is based on a low-cost, short-range radio link, and facilitates ad hoc connections for stationary and mobile communication environments.
The Infrared Data Association (IrDA) specifies three infrared communication standards: IrDA-Data, IrDA-Control, and a new emerging standard called AIr. For the purpose of this document, IrDA refers to the IrDA-Data standard. In general, IrDA is used to provide wireless connectivity technologies for devices that would normally use cables for connectivity. IrDA is a point-to-point, narrow angle (30° cone), ad-hoc data transmission standard designed to operate over a distance of 0 to 1 meter and at speeds of 9600 bps to 16 Mbps.
The Motorola Piano Platform provides short range, wireless connectivity at high bandwidth to a variety of mobile devices. It creates spontaneous, ad hoc networks between a wide variety of common devices. When Piano-enabled devices come into physical proximity with one another, they automatically detect each other's presence, and exchange information, either automatically or under user control, to determine whether further communication between the devices is warranted. If further communication is necessary or desired, a "just-in-time" intranet is established between the devices so that either device can use the services of the other. Piano is complementary to both Jini and Bluetooth.
IBM-Almaden's T Spaces is a network communication buffer with database capabilities. It enables communication between applications and devices in a network of heterogeneous computers and operating systems. T Spaces provides group communication services, database services, URL-based file transfer services, and event notification services. With a small footprint, T Spaces is capable of bringing network services to small/embedded systems. Written in Java, T Space client applications can be loaded dynamically into any network-attached computer. At present IBM has no plans to market a commercial product based upon this experimental technology. IBM-Almaden has also developed a software technology called Mobile Document Application Language (MODAL) that converts any handheld device into a universal remote control. MODAL uses T-Spaces for its communications, and has the capability to emulate any device's interface. The technology is functionally similar to Sun's Jini technology, but Jini has the devices only discover one another, then frees them to talk to each other anyway they want; MODAL and T Spaces provide application communications beyond discovery. MODAL works in multiple communications modes from local wireless devices using infrared and Bluetooth radio frequencies. It also works over wide areas using paging networks or cellular digital packet data.
The Trace R&D Center at the University of Wisconsin-Madison has developed EZ Access and URCC. EZ Access is a flexible but standard set of interface strategies for allowing people to access and use electronic devices even when they are operating under constrained conditions, such as having a disability or from environmental factors. EZ Access is a set of modes and features which can change the way electronic devices operate. The EZ Access package includes strategies for people with low vision, blindness, reduced hearing, deafness, physical disabilities, reading problems, inability to read, and more. EZ Access provides a standard way for people with disabilities to use all manner of electronic devices, such as microwave ovens, cellular phones, interactive multimedia kiosks, or coffee vending machines. The URCC is a communications protocol that can be used over any transmission medium. URCC allows individuals to use a single controller (e.g., a dedicated controller, an electronic pocket organizer, a laptop computer) with an appropriate comm port to control any URCC-compatible device (VCR, stereo, thermostat, kiosk, etc.). It also allows people with disabilities who cannot use the displays and controls on the standard devices to use a special assistive technology as a remote console, allowing them to access and use the standard devices.
The HomeRF Working Group (HRFWG) was formed to provide the foundation for a broad range of interoperable consumer devices by establishing an open industry specification for wireless digital communication, between PCs and consumer electronic devices anywhere in and around the home, called the Shared Wireless Access Protocol (SWAP). The system is intended to operate at 2.4GHz. SWAP provides support for delivery of both voice and data traffic and interoperates with both the Public Switched Telephone Network and the Internet. It employs TDMA for voice and other time-critical services and CSMA/CD (Ethernet) for high-speed packed data transfer.
HomeAPI is a set of programming interfaces enabling software applications to discover and control home devices such as TVs, VCRs, lights, security systems, thermostats, etc. Home API and the Home Audio/Video Interoperability (HAVi) complement one another and target different clients. Home API addresses the full spectrum of home devices and targets Windows application clients. Home API will be capable of interfacing with Jini devices, but Home API is based on a more centralized control model in which a few general-purpose intelligent devices control a wide variety of devices across arbitrary home networks. Jini does not assume a centralized control nor a Windows environment. Home API is capable of interfacing with a variety of lower-level network and device control protocols, such as CEBus and Home PnP.
HomePNA has chosen to standardize on a technology already available which permits linking devices at speeds up to 1 Mbps over existing home phonelines. It supports the complex, random-tree type of wiring typically found in the home and does not require any hubs or new Category 5 wiring. Such an arrangement requires no special terminations, filters or splitters, and uses only the single pair of existing phone wires to make its connection, and operates concurrently with any normal telephone service that might be using those same wires. The technology also coexists with the new splitterless Universal ADSL standard. It is fully compatible with the Ethernet MAC layer standard (IEEE 802.3 CSMA/CD with a new physical layer).
Hewlett-Packard has new product called JetSend that is intended to operated above connection technologies such as Jini and Universal Plug-and-Play. The premise of JetSend is a protocol that can be embedded into different devices--printer, PC, PalmPilot,scanner, cellphone--to permit them to communicate and exchange information directly. JetSend is independent of transport protocol and can be used over network technologies as diverse as infrared or Internet IP, or it could be layered over Jini. JetSend has a "negotiation" protocol which permits the exchange of data type and data structure information, through the transmission of Java objects called "surfaces". There is also a language which is used to describe the contents and structure of a surface. Each surface has an owner-device, but another device receiving a copy of a surface (called "impression") permits the recipient to operate the first device without having to load a driver. HP has published the JetSend specification and developers are free to build their own implementations.
ChaiAppliance Plug and Play is a member of HP's Chai family of embedded-software products and supports device and application discovery using Web standards such as HTTP and XML and supports the Universal Plug and Play initiative. ChaiAppliance Plug and Play is written in the Java programming language and is targeted for use in a broad range of appliances. ChaiServer uses the World Wide Web's URLs (Uniform Resource Locators) to identify and directly access individual devices and their applications. This makes it possible to access a device and its services via any browser, or to call these services programmatically. All communication is done over HTTP (HyperText Transport Protocol). ChaiVM 2.0, a virtual machine that complies with the Java Virtual Machine specification, allows for Java-language-based logic mobility in embedded appliances, permitting downloadable applications that could execute on a family of appliances, regardless of operating system or CPU differences.
HAVi ("Home Audio/Video interoperability") is consortium whose activity pertains to interconnecting and controlling AV electronics appliances connected in the Audio/Video Home Network based on IEEE 1394. The core open home network specification defines middleware elements for permitting interoperation of different brands of of AV electronic appliances, and the roles functions of these elements. Display devices offer their display to other applications and need not take part in the application themselves or be aware of the functionality behind the User Interface that is shown by an application. HAVi also specifies an open and standardized Java programming environment for applications and Device Control Modules on HAVi devices. HAVi adopted the IEEE-1394 bus as the underlying network technology for the HAVi protocols as well as for the transport of the real-time AV streams.
The CEBus Industry Council (CIC) has developed the CEBus Standard around Common Application Language (CAL). The CAL defined within EIA-600 provides only a framework for communication among home LAN products produced within divergent industry sectors (e.g.; entertainment, computers, heating/cooling, kitchen appliances, and many more) . EIA/CEMA published CAL as a separate EIA Standard, to be known as EIA-721, after it was adopted by various industry sectors and CIC had defined "grammatical" rules for using the language. CIC's Home Plug & Play Specification is a set of interoperability guidelines developed by the CEBus Industry Council. The guidelines are transport-protocol independent. To be properly implemented, each industry sector must define the "application contexts" (i.e., grammatical rules) under which its products will use the language.
This ERCIM Working Group is initiated against the background of recent European R&D activities which have analyzed the requirements, identified the viability, and demonstrated the feasibility of constructing 'user interfaces for all', i.e. interfaces which address the individual user requirements of potentially all users. It has been successfully argued that alternative, technologically more powerful and methodologically more systematic approaches are needed to tackle the problems of accessibility and quality of interaction for all potential users and in a holistic way.