Delivery Context: Client Interfaces (DCCI) 1.0

1.1 Uses for DCCI

The key uses for DCCI are related to adaptation[GLOSS]. One major use is in supporting devices that are capable of interaction with users in a variety of modalities[GLOSS]. For example, a device may be able to interact visually, or using voice, depending on the user's current context.

The W3C Multimodal Interaction Framework [MMI] identifies the core components for multimodal systems. At its heart, lies the Interaction Manager [IM], which coordinates data and manages execution flow from various input and output modalities. DCCI can provide the Interaction Manager with dynamic access to the properties that represent the current delivery context. This can include the properties of the device and of the network and user preferences. These properties can indicate which modalities are supported and which are currently active. The DCCI can retrieve this information and, additionally, can provide a means to enable or disable particular modality functions. It also provides notifications when properties change. Such changes might occur as a result of a user action and might indicate that a user now prefers a different modality to be used.

In providing mechanisms to query and update delivery context properties, and to report changes via events, DCCI directly supports the basic W3C Multimodal Interaction Requirements [MMIReqs] (MMI-G14, MMI-G15, MMI-A4).

Another major use for DCCI relates to content adaptation for device independence. Materials to be used on a particular device may need to be tailored to take account of that device's particular capabilities. Layout, styling and the media associated with a web page may all need to be tailored based on the delivery context to achieve a good user experience. Where the tailoring is based on dynamic properties, it may be necessary to provide adaptation capabilities on the client. In this type of scenario, DCCI provides an interface that can be used to access the delivery context in support of highly dynamic adaptation.

1.2 Reading the Specification

1.3 Documentation Conventions

2.1 Interfaces

Interfaces provide a way to access delivery context information regardless of the way that information is actually stored and represented. This can be important for use on clients, particularly when implementations may have to execute on devices with restricted memory, processing power and battery life. Interfaces are also important for server-side implementations. A number of vendor-specific representations of delivery context are now in existence. Standardized interfaces can provide common mechanisms that can be used by authors regardless of the particular representation in use.

DCCI is an interface that focusses on making properties from the delivery context available to code executing within a web client[GLOSS]. Other interfaces focus on making similar information available to code executing within web servers[GLOSS].

Some of these server-side interfaces are primarily concerned with static information. This comprises the subset of the delivery context that is common to all instances of a particular device. The W3C Mobile Web Initiative's Device Description Working Group [DDWG] is developing a standardized interface suitable for accessing this kind of information.

Other interfaces are more concerned with dynamic and highly dynamic properties. The Open Mobile Alliance [OMA] is working on standardization of this style of interface in the Device Capabilities sub-working group of its Browser Technologies working group [BT DCAP].

One set of interfaces is specifically oriented at providing access to the delivery context directly from markup languages. The Delivery Context: XPath Access Functions [XAF] provides access to the delivery context from XPath expressions, which can be embedded in markup languages.

2.2 Representations

Prior to the work in defining interfaces, previous standardization work concentrated on defining representations of the properties of the delivery context. In particular, W3C's Composite Capability/Preference Profiles [CCPP] provides a framework for representations of delivery context properties. It is based on the Resource Description Framework [RDF]. CC/PP does not itself specify a particular vocabulary and so does not provide a representation of the delivery context. However, it provides the framework on which such representations can be built.

By adding a specific vocabulary to CC/PP, the OMA's User Agent Profiles (UAProf) specification [UAPROF] does provide a representation of delivery context. Typically, UAProf tends to be used to represent rather static properties of the delivery context. UAProf profiles are normally associated with a URI. A profile needs to be accessed, parsed and analyzed to allow the information about properties to be retrieved.

3.1 Property Datatypes

Each property in the delivery context is associated with a given datatype. Individual properties may , for example, be numbers or strings.

3.2 Property Interfaces

Node

Some DOM operations return individual items in the form of a DOM Node. Where such an item represents a property of the delivery context, the Nodewill actually be a DCCIProperty.

3.3 Property Collections

NodeList

Some DOM operations return collections of information rather than individual items. When this happens, the collection is in the form of a DOM NodeList. Where such a collection represents a set of delivery context properties, each Node in the NodeList will actually be a DCCIProperty.

3.4 Property Initialization

