Meeting Summary - 9 July 2007
[Weekly conference call, 9 July 2007] F2F preparations. More vocab contributions. Wiki-to-doc. Working with OMA. Recording bugs and limitations in the vocabulary. Using DI docs. Requirements, conformance and assessments. Details follow.
[F2F] The face-to-face meeting is next week in London. The agenda for the two day event is now complete, though the order of topics still needs final confirmation.
[Vocab] Two more contributions to the DDR core vocabulary were received recently. These will now be transferred to the public wiki, and may be discussed on the dedicated mailing list. Andrea has agreed to do the wiki editing for these contributions. Meanwhile, the BPWG is currently discussing some potential contributions to the core vocabulary. DDWG looks forward to receiving these from BPWG.
[Wiki] Some documents on the wiki will need to be transformed to XMLSpec in advance of formal publication. The technical challenge of achieving this will be investigated by some group members.
[DDR/DPE] The relationship between the DDWG and the OMA DPE group was discussed. Both groups are working on technologies to enable solutions take advantage of device properties. DDWG is working primarily on access to "a priori" information, whereas DPE is working on "real time" information. (This is a loose approximation.) There is an opportunity to avoid unnecessary incompatibilities between the two technologies, and indeed there is already a forming agreement to consider a common ontology. DDWG awaits further information from DPE in this regard. Meanwhile, the scope of work of the two groups does not necessarily ensure a complete solution for contextually adaptive technologies, the respective charters do not make this a requirement, and the use cases for the respective specifications are unbounded (thanks to the imagination of "customers"). The best we might offer is an informal statement of intent: to work seamlessly together. This will be a topic of discussion at the face-to-face.
[Properties] There was a comment recently regarding the specificity of properties. The example cited was "table support" in browsers. From practical experience, it is often not enough merely to assume that support for a particular markup language (that includes tables) is enough to determine that the browser supports tables. There are often limitations and bugs. These are important data for adaptation technologies. How should these data be represented in the DDR? Should there be a new property introduced for each limitation discovered? This topic will also be considered at the face-to-face.
[DI] It was decided that in order to explain how the API would assist content adaptation, it would be good to make reference to the previous publications of the DIWG with respect to "DI Challenges" and "DI Techniques". Furthermore, the DISelect specification (originally from DIWG and now being managed by UWAWG (UbiWeb)) is designed to be extensible, so it was agreed that when the DDR API is complete, some effort should be made to extend DISelect to support the DDR API. This would provide a simple adaptive technology based purely on W3C specifications, that could be used in profiles with other markup languages.
[Requirements] It was recently agreed between editors of Requirements and API that the description of "API Conformance Requirements" should be made part of the API document, and that the existing Requirements document should focus on "Assessment Criteria" for judging the quality (and expected behaviour) of a DDR instance. One of the assessment criteria would have to be that the DDR instance meets the conformance requirements listed in the API document.
Rodrigo Garcia (CTIC)
Rotan Hanrahan (MobileAware)
Martin Jones (Volantis)
Rhys Lewis (Volantis)
Jo Rabin (dotMobi)
Mike Smith (W3C)
Andrea Trasatti (dotMobi)