W3C

System and Environment Framework

W3C Working Draft 28 July 2004

This version:
http://www.w3.org/TR/2004/WD-sysenv-20040728/
Latest version:
http://www.w3.org/TR/sysenv/
Previous version:
none as yet
Editors:
Keith Waters, France Telecom
Rafah A. Hosn, IBM
Dave Raggett, W3C/Canon

Abstract

The W3C Multimodal Interaction working group aims to develop specifications to enable access to the Web using multiple modes of interaction, such as speech, pen, keypad, bitmapped displays etc. This document is part of a suite of specifications for multimodal systems, and provides details of a platform and language neutral software interface that enables applications to dynamically determine and respond to changes in device capabilities, device configuration, user preferences and enviromental conditions, such as low battery alerts or loss of network connectivity.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is the first public Working Draft for review by W3C members and other interested parties. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This specification describes platform and language neutral interfaces for the System and Environment (S&E) component in the W3C Multimodal Interaction Framework. These interfaces provide dynamic access to a hierarchy of heterogeneous properties representing device capabilities, device configuration, user preferences and environmental conditions.

This document has been produced as part of the W3C Multimodal Interaction Activity, following the procedures set out for the W3C Process, with the intention of advancing it along the W3C Recommedation track. The authors of this document are members of the W3C Multimodal Interaction Working Group (members only).

This document was produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

Your feedback is welcomed, especially on the open issues described within the specification. See sections 4.8 and 4.9 for details. Please send comments about this document to the public mailing list: www-multimodal@w3.org (public archives). See W3C mailing list and archive usage guidelines.


Table of Contents

1. Introduction

Multimodal applications are expected to function in heterogeneous environments with widely varying device capabilities. The device configuration, user preferences and environmental conditions can vary dynamically and applications need to be able to respond accordingly. How should the application deal with low battery alerts or with loss of network connectivity? Perhaps the user has just muted the microphone or disabled the audio output? Dynamic configurations include snapping a camera attachment onto a cell phone or bringing devices together with Bluetooth, for example, a camera phone and a color printer. The changes to the configuration directly effects the features that applications can offer to users.

The W3C Multimodal Interaction Framework [MMI Framework] identifies the major components for multimodal systems. At its heart, lies the Interaction Manager, which coordinates data and manages execution flow from various input and output modalities. The System and Environment component provides the Interaction Manager with dynamic access to a hierarchy of properties representing the current device capabilities, device configuration, user preferences and environmental conditions. These properties indicate which modes of interaction are supported, which are currently active, as well as a means to enable or disable particular modes, and to get notifications when users make changes themselves.

Within a Multimodal application it is the devices capabilities and operational environment that can shape the input and output presented to the user. Once it has been established what modes are availabile, it is useful to distinguish between persistent (static) and transient (dynamic) information. Static information refers to data that remains constant for the session duration, for example specifying a users language preference for prompt playback, while dynamic information refers to notifications and events during a session, for example generated though GPS notifications [LIF] updating the reported location of a mobile device.

Multimodality is best demonstrated on mobile devices, where the constraints of the device and the environment dictate which modes get utilized. WiFi PDA's are typically large portable devices with high resolution displays, touch screens, powerful CPU's and high bandwidth data channels. In comparision, todays mobile phones have much smaller lower resolution screens, limited keypad (DTMF) for input and low bandwidth data chanels. The rapid acceleration of the mobile handset industry—coupled to next generation mobile networks—clearly indicate that tomorrow's emerging smart phones will be richer, faster and far more capable. The proliferation of such mobile devices will demand multimodal interaction because of the wide range of basic functionality; some devices may have full keyboards, others only keypads, likewise touchscreens for pen input, local or remote speech recognition, GPS location etc., For the Multimodal content provider, it will be increasingly challenging to create content that can be re-purposed for all mobile contexts. From a user's perspective, it will be increasingly important to choose which modes they want to use as well as define their preferences.

Typical environmental properties involve dynamic status information, such as the remaining battery life, mobile signal strength, ambient brightness, location and display orientation information. These properties often vary during a session and need to be signalled to the application to adapt to the new environmental conditions. Static properties are typically defined by user preferences and device context, such as the selected voice for speech synthesis, a preference for pen input over the keypad, or preferences for the font size and color. Such properties usually remain persistent for the duration of the session and can be configured at the start of the session.

The System and Environment Framework provides a mechanism to both query and update properties. For dynamic properties it is important to be able to respond to changes when they occur, for example, the devices' new location, consequently a mechanism to subscribe and unsubscribe to specific events is required. This functionality directly supports the basic requirements of the W3C Multimodal Interaction Requirements [MMI Reqs] (MMI-G14, MMI-G15, MMI-A4).