DCCI provides mechanisms to access properties within the delivery context. It does not provide the means by which properties in the delivery context are managed. Implementations of DCCI must provide those facilities by whatever means is appropriate. Properties may be added and removed from the delivery context at any time in response to events external to DCCI. For example, new properties may appear in the delivery context when a user enables a particular function in their device. Property values may also change at any time, of course.

The mechanisms by which implementations of DCCI manage properties and their values within the delivery context is out of scope for this specification.

3.5 Properties in Distributed Systems

In some contexts, devices may take part in networked interactions with other devices. In such cases, some aspects of the delivery context may represent properties associated with those other devices or on servers that are also part of the network. For example, where a device is connected in some way with a printer via an intervening network, the delivery context might contain properties that indicate the toner or ink levels available in the printer. Where the delivery context includes information that is not directly held on the device on which DCCI is executing, there may be network delays involved in accessing the information. Implementations should ensure that delays in accessing such information do not cause applications using DCCI to block for long periods of time.

The mechanisms and network protocols used to distribute and synchronize delivery context properties between devices and other network components are outside the scope of this specification. Some possibilities include SIP Events [SIP], Web Services, and technologies such as Universal Plug and Play [UPnP].

3.6 Metadata

Metadata can be directly or indirectly associated with any property accessed via DCCI. Some potential examples of metadata include the version of a property interface, and timestamps for property creation and modification. Richer metadata could describe ontologies of properties, and be expressed using powerful metadata frameworks like OWL [OWL] for the purposes of authoring solutions.

DCCI provides mechanisms for accessing the metadata associated with a property. However, the details of the particular kinds of metadata used and their representation is outside the scope of this specification. The mechanism for accessing property metadata is based on the DCCIMetadataInterface and DCCIMetadataInterfaceType properties associated with each delivery context property. The first of these properties provides access to the metadata-related information while the second defines its datatype. As an example, a DCCI implementation might choose to provide metadata via a URI represented as a DOMString. In this case, DCCIMetadataInterface would hold the URI and DCCIMetadataInterfaceType would indicate that the type was DOMString. As an alternative, the implementation of a particular property could return an interface as the value of DCCIMetadataInterface. Operations on that interface would then yield the metadata.

These properties are described fully in 5.1 The DCCIProperty Interface.

4.1 Querying and Searching

DCCI supports direct access to the properties in the delivery context through the searchProperty() method in the DCCIProperty interface. This method provides direct access to a specific property when both the namespace and property name are supplied. However, it can also provide access to sets of properties if wild cards are used. For example, suppose that part of the delivery context is the tree shown in Figure 2.

Figure 2. An example property hierarchy.

In Figure 2, there are two cameras associated with the device. One is in a namespace represented in the figure by the prefix base. The other is in the namespace represented by the prefix acc. This might represent the situation where a more capable camera module has been plugged in as an accessory to enhance the capabilities of the device.

The value of the property BitsPerPixel for the accessory camera could be retrieved by using a query that explicitly references the name BitsPerPixel and the namespace associated with the prefix acc. A query that merely referenced the name and used the wildcard * for the namespace would retrieve a list containing both values. Searching such as this may be valuable when the content of the delivery context is highly dynamic and its structure is not completely predictable.

In fact, of course, searches like this might actually retrieve other properties also called BitsPerPixel. Other components of the device, such as any displays that it has, might also have properties with this name. Ontologies of delivery context properties try to address such ambiguity by defining unique property names.

Full details of the function available for querying and searching for property values are given in the section on the searchProperty() method in the DCCIProperty interface.

4.2 Using Events

DCCI implementations provide events that can be used as notifications that changes have occurred in the delivery context. In addition to the usual DOM events, which can, for example, indicate changes in the structure of the delivery context as properties are added or removed, DCCI adds a new DOM Event, with a value of DCCI-prop-change. This event is raised when a property changes value.

DCCI does not define any additional specific events to report particular situations that may be associated with specific properties. Examples of situations include:

• an alert to indicate that the battery level in the device is low

• an alert to indicate a loss of connectivity to the network

• an alert that the performance of speech recognition has fallen below some predefined quality threshold

DCCI implementers are expected to use the available DOM and DCCI events with appropriate data to indicate such situations.

4.3 Access Control

