This paper explains the rationale and approach for the Bondi Device Status API [1] to be released on June 2009. The aim is to introduce developers on the conceptual model and key concepts utilised by the API and to describe the main methods. Then we continue with a comparison of the proposed API with Nokia's [2], explaining the main advantages of our approach. Finally we summarize the main conclusions obtained and the future work to be done.
The intended audience of this document is anyone interested in the future of Device APIs and particularly those mobile web application developers interested in exploiting the information about the characteristics and status of the user's device.
The Bondi Device Status API Conceptual Model is based on the DDR Simple API [3], a W3C Recommendation which defines an API for retrieving device characteristics in order to enable the automatic adaptation of mobile content.
The Bondi Device Status API models a device and its related entities as an aggregation of different Components. A Component is an instance of an Aspect. An Aspect represents a category of hardware or software that participates in delivering a Web experience [3]. Examples of Aspects are Display, Camera, Web Browser, Cellular Network, etc. The Device itself is an Aspect. There can be Aspects with many Components (for instance Camera) while others typically only have one, such as the Display.
A Property represents a characteristic of an Aspect. Examples of properties are vendor, version, batteryLevel, currentOrientation, etc. There are properties that apply to many different Aspects, such as version or vendor, while others only apply to an specific Aspect, for instance, batteryCapacity. Properties have names and data types for their values (boolean, int and so on). A Property may have an "unknown value" when the actual value is not known to the implementation.
Property names and Aspect names are namespaced to allow independent naming and evolution of sets of Properties. In the Bondi Device Status API, Aspects share the same namespace as the properties with which they are associated. A Vocabulary is a set of Properties and the Aspects with which the Properties are associated. Vocabularies are identified by an IRI and provide a namespace for the Property Names and Aspect Names that compose them. The IRI that identifies the vocabulary also identifies its namespace. Vocabularies should declare:
In addition vocabularies may also define Component Aliases in order to distinguish
between components from a logical point of view. For example, the Bondi Vocabulary defines the __primary and __secondary special reserved identifiers to denote the primary and the secondary cameras of a device respectively.
Bondi has defined a baseline Vocabulary [5] of Aspects, Components and Properties. Such Vocabulary is based on the Delivery Context Ontology [4] specification, a W3C normative reference document which describes a formal model of the Delivery Context.
The Bondi API supports the concept of Default Vocabulary in order to make developer's life easier. In Bondi's implementation the Bondi Vocabulary it is always used by default.
This example shows how to obtain the level of the default Battery Component of a Device. The developer only needs to specify the property name, as the Aspect and Component are the default in accordance with the Bondi Vocabulary.
/* Gaining access to the main API object */
var deviceStatus = ....;
var batteryLevel = deviceStatus.getPropertyValue('batteryLevel');
if(batteryLevel) {
alert(batteryLevel);
}
else { alert('Battery Level not known!!!'); }
This example demonstrates how to obtain the version of the device and the version of the operating system. It is a bit more complicated as it deals with a property, version, that has more than one associated Aspect. In this case the developer needs to provide a Javascript Object with the name of the Property and the name of the Aspect.
var deviceStatus = ....;
var propertyRef1 = {property:'version',aspect:'OperatingSystem'};
var propertyRef2 = {property:'version',aspect:'Device'};
var osVersion = deviceStatus.getPropertyValue(propertyRef1);
var deviceVersion = deviceStatus.getPropertyValue(propertyRef1);
This example explains how to deal with a more complex use case where the developer is interested in knowing about the resolution width of both the primary and secondary cameras of the device. In this case it is necessary to provide the name of the property, the name of the aspect and finally the component alias that denotes wich camera she is referring to.
var deviceStatus = ....;
var propertyRef1 = {property:'resolutionWidth',aspect:'Camera',component:'__primary'};
var propertyRef2 = {property:'resolutionWidth',aspect:'Camera',component:'__secondary'};
var resWidthPrimary = deviceStatus.getPropertyValue(propertyRef1);
var resWidthSecondary = deviceStatus.getPropertyValue(propertyRef2);
This example shows how to obtain the list of present WiFi networks and listing their SSID. (Please note that this task can take a long time and might be appropriate to do it asynchronously).
var deviceStatus = ....;
var wifiNetworks = deviceStatus.getComponents('WiFiNetwork');
var pref = new PropertyRef();
pref.property = 'ssid';
pref.aspect = 'WiFiNetwork';
for (var network in wifiNetworks) {
pref.component = network;
alert(deviceStatus.getPropertyValue(pref));
}
The Bondi API provides different methods to obtain the list of properties, aspects and vocabularies supported by an implementation.
First of all we celebrate the fact that the proposal coming from Nokia is not very different than ours, which means that reaching consensus during a future standardization work will not be very hard. For example, the concept of 'Channel' in Nokia's API seems to be similar to the concept of 'Aspect' in our proposal.
Nonetheless, we believe that Bondi's proposal is more powerful and flexible. In order to justify our affirmation, We have made a comparison taking into account the following criteria: scalability, flexibility, extensibility, simplicity, functionality and compliance with existing standards.
In terms of scalability, flexibility and extensibility it is undoubtly clear that Bondi's proposal is superior due to the usage of a generic framework based on vocabularies. Such approach allows a clear separation between the API and the actual data managed. Nokia's proposal based on specific interfaces for declaring the information to be retrieved makes flexibility, extensibility and scalability much more difficult.
In terms of simplicity, even though our framework is more powerful, the 'HelloWorld Example' in Bondi's proposal is much more compact and concise than Nokia's.
With regards to functionality, Bondi's API provides a way to obtain information about the different Components of an Aspect, wherareas in Nokia's it is not possible. On the other hand Nokia has defined explicitly asynchronous versions of the property retrieval methods wherareas in Bondi there is only one method for "permanent" subscription to property changes. In addition Nokia's proposes to declare explicitly which operation modes (synchronous / asynchronous) support each channel, which might be a good idea.
The design of the Nokia API allows to obtain at once all the properties of a channel. On the other hand in Bondi's there is no such an operation. Nonetheless, it would not be difficult to implement such a method in Bondi's
Regarding standards compliance, we believe that Bondi's work is better in terms of compliance with existing W3C standards. Particularly we have defined a model which it is both compliant with the DDR Simple API framework and also with the Delivery Context Ontology work.
Last but not least, the name which has been chosen by Nokia for the API 'System Information' might be more accurate than 'Device Status', as the API not only serves to provide information about the device, but also to the rest of elements that are part of the computing platform, including the network.
We are planning to enrich the Bondi's APIs with new methods to address functionalities which are not yet covered, namely:
We have made an introduction to the Bondi's API for Device Status, which is based on a conceptual model that decouples the API from the specific Vocabularies used to refer to the information. Bondi's API establishes a three dimensional view of the computing platform, structured around Components, Aspects and Properties.
Nokia's System Information API is structured around a two dimensional schema of 'Channels' and concrete SystemData data structures for different elements (Bluetooth, Network, etc.).
The conclusions of our comparison is while Nokia's is more complete with respect to asynchronous and one shot retrieval schemas, Bondi's is much more powerful, flexible, concise and extensible thanks to the generecity provided by the Vocabularies and the conceptual model.
We believe that the convergence of the two approaches in a future W3C standard is feasible, taking the best of both proposals, complementing the genericity advocated by Bondi with the versatility (synchronous, asynchronous, one shot) offered by Nokia's.