The System and Environment Framework is designed to allow for properties to be defined by different organizations. For instance, the W3C Device Independence Activity [DevInd] is working on defining a set of core presentation attributes. The Open Mobile Alliance [OMA] (OMA - formally the WAP Form) has developed a set of properties for describing static characteristics of mobile phones. Device vendors are expected to define additional properties for proprietary features.

W3C's Composite Capability/Preference Profiles [CC/PP] is an XML representation of device characteristics, and based on the Resource Description Framework [RDF]. It allows devices to pass a description of these characteristics to Web servers for use in content selection/adaptation. CC/PP has been used for the OMA User Agent Profiles [UAPROF], which describe three classes of static device characteristics:

  1. Hardware: e.g., screen size, type of keyboard,
  2. Software: e.g., browser manufacturer and supported markup language, and
  3. User preferences: e.g., audio enabled and chosen color scheme.

CC/PP is complementary to the System and Environment Framework. CC/PP provides the means to transfer sets of device characteristics from one device to another, while the System and Environment Framework provides Interaction Managers with dynamic access to device characteristics on a moment to moment basis, thereby enabling applications to respond to changes in real time.

2. Assumptions

The System and Environment Framework is based upon the following assumptions:

  1. Properties are associated with XML name spaces and can be arranged in hierarchies. This is essential if properties are to be defined by multiple organizations.

  2. Property names are further constrained so that they can be exposed in XPath expressions as element names, for example, "/a/b/c[3]", and as identifiers such as "a.b.c[2]" in languages such as ECMAScript and Java etc. Formally, the set of valid property names is the intersection of the set of valid ECMA 262 identifiers and the set of valid XML element names.

  3. Properties may be held locally or remotely. The interfaces must be consistent with the apartment threading model, i.e. blocking for any significant length of time is unacceptable.

  4. There is a flexible means to subscribe (and unsubscribe) to notifications of changes to properties, and which gives authors control over the detailed conditions under which notifications are raised in a property specific manner.

  5. Notifications (events) are associated with namespaces for the same reasons as properties.

  6. Properties may themselves be dynamically added or removed during an application, for instance, when a camera module is connected to a cell phone, thereby adding the capability to take photographs.

3. Datatypes for property values

Each property is associated with a given datatype, e.g. a number, a string or structured types like arrays or named fields. This will build upon the types defined by the W3C DOM working group. This section is informative, please see the DOM Object Model Core for definitive details. Some of the common data types in the DOM include:

The DOM normally handles errors by passing back error conditions. In truly exceptional circumstances, a DOMException may be raised, e.g. when an operation cannot be completed.

XML namespaces and URI's in general are treated as being of type DOMString.

4. Interfaces for Properties

This section describes how to determine whether a device supports a given property, or named set of properties. Some properties may be held externally on a Web server (or remote system) and therefore suggests a need to be able to query remote systems as well as the local device. Imagine a multimodal application involving a camera phone connected via wireless to a color printer which may not be in the same room. Properties describing the paper size, and status of the ink cartridges won't be held locally on a mobile device. Environmental alerts in this scenario could include running low on ink, running out of paper, or a paper jam.

The System and Environment is treated as a hierarchy of properties rooted in the SEComponent as shown in the following illustration. Each property is associated with a name, a namespace, a value and an ordered list of subsidiary (child) properties.

component hierarchy

The System and Environment framework is formally defined in terms of OMG IDL interfaces. The SEProperty interface is modeled on the DOM Node interface and represents a single property. It provides support for creating and manipulating a hierarchy of properties. The SEPropertyList is modeled on the DOM NodeList interface and plays an analogous role in providing access to the direct children of a given property. The SEComponent is itself a property node, and provides readonly access to the System and Environment framework version number.

Properties raise events to notify changes in property values, or the removal or addition of properties themselves. SEProperty supports methods for adding and removing event listeners. The SEProperty supports the event capture/bubbling model. This allows you to add an event listener at different levels of the property hierarchy when you want to listen to events that recursively bubble up from child properties. This is independent of the event propagation model in the host environment.

4.1 The SEProperty interface

Objects implementing this interface represent properties. The interface is modeled on the DOM Node interface. Note that the interface provide a means for manipulation the hierarchy of properties but not (as yet) for the creation or destruction of properties. Further information on events is covered in section 5 and section 4.7 covers exception handlers. Ultimately, the implementation is responsible for access control and data integrity.

4.1.1 attributes