DCCI provides the means for accessing the delivery context, which includes information such as user preferences, device characteristics and environmental factors. Some of this information could be considered sensitive. As a consequence, a form of access control would be desirable to protect such information.

The definition of the details of such access control capabilities is outside the scope of DCCI. However, where an implementation provides access control and an access violation is detected, the exception DCCIException with error code ACCESS_VIOLATION_ERR must be raised.

4.4 Errors

In general, DCCI operations return values that may indicate error conditions. In "exceptional" circumstances, DCCI operations may raise exceptions, for example, when an operation is impossible to perform.

5.1 The DCCIProperty Interface

interface DCCIProperty : Element {

  //Attributes
  attribute any value;
  readonly attribute DOMString valueType;
  attribute DOMString propertyType;
  readonly attribute boolean readOnly;
  readonly attribute DOMString DCCIMetadataInterfaceType;
  readonly attribute any DCCIMetadataInterface;

  //Methods
  boolean hasProperty(in DOMString namespaceURI, 
                      in DOMString propertyName, 
                      in boolean deep)
          raises(DCCIException);                    
                      
  NodeList searchProperty(in DOMString namespaceURI, 
                          in DOMString propertyName, 
                          in DCCIPropertyFilter dcciPropertyFilter, 
                          in boolean deep) 
           raises(DCCIException);                    
};

5.2 The DCCIPropertyFilter Interface

interface DCCIPropertyFilter {

  //Methods
  boolean acceptProperty(in DCCIProperty property)
          raises (DCCIException);

};

5.3 The DCCIComponent Interface

The DCCIComponent interface forms the root node of the DCCI hierarchy. DCCIComponent derives from the DCCIProperty interface and contains an additional read-only attribute called version. The value of the version attribute is the version number of the Delivery Context: Interfaces component. The value of version for this release is the string "1.0". The parent and value attributes of a DCCIComponent have the value null.

5.4 The DCCIException Exception

DCCI defines one specific additional exception, named DCCIException, in addition to those that can defined by the DOM itself.

exception DCCIException {
   unsigned short code;
};
//Exception codes
const unsigned short ACCESS_VIOLATION_ERROR = 1;
const unsigned short NOT_SUPPORTED_ERROR    = 2;
const unsigned short PROPERTY_FILTER_ERROR  = 3;

6.1 The DCCI-prop-change Event

DCCI raises this event to notify a change in the value of a property. This event is a normal DOM Event with its type attribute set to DOMString literal value "DCCI-prop-change".

Where an implementation is based on DOM 3, it must mark the event as being within the DCCI namespace. In particular it must set the namespaceURI attribute of the DOM Event to that of the DCCI namespace.

6.2 How DCCI Uses Existing DOM Events

DCCI uses existing DOM events (see for example [DOM2-Events]) to notify listeners about particular changes in the structure of the DCCI DOM. In particular DCCI implementations must use the following DOM Mutation events to notify listeners about insertion of items into the DOM and about their removal.

DOMNodeInserted

This event is raised when a new property has been added to the DCCI DOM. The event is dispatched after the new node has been inserted. The target node of this event is the property being inserted.

DOMNodeRemoved

This event is raised when an existing property is being removed from the DCCI DOM. The event is dispatched before the property is removed from the tree. The target node of this event is the property being removed.

DOMSubtreeModified

This event is raised when the structure of the DCCI DOM changes in any way. Listeners can use it instead of the more specific events concerned with node insertion and removal. Depending on the nature of the change being made, implementations may choose to raise it after a single modification has been made to the DCCI DOM. Alternatively, implementations may choose to raise it only after a set of modifications has been applied. This latter case can accommodate situations in which multiple changes occur in rapid succession.

The target of this event is node that is the lowest common parent of the changes which have taken place. This event is raised after any other events caused by those changes have been raised.

7.1 Conformance Requirements for All DCCI Implementations

A conforming DCCI implementation must implement all the normative sections of this document.

A conforming DCCI implementation must implement the DOM EventTarget interface [DOM2-Events].

In a conforming DCCI implementation, the DCCIProperty interface must inherit from the DOM Element interface.

A conforming DCCI implementation must support the use of the isSupported()method, in the DOM Node interface, to enable code to determine the level of DOM used in the implementation of DCCI. Specifically, the following results must be supported by conforming implementations:

