According to the W3C’s Glossary of Terms for Device Independence, the Delivery Context is a set of attributes that characterizes the capabilities of the access mechanism, the preferences of the user and other aspects of the context into which a web page is to be delivered. Examples of such attributes are:
- the model and vendor of the device
- the screen resolution
- browser’s supported standards (XMLHttpRequest, DOM Level, etc.)
- the location
- the network (GPRS, UMTS, etc),
- the user and its circumstances, etc.
The Delivery Context is an important source of information that can be used (typically at server side) to adapt materials from the Web to make them useable on a wide range of different devices with different capabilities. Moreover, AJAX applications, executing on modern browsers, are also demanding access to the Delivery Context. For example, an AJAX-based web application or widget might need to ask for the location of the user’s device via Javascript, and use the retrieved coordinates to put them in a Google’s Map.
The W3C’s Ubiquitous Web Applications Working Group is currently working on an ontology that describes formally the Delivery Context. The Ontology will be the normative and formal description of the Delivery Context, its aspects, components and properties:
An aspect is a type of Delivery Context component. Examples of aspects are the device hardware, the operating system, browsers, cameras, etc.
A component represents an specific instance of an aspect. For example, if a device has two cameras the Delivery Context will be composed, at least, by two components which will be instances of the “Camera” aspect.
The ontology is modelled with OWL, where aspects and its properties are represented by OWL classes and properties (identified by URIs), respectively. Components are modelled using OWL instances.
It is important to remark that the Delivery Context is composed by two kind of properties:
- Session-invariant properties (a.k.a. static properties). For example, the ‘device’s weight’ is a property that will not change during a user’s session. Furthermore, the property value will be the same for all the instances of an specific device class. As a result, it will be suitable of being stored on a Device Description Repository as there is “a priori knowledge” about the property value.
- Session-variant properties (a.k.a. dynamic properties). A typical example is ‘battery level’.
It is noteworthy that one cannot characterize properties as static or dynamic solely taking into account the property itself. That’s because a property that cannot change in a device, can change in another device. For example, there are some devices which height can change (they have a mechanism for folding or unfolding a small keyboard), while in others the height will be always constant.
Nowadays there are no universal APIs for the Delivery Context. At the server side there are APIs targeted to the problem of device and browser identification and “a priori” retrieval of property values. Leveraging the classic WURFL and UAProf technologies, there is an upcoming standard for this kind of information, which is the Device Description Repository API, that is being defined by the W3C Device Description Working Group. This API is intended to server-side access to device properties that are stored in Device Description Repositories (DDRs). As a result, the API will only cover access to properties that are intrinsic to the device, but not highly dynamic properties.
With regard to dynamic properties, there is an upcoming OMA standard, called DPE, aimed at defining the standard mechanism to propagate property value changes between the device and the application server, enabling access to dynamic properties at the server side. It is expected that in the future Telco Operators will support on their networks DPE-compliant infraestructure which will enable this kind of functionalities.
On the client side, there is a standard that has not taken over: DCCI. Delivery Context Client Interfaces. It is six years old and the industry nearly hasn’t implemented it. Moreover, the spec itself has changed its name three times, from DPF to DCCI passing through DCI. One of the main drawbacks of the DCCI spec is its dependency on the DOM (Level 2 or Level 3) which makes it difficult to implement. Also there are no simple interfaces for developers, who, as we know from the experience gained from the HTML’s DOM, often get into the burden of trees and nodes manipulation. It is agreed that DOM-style interfaces are powerful, but the reality is that everybody wraps it on convenience functions, such as those provided by the most popular AJAX frameworks such as Prototype or jQuery.
Other related standards are the Delivery Context XPATH Access Functions which provide a set of convenience functions to retrieve information of the Delivery Context when XPATH is used. The main drawback of this spec is its uncompleteness (the spec only covers the properties used by CSS Media Queries) and its dependency on XPATH. It is clear that something more general (not bound to any language) is needed regarding convenience functions for the Delivery Context.
The popularity of Widgets deployed on mobile devices has leaded to the proliferation of propietary APIs for Delivery Context property retrieval using Javascript. Examples are the Opera Platform or the Nokia S60 propietary APIs for widgets. This kind of approach is not good for interoperability or massive deployment of Mobile 2.0 services.
The conclusion is that there is a need for universal and standard interfaces for the Delivery Context. This intefaces should be as simple as possible and based on convenience methods and functions. Furthermore, a well-designed spec will allow the definition of interfaces easyly implementable both on Web Browsers (by the most popular AJAX Frameworks) or at the server side (in Java, Python, .NET, etc.).
Let’s sketch how would be the look and feel of these proposed interfaces. In general the interfaces will be as simple as:
DeliveryContext dc = getDeliveryContext();
Component camera = dc.getComponent(’Camera’);
PropertyValue val = camera.getProperty(’cameraResolution‘);
Of course Javascript developers will demand something like:
$DC(’Camera’).cameraResolution
which also should be standardized. It is important to remark that the property names will be those already present in the ontology, although developers, indeed, will not have to care about the URIs.
Also it should be possible to register event handlers for property changes, preferably using declarative approaches such as a flavour of XML Events 2.
<ev:listener event=”dco:propertyChanged” handler=”javascript:updateMap()”
if=”dcoProperty() == ‘location’” />
Nevertheless, nothing precludes the Delivery Context Universal APIs to live and interoperate with the DCCI as current AJAX Frameworks do with the DOM.
In this post we have presented what is the problem statement about the Delivery Context and its interfaces and we have sketched the solution, the Delivery Context Universal Interfaces. Under the MyMobileWeb project, We are working now in producing a spec for the API behind these universal interfaces. The first draft of this spec will be available by the end of January 2008. We plan to implement the spec in Java and Javascript and we will develop adaptors to other propietary APIs such as Opera Platform or Nokia S60. We will keep you updated!!!