readonly attribute DOMString name;         // name of this property
readonly attribute DOMString namespaceURI; // namespace for this property

Each property is identified by a name and namespace. These are initialized when the object is created and can't be changed thereafter.

attribute SEPropertyValue value;  // current value of this property

Value provides read/write access to the property's value. It can accept any data type.

readonly attribute SEProperty parent; // parent property interface

Parent provides readonly access to the immediate parent property in the hierarchy.

readonly attribute SEpropertyMetaData mData;  // Meta data

mData can be used to bind a property to associated meta-data. It can accept any data type.

4.1.2 appendSEProperty

SEProperty appendSEProperty(in SEProperty newChild)
                     raises(dom::DOMException);

This method is used to append a new child property to the list of children for this property. The new child's Parent data item is set to this property. If it was previously the child of another property, it will be automatically removed from that property before being added to this one. The return value is the property being added. A HIERARCHY_REQUEST_ERR exception is raised if this property is of a type that does not allow children of the type of the newChild property, or if the property to append is one of this property's ancestors or this property itself. A NO_MODIFICATION_ALLOWED_ERR exception is raised if this property is readonly or if the previous parent of the property being inserted is readonly.

4.1.3 insertSEPropertyBefore

SEProperty insertSEPropertyBefore(in SEProperty newChild,
                                  in SEProperty refChild)
                           raises(dom::DOMException);

This method is used to insert a new child property before an existing child of the current property. The new child's Parent data item is set to this property. If it was previously the child of another property, it will be automatically removed from that property before being added to this one. The return value is the property being added. A HIERARCHY_REQUEST_ERR exception is raised if this property is of a type that does not allow children of the type of the newChild property, or if the property to append is one of this property's ancestors or this property itself. A NO_MODIFICATION_ALLOWED_ERR exception is raised if this property is readonly or if the previous parent of the property being inserted is readonly.

4.1.4 replaceSEProperty

SEProperty replaceSEProperty(in SEProperty newChild,
                             in SEProperty oldChild)
                      raises(dom::DOMException);

This method is used to replace an existing child property with a new child property. The new child's Parent data item is set to this property. If it was previously the child of another property, it will be automatically removed from that property before being added to this one. The return value is the property being replaced. A NOT_FOUND_ERR exception is raised if oldChild is not a child of this property. A HIERARCHY_REQUEST_ERR exception is raised if this property is of a type that does not allow children of the type of the newChild property, or if the property to append is one of this property's ancestors or this property itself. A NO_MODIFICATION_ALLOWED_ERR exception is raised if this property is readonly or if the previous parent of the property being inserted is readonly.

4.1.5 removeSEProperty

SEProperty removeSEProperty(in SEProperty oldChild)
                     raises(dom::DOMException);

This method is used to remove an existing child property. This has the effect of setting it's Parent data item to NULL. The return value is the property being removed. A NOT_FOUND_ERR exception is raised if oldChild is not a child of this property. A NO_MODIFICATION_ALLOWED_ERR exception is raised if this property is readonly or if the previous parent of the property being inserted is readonly.

4.1.6 hasSEProperty

boolean hasSEProperty(in DOMString namespaceURI,
                      in DOMString PropertyName,
                      in boolean deep);

This method is used to determine whether this property has a given named property as identified by its name and namespace. If deep is true, the search applies to the children and children's children recursively. If false, the search is limited to the immediate children of this property. If there are no matching properties, the result is false.

4.1.7 getSEPropertyList

SEPropertyList getSEPropertyList(in DOMString namespaceURI,
                                 in DOMString propertyName,
                                 in boolean deep);

This method is used to obtain a list of the children with matching property name and namespace. If Deep is true, the search applies to the children and children's children recursively. If false, the search is limited to the immediate children of this property. NULL can be used as a wildcard for the property name and namespace. If there are no matching properties, the result is an SEPropertyList with length zero.

The SEProperty interface also holds the interface to the parent of that property node. This is used to disambiguate between properties that might hold the same name and namespaceURI. For example, consider the property GPS under SEComponent:

There could be two or more GPS system present in the device and there could be an inter-relation between the systems as shown

GPS hierarchy

Calling getSEPropertyList at node GPS with Deep set to true would return both instances of the IBM:GPS properties. To disambiguate between the two, the parent interface can be queried. You would get GPS as the parent of the first such property and NOKIA as the parent of the second.

The SEProperty interface also defines a readonly attribute for metadata that could provide additional information about the property if needed. For example, the profile of IBM:GPS could be stored at some remote location and the information provided by this profile might be needed by the calling application. The metadata format can be of any type.