• Invocation of isSupported() on any DCCI node with the feature parameter set to "DCCI-DOM" and the version set to "2.0" must return true if the implementation of DCCI is based on DOM 2 and false otherwise.
• Invocation of isSupported() on any DCCI node with the feature parameter set to "DCCI-DOM" and the version set to "3.0" must return true if the implementation of DCCI is based on DOM 3 and false otherwise.

A conforming DCCI implementation must support all datatypes specified by the W3C DOM 2 specifications [DOM2-Core]

In a conforming DCCI implementation, DCCIProperty nodes must return ELEMENT_NODE as the value of their nodeType attribute.

In a conforming DCCI implementation, DCCIProperty nodes must return the name of the property as the value of their nodeName attribute.

A conforming DCCI implementation must raise the DOM ACCESS_VIOLATION_ERR Exception if it supports access control and detects an access violation.

A conforming DCCI implementation must raise the DCCI NOT_SUPPORTED_ERR Exception if an operation is requested that it does not support.

A conforming DCCI implementation must raise the DOM NO_MODIFICATION_ALLOWED_ERR Exception if an operation is requested that would result in a disallowed modification of the delivery context.

A conforming DCCI implementation must raise the DOM NOT_SUPPORTED_ERR Exception when an attempt is made to insert nodes with types other than DCCIProperty into the DCCI DOM. In particular, this applies if the DCCI implementation also supports the methods insertBefore(), replaceChild(), and appendChild() in the DOMElement interface.

In a conforming DCCI implementation, DCCIProperty nodes may return null for the value of the ownerDocument attribute.

A conforming DCCI implementation must implement DCCIMetaDataInterface as a DOMString unless the implementation is based on DOM 3, in which case it must be implemented as a DOMObject.

A conforming DCCI implementation may implement cloning, adopting and importing of nodes. However, it must raise a DOM NOT_SUPPORTED_ERR Exception for any operation of these operations that is not supported.

A conforming DCCI implementation should raise the most appropriate DOM Exception when it encounters an error not otherwise stipulated explicitly in this specification.

A conforming DCCI implementation may provide access to the root of the delivery context through a global variable. If this mechanism is chosen, the preferred name for the variable is DCCIRoot.

DCCI implementations must use the DOM Mutation events DOMNodeInserted, DOMNodeRemoved and DOMSubtreeModified to notify listeners about changes in the structure of the delivery context.

7.2 Additional Conformance Requirements for Implementations Based on DOM 3

In addition to the conformance requirements for all DCCI implementations, additional requirements apply to those implementations based on DOM 3.

A conforming DCCI implementation based on DOM 3 may support the use of the DOMImplementationRegistry to enable the DCCI DOMImplementation to be discovered. If this approach is used, the implementation must be identified by the DOMString literal value "DCCI 1.0". Additionally, if this approach is used, the implementation must provide access to the root of the delivery context using the getFeature() method of the DOMImplementation interface with the feature parameter set to the DOMString literal value "DCCI-Root" and the version set to the DOMString literal value "1.0".

A conforming DCCI implementation based on DOM 3 must support all the datatypes supported by the W3C DOM 3 specification [DOM3-Core].

In a conforming DCCI implementation based on DOM 3 DCCIProperty nodes must return the value of their textContent attribute as null.

A conforming DCCI implementation based on DOM 3 must implement DCCIMetaDataInterface as a DOMObject.

A conforming DCCI implementation based on DOM 3 may implement the event interfaces described in the [DOM3-Events]. Note that [DOM3-Events] adds the notions of event namespace, groups and categories to [DOM2-Events]. These may be useful features in the context of DCCI.

A conforming DCCI implementation based on DOM 3 must support the use of namespaces in events to distinguish between DCCI events raised by different properties. This allows events that have the same name but which were defined by defined by different organizations to be distinguished. They also allow code to listen for property events only from a particular organization.

8.1 DCCIException Interface

8.2 DCCIProperty Interface

Objects that implement the DCCIProperty interface have all properties and functions of the EventTarget and the Element interfaces as well as the functions and properties defined below:

8.3 DCCIComponent Interface

8.4 DCCIPropertyFilter

This is an ECMAScript function reference. The method takes in a DCCIProperty object as parameter and returns a boolean value.