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.