4.1.8 searchSEProperty

SEPropertyList searchSEProperty(in DOMString namespaceURI, 
                                in DOMString propertyName,
                                in SEPropertyFilter sePropertyFilter,
                                in boolean deep);

This method provides a way to obtained a filtered list of child properties, using an application defined filter passed via sePropertyFilter. The other parameters have the same meaning as for getSEPropertyList. The application filter is defined by the following interface:

// application defined filter for use with searchSEProperty
interface SEPropertyFilter
{
  boolean acceptSEProperty(in SEProperty sePropertyNode);
};

The filter should return true if the property passed by sePropertyNode is to be included in the list, and false if it is to be excluded.

4.2 The SEPropertyList interface

interface SEPropertyList
{
  SEProperty item(in unsigned long index);
  readonly attribute unsigned long length;
};

This is modeled on the DOM NodeList interface, and provides the abstraction of an ordered collection of properties. The item method returns the n-th entry in the list or NULL if the index provided is out of range. The items are numbered sequentially via an integral index that starts from zero for the first item in the collection. The length of the collection is available as a readonly value. The collection is manipulated using the method provided by the SEProperty interface.

4.2.1 SEPropertyList Live

The SEPropertyList is always live. This means that the list would always reflect the changes happening in the SE property hierarchy. The SEPropertyList would be an array that would hold pointers to the actual SEProperties. If there are changes happening in the hierarchy tree, the index number in SEPropertyList would be updated and the array extended accordingly.

4.2.2 No Result Match

If there is no result match, the getSEPropertyList method would return an empty SEPropertyList where the length value would be zero.

4.2.3 Property Removal

If a SEProperty node was accessed and then removed, the system would point the removed node to an empty SEProperty node.

4.2.4 Property Removal once the Value was Accessed

In the SEProperty interface, the value attribute has been typedefined for anytype. This means that the value could be a pointer to a data structure or contain structured data within itself. This assumption would have implications on the SEPropertyList being live. In such a case, the system would raise an exception. This would mean that all such code would have to be enclosed within a try/catch statement.

4.3 The SEComponent interface

interface SEComponent extends SEProperty
{
  readonly attribute DOMString Version;
};

This is used for the root of the hierarchy of properties and includes a readonly value for the version of the System and Environment Framework.

4.4 The SEEventTarget interface

The SEEventTarget interface extends the DOM 2 EventTarget interface and adds to it support for namespaces and event groups as specified in the W3C DOM 3 Note.

4.4.1 addSEEventListener

// simplified analogue of DOM3 addEventListenerNS
void addSEEventListener(in DOMString namespaceURI, 
                        in DOMString type, 
                        in DOMObject evGroup,
                        in SEEventListener listener);

This method is used to add a listener for an SEProperty notification identified by the associated type and namespace and event group.It is analogous to DOM3 addEventListenerNS. Listeners can be added at any level in the hierarchy of properties. Not all events will bubble up to the parent property, and this depends on the specific property and event.

The type parameter can be used to register for category of events rather than for a specific event. This assumes that event categories are expressed as a hierarchy of names. For example, in VoiceXML a specific event sent upon hangup is "connection.disconnect.hangup". This belongs to the category "connection.disconnect" which covers a range of events for different kinds of disconnect. This allows the use of '*' as a wild card, for example in "connection.disconnect.*" and "connection.*.hangup"

4.4.2 removeSEEventListener

// simplified analogue of DOM3 addEventListenerNS
void removeSEEventListener(in DOMString namespaceURI, 
                           in DOMString type, 
                           in SEEventListener listener);

This method is used to remove a listener for an SEProperty notification identified by the associated type and namespace. It is analogous to DOM3 removeEventListenerNS.

4.5 The SEEvent interface

// SEEvent extends DOM2 Event interface
interface SEEvent : Event
{
  readonly attribute DOMString namespaceURI;
 
  void stopImmediatePropagation();

  void initEventNS(in DOMString eventTypeArg,
                   in DOMString eventNamespaceArg,
                   in boolean canBubbleArg,
                   in boolean cancelableArg);
  };

Property specific events extend this interface with additional data items. The DOM event capture/bubbling model is supported and the eventPhase should be one of the enumerated phase types. The attributes and methods have the same meanings as defined in the DOM 2 Event interface, with the addition of the event namespace URI to allow events defined by different organizations to be differentiated by namespace.

The stopImmedidatePropagation method is analogous to the method defined in the W3C DOM 3 Event interface. If called on an event, it prevents listeners registered within the same group, on the current target, to get triggered. Both the DOM 2 stopPropagation and the DOM 3 stopImmediatePropagation methods have no effect between groups of listeners.

