20:11:44, Categories: News
Coming soon: The DDR Simple API
The two weeks leading up to the DDWG face-to-face in Seoul, Korea, have been very busy, and much of it is still playing out on the public mailing list
. In the conference call on the 18th, there was much discussion on the role of the Property Name and whether the aspect should be a part of that name. A week later and we have an API where the Property Name and aspect are seen separately. They can be combined in a property reference, where the namespace of the aspect is determined in the vocabulary to which the aspect is applied. Together with evidence representing HTTP headers, this data can be used in a query to retrieve contextual information from a DDR.
For those who have not been following closely, an 'aspect' is a qualifying term that can accompany a property name, so that it is clear which part of the delivery context the property refers. If, for example, you have a "pixelWidth" property and you use it in a hardware aspect then you would be referring to the physical width of the screen (in pixels). In a browser aspect this property would refer to the window width. In an image aspect it would be the width of the image. And so on. The Simple API permits default aspects to be used. A vocabulary of properties may include aspects too, and this is an approach likely to be used by default in the Simple API.
Of course, the devil is in the details, and much still remains to be decided. The issues include: factory methods, exceptions, constants, convenience methods (that use general string parameters) and robust methods (that use specific typed parameters). Keeping the typical programming languages of the Web in mind is also challenging. Where noted, certain approaches will be avoided if binding to a particular popular language poses a problem.
To keep all this work concrete, the group is using Java as an example binding. Even this has run into some concerns as Java 1.4 has been deprecated. Other bindings will also be prepared.
Next week, with Seoul being the hub of two days of face-to-face work, a final editors’ draft of the API should be completed. This version will be known as the "Simple API", recognising that this has been designed for easy adoption in the most common use case, that of adapting content for delivery to mobile devices on the Web.
The official First Public Working Draft
will come directly from this editors' draft, and it is hoped that the FPWD can move efficiently on the path towards a formal Recommendation as soon as possible. Several implementations have already been promised.
An editors draft of the Java binding
can be viewed online while all this is happening.
Comments are always welcome via the public mailing list.
Meeting Summary - 11 Feb 2008
[Meeting summary – 11 Feb 2008] Aspects in the Simple API, Catalogue methods, Core Vocabulary near completion.
[Aspects] The group discussed the interpretations of the concept of Aspect. One view sees an Aspect as a term of disambiguation for property definitions. Another sees it as an abstraction of types of components of the delivery context. It was agreed that a component could have more than one Aspect, though perhaps this is a simplification. For the Simple API, it was agreed that a very small number of Aspects should be considered. The hardware platform and the requesting client are the main Aspects. Representing Aspects in the Simple API needs to be done in a way that could be extended to an Advanced API. Consequently, it was resolved that Aspects could be included as optional parameters in the property retrieval methods. This provides extensibility without codifying the chosen Aspects in the API itself. Furthermore, the representation of Aspects should be as simple a mechanism as Strings though the actual use of String types is not favoured. Perhaps IRIs could be used. New exceptions were also considered: one to indicate that a query could return more than one value (i.e. different values depending on different Aspects) and another exception to indicate that an inappropriate Aspect was given as a parameter.
[Catalogue] It has been proposed that the Simple API also include methods to inspect the available vocabularies and available properties in any given implementation. Such methods could be used to enable only relevant and available data to be retrieved. While possibly redundant, the “exists” method was also discussed and found some support as a means of avoiding exceptions.
In general, it was agreed that the current set of classes and methods in the Simple API are both useful and (probably) simple to implement. This was put forward as one of the criteria of assessment for the Simple API. To further explore the Simple API as it nears completion, it was agreed that the Morfeo-hosted sample Java binding would be updated to reflect the decisions of this meeting, permitting the group to conduct discussions with some concrete examples.
[Vocabulary] The Core Vocabulary is near completion. The absence of an official normative version of the UWA ontology means that the vocabulary will not be able to reference the ontology in a normative way, but the group agreed that an informative section in the final document would make reference to the ongoing development of the ontology by the UWA. Furthermore, it was decided that the UWA participants would be best placed to describe the binding from the Core Vocabulary to the (still evolving) UWA Ontology. Some other outstanding issues were also resolved, such as references to XHTML-MP extensions, the agreement to have only ECMAScript MP listed in the enumeration of scripting languages used in mobile contexts, and recognition of the probable unavailability of normative definitions for device artefacts (such as a trackball input).
Attendees: Jongpil, Kevin, Martin, Jo, Matt, Bryan, Rodrigo, José
Meeting Summary - 4 Feb 2008
[Meeting Summary - 4 Feb 2008] The DDR API: Simple and Advanced.
The participants were given a summary of the results of the DDR API editors’ meeting that took place last week. The primary outcome was a simplified API that forgoes the support for Aspect, a mechanism that enables properties to distinguish how they are applied to different parts of the delivery context. The Simple API also masks the use of the Context Key, by only having query methods that take direct context evidence as input, and giving values for vocabulary terms as output. An early version of the Simple API in Java has been placed into the public domain. There was some disappointment that the Simple API would not incorporate many of the more complex features the group has been working on for the past year, and that there was a danger that the Simple API would not advance much beyond existing technologies. It was also noted that the more complex features could be captured in a new Working Group Note, to become the foundation of a successor Advanced API.
It was also noted that the Advanced API could eventually evolve to support access to any part of the delivery context, not just knowledge available beforehand in a repository. Furthermore, the applicability of such an API would extend to any modality of the Web, not just mobile devices. In time, the Advanced API would exceed the scope of the DDWG’s charter, so while it is valuable to the goals of the DDWG and the MWI, it should properly be transferred in time to a group within the W3C that has a greater mandate.
Some new proposals were discussed, mainly to suggest that the group focus on the Simple API while developing and capturing the remaining features for a future Advanced API. The absence of Aspect in the Simple API presents a problem with the Vendor, Model and Version terms in the latest draft of the Core Vocabulary. These terms can only be properly interpreted when given an Aspect (such as Hardware, Screen, Browser) in order to remove the ambiguities. Possible solutions include creating alternative terms in the vocabulary, so that the terms specify Aspects (e.g. BrowserVendor and PlatformVendor). Alternatively, terms that require Aspects could be removed from the vocabulary. Neither approach attracted much support, so an alternative was proposed: to consider a simple means of supporting Aspect in the Simple API.
Having discussed the pros and cons of the Simple and Advanced APIs, the use or absence of Aspects, and the desire to make progress within charter and in good time, the group came to the following majority conclusion: Split the API into Simple and Advanced. The Simple API provides a foundation for the development of adaptive content to be completed within the current charter. The Simple API is to be based on work resulting from the Editors Meeting with possible elaboration for example to introduce "Aspects". The Advanced API is moving towards a general interface for accessing delivery context information, not just a priori device knowledge and to complete it properly would be out of scope for DDWG. The group will continue work on the Advanced API with a view to capturing what has been learned, and developing the work to the point where it can be handed over to a group with broader scope.
Remaining issues regarding the vocabulary, some methods of the Simple API and conformance requirements were deferred to be discussed via the mailing list.
Attendees: Matt, Bryan, Rotan, Martin, Jo, Anders, Rafa, José, Abel, Rodrigo, Nacho