MWI Device Description Working Group News

Tuesday, June 24th 2008

DDR Simple API implemented successfully

It has been a while since DDWG reported, because the group has been busy dealing with technical comments on the draft API that was published several weeks ago. Comments were managed in public, and mainly they were addressed by providing additional clarity and a few adjustments to the text. Since completing this work, the group has attended a face-to-face meeting in France where several successful implementations were demonstrated. The implementation report summarises the results, which show that all of the API features are viable.
The successful implementation by several independent contributors will go a long way to progressing this specification towards being a W3C Recommendation. If you are interested in implementing it yourself, check out the latest stable version.
There's a pretty picture of the API on the DDWG home page.

Rotan Hanrahan

Wednesday, April 9th 2008

DDR Simple API published

The W3C MWI Device Description Working Group has published the First Public and Last Call Working Draft of Device Description Repository Simple API.
Web content delivered to mobile devices usually benefits from being tailored to take into account a range of factors such as screen size, markup language support and image format support. Such information is stored in "Device Description Repositories" (DDRs).
This document describes a simple API for access to DDRs, in order to ease and promote the development of Web content that adapts to its Delivery Context. Comments are welcome through 1 May.
The document includes links to Java and JavaDoc for the API, and also IDL and WSDL are provided. Additional implementation languages will be demonstrated via the DDWG home page in due course.
On behalf of the DDWG
Rotan Hanrahan
Chair

Rotan Hanrahan

Tuesday, March 25th 2008

Meeting Summary – 17 March 2008

[Meeting Summary – 17 March 2008] After Korea, End of charter, Comments, Commitments to implement.
[Korea] Following the face-to-face in Korea, the JavaDoc of the Simple API has been updated to reflect the group resolutions. The updated Core Vocabulary is expected in a few days, and the updated draft of the API Recommendation is also expected soon. These updates are to reflect the decisions already taken by the group, not to introduce anything since the face-to-face. There are some minor contributions outstanding such as tidying of the “bootstrap” class that instantiates the Service object. Prior to the face-to-face we had IDL and WSDL versions of the draft API. These will also be updated soon. The updated IDL will be accompanied by an explanation of how the IDL is derived from the Java definition. Both IDL and WSDL will be non-normative appendices of the API Recommendation. The Perl demonstration will also be updated, and a C# binding is expected soon. All of these will contribute to explaining the API and to demonstrating its language-neutrality. Some outstanding issues remain, but it was decided that the best way to resolve these was via comments during the Last Call phase of publication.
[Charter] With the impending publication of the Simple API and the Core Vocabulary, only the calls for implementations/contributions remain in the deliverables according to the charter. For this reason, the group now believes it is reaching the end of its life, coinciding with the projected end of its chartered period. A final face to face meeting is now being planned for June.
[Comments] Some comments on the recent API work are to be delivered to the editors soon, and will subsequently be made public along with the updated documents.
[Commitments] Group participants were asked for information on intended implementations and demonstrations of the proposed technologies. From the feedback, we can expect implementations in Java, IDL, WSDL, Perl and C# over the next few weeks. A public call for implementations and data contributions will be made after the current documents have been updated and published.
Attendees: Rotan, Pontus, Jo, Nacho, Rodrigo, Rafa, Matt.
(Note: There was no meeting this week. The above is a summary of last week’s meeting.)

Rotan Hanrahan

Wednesday, February 27th 2008

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.

Rotan Hanrahan

Thursday, February 14th 2008

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é