4.6 The EventListener interface

// the DOM2 EventListener
interface EventListener
{
  void handleEvent(in Event event);
};

The EventListener interface is used to pass a listener to the SEProperty addSEEventListener method. Listeners can use the event's type and namespace attributes to determine which interface to cast the event to.

4.7 Exceptions

Defined exception error constants:

NO_MODIFICATION_ALLOWED_ERR
If an attempt is made to modify a property where modifications are not allowed.
HIERARCHY_REQUEST_ERR
If any property is inserted somewhere it doesn't belong.
NOT_FOUND_ERR
If an attempt is made to reference a property in a context where it doesn't exisit.
INVALID_ACCESS_ERR
If a parameter that is being accessed pointes to an invalid or outdated location.
INVALID_MODIFICATION_ERR
If an attempt is made to modify the type of the underlying object. A property can raise this exception if the parent is being changed to an invalid one.
NAMESPACE_ERR
If an attempt is made to crate or change a property in a way which is incorrect with regard to namespaces.
TYPE_MISMATCH_ERR
If the type of a property is incompatible with the type f parent under which it is added.
NOT_SUPPORTED_ERR
If the implementation does not support the requested type of object or operation.
SYNTAX_ERR
If an invalid or illegal string is specified. If a search is being made with an invalid Xpath expression or string, this exception can be raised.
INDEX_SIZE_ERR
If an invalid index number is used for accessing the property on a SEPropertyList, the exception will be raised.

4.8 Properties in distributed systems

This section introduces some open issues raised by distributed multimodal applications. It is unlikely that a single approach will be appropriate in all cases. Your feedback and suggestions are welcomed!

In summary how can applications:

For distributed applications, some properties may be held on a server or on another device. One example is toner levels for a printer. An application may choose to query the printer for the current toner levels or to subscribe to notifications of changes. Another example is the use of a server-side script supplied by a third party for a Web Service that provides location information in the format desired by an application running on the device. In both examples, additional properties are needed to control the conditions under which notifications are raised.

The addressing mechanisms and protocols used for remote properties are outside the scope of this specification, although there may sometimes be a need for application authors to pass through information to bind properties to the means needed to implement them. An example, would be the URI for a Web Service used to convert location data. Further discussion is needed on how to support authors in this regard. Some of the potentially relevant approaches for notifications include SIP Events, WS-Events, WS-Notification, UPnP 1.0 eventing, and many more. Similarly, there are a wide range of approaches for accessing and updating remote property values, including, for instance, HTTP and Web Services.

Many approaches to eventing involve a subscribe/notify model. Where events derive from an external source, the subscription interface can be implemented in terms of a remote call, for instance, via a Web Service or the subscribe feature in SIP Events. When this occurs, some kind of handle must be passed to the remote interface, and in turn passed back as part of each event, so that the local system can deliver the event to the correct event queue.

In some cases, prior agreement can avoid the need to pass the subscribe message to the remote interface. A particular example is where events are sourced from the Web server that generated the current page. In this case, the server needs to include the handle in the page in some manner so that it can be passed to the S&E subscribe interface. This allows the local system to configure itself to route subsequent events to the correct event queue, and saves a redundant round trip to the server.

Asynchrous access is needed when the time involved in synchronous access incurs user interface penalties and would breech normal guidelines for the use of the apartment threading model. This can occur when the property value is held remotely (e.g. on a Web server or on another device) and for other cases where it takes significant time to obtain.

Asynchronous access can be avoided if local proxies are maintained for remote properties. A master / slave model can then be used to propagate changes to all such proxies. There will be short periods of time when the slave copies are out of sync with the master. In many cases applications can be designed to cope with this. The approach trades memory and network access for an easier authoring model. For instance, if the application only needs access to one or two properties, then network activity to maintain local copies of other properties will have been wasted. This could be substantial for configurations involving large numbers of properties.

A more refined implementation could set up actively maintained local copies on an as needed basis. Frequently used properties would then be accessible quickly without the high overheads associated with maintaining local copies for all properties. An open question is how applications determine whether to use synchronous or asynchronous access for any given property. Distributed multimodal applications are likely to be very important, and hence these questions need to be addressed in a satisfactory manner.

If true asynchronous access is needed, then values can be returned via events that are triggered by non-blocking requests. The current interface for SEProperty could be modified to support this. A non-blocking method could be added for requesting an event containing the property value. Meta-data associated with the property could be used to indicate whether a property needs asynchronous access, and a 'would block' exception could be raised upon attempting a synchronous access.

