Last week I was in Louvain-La-Neuve, visiting the University and having a technical meeting with Jean Vanderdonckt’s group. We are producing fresh user interface models towards the convergence between IDEAL and UsiXML. The meeting was very productive and pleasant. In the meantime I had time to give a techtalk about Model-Based Authoring and Adaptation, and, of course, I talked also about MyMobileWeb. Below you will find the link
Welcome to Ubiquitous Web Applications Chapter
The Morfeo UWA Chapter is devoted to the creation of open source reference implementations of technologies around the concept of Ubiquitous Web and the Mobile Web access to the "Internet of Things".
In particular the technologies and reference implementations under the scope of the UWA chapter will deal with the following topics:
- UI technologies that abstract the details of how the user interface is realized on specific devices and browsers
- Advanced policies and formalisms (including those based on Semantics) that enable the adaptation to context
- Rich descriptions of devices (based on ontologies), and the means to expose this to Web applications
- Enable access to device capabilities (camera, NFC, GPS, screen orientation, etc) from Web browsers
- Remote displaying of user interfaces in devices
- Technologies for searching and discovery of devices / services / information in the ubiquitous web
- Application of emerging technologies such as RFID or NFC to the Ubiquitous Web Applications space
- 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 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 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‘);
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.
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.