4.9 Access rights and validation

A couple of other open issues relate to considerations of controlling access to properties, and a means to apply integrity constraints.

Access rights

There is a need to provide some sort of access rights mechanism for controlling access to properties, for instance, to prevent applications from changing specific property values, or to limit access to specific software components, such as a system manager, middleware component, or modality interface. Access rights could also be useful for restricting event handling. A design issue would be whether to incorporate these rights within the property interface or to provide seperate access rights descriptions.

Integrity constraints

A further requirement would be a means to apply integrity constraints when properties are added or removed, and when their values are updated. For instance, that a new property is permitted at this point in the hiearchy and that its value is acceptable.

5. Events

5.1 Introduction

Properties raise events to notify changes to property values. The data passed with each event will vary according to the property. All events extend the SEEvent interface, which exposes the event's namespace and type, as well as the property on which the event was raised. The conditions under which an event is raised also vary and can be controlled through the value of subsidiary properties.

For some properties an event is raised each time its value changes. This works fine for properties limited to a small set of possible values, for instance, the mute state of the microphone is either true or false. For slowly changing real valued properties, it is better to only raise notifications when the value crosses suitable thresholds, for instance when it goes above a certain percentage of the value at which the last notification was raised.

For notifications incurring network traffic, there are considerations of cost and efficient network utilization. An example is location updates for a cell phone. Some applications will want updates at frequent intervals, while others will only need updates when the location has changed by a suitable amount, or when the phone is approaching key landmarks (street intersection, bank, restaurant, freeway exit etc.)

Additional events are used to notify when properties are removed or added to the hierarchy. An open issue is whether these should be standardized as part of the System and Environment Framework, or left as property specific. Feedback on this issue is welcomed!

This framework doesn't normatively define particular events, but rather shows how events fit into the framework. Informative examples are given to explain how this works, e.g. low battery alerts, loss of network connectivity, location updates, and alerts for when speech recognition rates drops below some predefined threshold.

5.2 Event Processing Model

The S&E eventing model conforms to the DOM 2 Event Specification including capture and bubble phases.

The S&E event interfaces extend the DOM 2 event interfaces and add to them methods to support event namespaces, groups and categories; these additional methods are extracted from the W3C DOM 3 Event Note .

Event namespaces can be used to distinguish between S&E events raised by properties that have the same name but are defined by different organizations. They also allow modules to listen for property events from a particular organization.

Event groups can be used to prevent listeners from stopping an event's propagation before other listeners have a chance to react to it. The DOM 3 Note specifies that if two listeners are registered in two different groups one cannot prevent the other from being triggered. This feature is useful when multiple modules are listening to the same event and some of them need a guarantee that they will indeed receive it regardless of some listeners in other groups stopping its propagation.

Event categories allow listeners to be registered for a hierarchy of S&E events rather than for a specific event type. For example, a listener can register for an "asr.*" event category, thus instructing the event processor to activate it for all property events that get raised from the subtree rooted at the "asr" property.

Any module (such as a browser or interaction manager) that implements the DOM 2 EventListener interface can register as a listener on the S&E property tree. Modules that get activated receive SEEvents and may need to appropriately cast or copy these events before dispatching them in their own structures. For example, a DOM based browser container may register itself as a listener to property events on behalf of application authored event listeners. When the container listener gets activated, it many needs to copy the SEEvent into a DOM event implementation and substitute the SEProperty targets into DOM Node targets before it can propagates it down its own DOM tree (assuming the container gets a reference to the SEEvent rather than a copy).

6. Appendix - IDL Definitions for System and Environment Framework

This appendix contains the complete OMG IDL definitions for the System and Environment Framework with the exception of existing DOM modules for the DOM core and DOM events. which are used for some common DOM data types and the EventTarget interface.

// File: seproperty.idl

#ifndef _SEPROPERTY_IDL_
#define _SEPROPERTY_IDL_

// include DOM IDL modules
#include "dom.idl"
#include "event.idl"

#pragma prefix "sysenv.w3c.org"
module seproperty
{
  interface SEComponent;
  interface SEProperty;
  interface SEPropertyList;
  interface SEEvent;
  interface SEEventTarget;

  typedef any SEPropertyValue;
  typedef any SEPropertyMetaData;

  typedef dom::DOMString DOMString;
  typedef dom::DOMTimeStamp DOMTimeStamp;
  typedef dom::DOMObject DOMObject;

  exception SEException {
    unsigned short   code;
  };

  // Exception codes for SEProperty interface
  const unsigned short      UNSPECIFIED_EVENT_TYPE_ERR     = 0;

  // SEEventTarget extends DOM 2 EventTarget and adds to it methods to
  // support event namespaces and groups.
  interface SEEventTarget : EventTarget
  {
    // analogous to DOM3 addEventListenerNS
    void addSEEventListener(in DOMString namespaceURI, 
                            in DOMString type, 
                            in DOMObject evGroup,
                            in SEEventListener listener);

    // analogous to DOM3 removeEventListenerNS
    void removeSEEventListener(in DOMString namespaceURI, 
                               in DOMString type, 
                               in SEEventListener listener);
  };

  interface SEComponent : SEProperty
  {
    readonly attribute DOMString version;
  }

  // SEProperty supports a hierarchy of property/value pairs

  interface SEProperty : SEEventTarget
  {
    readonly attribute SEProperty parent; // parent property interface

    readonly attribute DOMString namespaceURI; // namespace for this property

    readonly attribute DOMString name;         // name of this property

    attribute SEPropertyValue value;  // current value of this property

    readonly attribute SEpropertyMetaData mData;  // Meta data

    SEPropertyList getSEPropertyList(in DOMString namespaceURI,
                                     in DOMString propertyName,
                                     in boolean deep)
                             raises(dom::DOMException);
    SEPropertyList searchSEProperty(in DOMString namespaceURI, 
                                    in DOMString propertyName,
                                    in SEPropertyFilter sePropertyFilter,
                                    in boolean deep);

    boolean hasSEProperty (in DOMString namespaceURI,
                           in DOMString propertyName,
                           in boolean deep);

    SEProperty insertSEPropertyBefore(in SEProperty newChild,
                                      in SEProperty refChild)
                               raises(dom::DOMException);

    SEProperty replaceSEProperty(in SEProperty newChild,
                                 in SEProperty oldChild)
                          raises(dom::DOMException);

    SEProperty removeSEProperty(in SEProperty oldChild)
                         raises(dom::DOMException);

    SEProperty appendSEProperty(in SEProperty newChild)
                         raises(dom::DOMException);
  };

  // SEPropertyList provides the abstraction of an ordered
  // collection of SEProperty interfaces. The items are
  // accessible via an integral index, starting from 0.

  interface SEPropertyList
  {
    SEProperty item (in unsigned long index);
      readonly attribute unsigned long length;
  };

  exception DOMException {
     unsigned short   code;
  };

  // ExceptionCodes
  const unsigned short   NO_MODIFICATION_ALLOWED_ERR =1;
  const unsigned short   HIERARCHY_REQUEST_ERR =2;
  const unsigned short   NOT_FOUND_ERR =3;
  const unsigned short   INVALID_ACCESS_ERR =4;
  const unsigned short   INVALID_MODIFICATION_ERR =5;
  const unsigned short   NAMESPACE_ERR =6;
  const unsigned short   TYPE_MISMATCH =7;
  const unsigned short   NOT_SUPPORTED_ERR =8;
  const unsigned short   SYNTAX_ERR =9;
  const unsigned short   INDEX_SIZE_ERR =10;
                          
  // application defined filter for use with searchSEProperty
  interface SEPropertyFilter
  {
    boolean acceptSEProperty(in SEProperty sePropertyNode);
  };

  // SEEvent extends DOM2 Event interface and adds to it methods to
  // support event namespaces and to stop propagation of an event
  // within the same event listener group as specified in DOM 3 
  interface SEEvent : Event
  {
    readonly attribute DOMString namespaceURI;

   // analogous to stopImmediatePropagation in DOM 3.
    void stopImmediatePropagation();

   // analogous to initEventNS in DOM 3 
    void initEventNS(in DOMString eventTypeArg,
                     in DOMString eventNamespaceArg,
                     in boolean canBubbleArg,
                     in boolean cancelableArg);
  };

  // the DOM2 EventListener copied here for completeness
  interface EventListener
  {
    void handleEvent(in Event event);
  };
};

#endif // _SEPROPERTY_IDL_

7. Appendix - informative use cases

This section provides a brief informative illustration of how the System and Environment Framework could operate.

Other examples may include; CC/PP dynamic SEProperty updates and/or device context notifications such audio muting

7.1 GPS resolved Zip code I

The first example is based on location notifications provided by GPS that can be used to resolve the devices ZIP code location.

Step one is to initialize the gps location property to set the format to ZIP code and the update frequency to 10 seconds. The location update event is bound to ECMAScript code that reads the value and uses the DOM to write it as the content of a span element.

<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
      xmlns:ev="http://www.w3.org/2001/xml-events" >
  <head>
    <title>GPS location example</title>
    <!--
      Initialize GPS location property in System and Environment
      to provide updated values every 20 seconds with the format
      specified to be the ZIP code for the device's GPS location.
      The mechanism used to provide these updates is hidden from
      the application and might be based on a Web Service.
    -->
    <script type="text/javascript">
    <![CDATA[
      SystemEnvironment.location.format="zip code";
      SystemEnvironment.location.updateFrequency="20s";
    ]]>
    </script>

    <!--
      This is an event handler that listens for location update
      events raised whenever the location property is updated.
      The handler reads the value and sets it as the content
      of the span element with id="location". The defer attribute
      is used to prevent execution when document is first loaded.
    -->    
    <script defer="defer" type="text/javascript" 
      ev:event="se:locationUpdate">
      <![CDATA[
        var field = document.getElementById("location");
        var zipcode = SystemEnvironment.location;
        field.childNodes[0].nodeValue = zipcode;
      ]]>
    </script>
  </head>
  <body>
    <h1>Track your location as you walk</h1>
    <p>Your current zip code is: <span id="location">(please
    wait)</span></p>
  </body>
</html>

7.2 GPS resolved Zip code II

In the second example, a hypothetical setvalue element is used to initialize the GPS location property. The ref attribute uses an XPath function exported by the System and Environment framework to obtain the SEProperty node for the location. The location update event reads the value and places it into an XForms data instance. This is then bound to an XForms output control. This raises the interesting possibility of directly binding XForms controls to System and Environment properties.

<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
      xmlns:xf="http://www.w3.org/2002/xforms"
      xmlns:se="http://www.w3.org/2004/07/sysenv"
      xmlns:ev="http://www.w3.org/2001/xml-events">
  <head>
    <title>ZIP code tracker</title>

    <!--
      Initialize GPS location property in System and Environment
      to provide updated values every 20 seconds with the format
      specified to be the ZIP code for the device's GPS location.
      The mechanism used to provide these updates is hidden from
      the application and might be based on a Web Service.
    -->
    ]]>
    <se:setvalue ref="location()/format" value="zip code" />
    <se:setvalue ref="location()/updateFrequency" value="20s" />

    <!-- XForms data model for location information -->
    <xf:model>
      <xf:instance><data xmlns=""><zipcode/></data></xf:instance>
    </xf:model>

    <!-- use location update event to update XForms data model -->
    <xf:action ev:event="locationUpdate">
      <xf:setvalue ref="zipcode" value="environ:location()"/>
    </xf:action>
  </head>
  <body>
    <h1>Track your location as you walk</h1>
    <p>Your zip code is: <xf:output ref="zipcode"/></p>
  </body>
</html>

8. References

[CC/PP]
"Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0", W3C Recommendation 15th January 2004. See: http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/
[DevInd]
W3C Device Independence Activity. See: http://www.w3.org/2001/di/
[DOM]
W3C Document Object Model (DOM) Technical Reports. See: http://www.w3.org/DOM/DOMTR
[LIF]
"Location Interoperability Forum, Mobile Location Protocol Specification Version 3.2.0", OMA-LIF-MLP-V3.2.0 Specification, LOC, 26 November 2003. See: http://www.openmobilealliance.org/ftp/Public_documents/LOC/Permanent_documents/
[MMI Framework]
"Multimodal Interaction FrameWork", World Wide Web Consortium, W3C NOTE 6th May 2003. See: http://www.w3c.org/TR/mmi-framework/
[MMI Reqs]
"Multimodal Interaction Requirements", World Wide Web Consortium, W3C NOTE 8th January 2003. See: http://www.w3c.org/TR/mmi-reqs/
[OMA]
"Open Mobile Alliance". See: http://www.openmobilealliance.org/
[OMG IDL]
"OMG IDL Syntax and Semantics" defined in The Common Object Request Broker: Architecture and Specification, version 2, Object Management Group. See: http://www.omg.org/technology/documents/formal/corba_2.htm.
[RDF]
"RDF/XML Syntax Specification (Revised)", W3C Recommendation 10 February 2004. See: http://www.w3.org/TR/rdf-syntax-grammar/
[UAPROF]
"WAP-174: UAProf User Agent Profiling Specification (1999)", as amended by WAP-174_100 user Agent Profiling Specification Information Note (2001) Wireless Application Protocol Forum. See: http://www.wapforum.org/what/technical_1_2.htm

9. Acknowledgements

The editors would like to recognize the contributions of the following members of the W3C Multimodal Interaction Group (listed in alphabetical order):