Archives for: 2008

Tuesday, June 24th 2008

Permalink 10:37:52, Categories: News

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

Permalink 07:45:34, Categories: News

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

Permalink 16:45:27, Categories: Meeting Summaries

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

Permalink 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.
Rotan Hanrahan

Thursday, February 14th 2008

Permalink 01:06:35, Categories: Meeting Summaries

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é
Rotan Hanrahan

Thursday, February 7th 2008

Permalink 12:20:08, Categories: Meeting Summaries

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
Rotan Hanrahan

Friday, January 25th 2008

Permalink 10:42:47, Categories: Meeting Summaries

Meeting summary – 21 Jan 2008

[Meeting summary – 21 Jan 2008] Scripting as a vocabulary entry, F2F agenda. [Scripting] It has been proposed that the Core Vocabulary should include a property representing information about the client’s support for scripting. It is unclear what is meant by "supports script", since it is known that few if any devices support 100% the official scripting specifications. Therefore a Boolean property would be of little value as it would generally be False. Alternatively, the group has already decided that regarding image support it would be sufficient to record what the manufacturers claim is supported, rather than what has been verified, as the existence of a claim is easier to test. Finally, it was also suggested that one could identify a common code library (such as the recent OpenAjax Hub or some WURFL accessors as used in MyMobileWeb), and test the client to see if it will support these scripts. This would provide a meaningful Boolean interpretation for “supports script”. It was also noted that knowing about scripting support would not be sufficient for even basic Ajax applications, which would need to know about the DOM support and possibly the specific mechanism for asynchronous callback. For detailed Ajax use cases, it was suggested that a domain-specific vocabulary would be needed and that perhaps the OpenAjax community could devise one. Scripts can be considered as an external/embeddable resource, just like stylesheets, images, audio and so on. It was proposed that perhaps the vocabulary should simply have a single property that enumerated all embeddable resource types, rather than have separate properties for each category. This would be more extensible than a categorised approach, and would be better able to handle resource types that might belong to multiple categories or to new/unanticipated categories. Most of the participants who expressed an opinion on this felt that the categorised approach better suited the expectations of developers. It is also possible for the same value to be in more than one category, such as GIF89a which could be a 2D image format and (in some interpretations) a video format. It was suggested that programmable formats (like scripts) should not be considered in the same category as passive data such as images. However, SVG was held up as a counter example, which can be considered as a representation of an image but is also a programmable format. The group discussed the two views (to use categories for properties or just use a single property to enumerate all embeddable formats) in detail, but did not reach a conclusion. This issue will be discussed during the week and at the next call. Regarding the value representing support for script, the importance of types of script and their versions were considered important. The group resolved not to use a Boolean property type. Instead there will be many values and these values will also reveal the type and version, much like is already proposed for image formats (based on MIME types). At this point it seems certain that the Core Vocabulary will mention script support, but the manner in which this (and other embeddable resource types) is represented remains to be decided. [F2F] The date of the Face-to-Face has been confirmed as Thursday 6and Friday 7 of March, in Seoul, Korea. Three topics are proposed for the agenda: the Core API editors’ draft, the final version of the Core Vocabulary and a review of the Structures WG Note. Attendees: Nacho, Jongpil, Pontus, Anders, Matt, José, Rotan, Jo, Bryan
Rotan Hanrahan

Wednesday, January 16th 2008

Permalink 21:30:46, Categories: Meeting Summaries

Meeting Summary - 14 Jan 2008

[Meeting Summary – 14 Jan 2008] Priorities for 2008, Editors’ meeting, Roadmap. [Priorities] The group commenced the meeting by reviewing the outstanding tasks to produce the chartered deliverables by the target date of May 2008. The key deliverables in this time frame are the Core API, the corresponding Conformance Requirements (an appendix to the Core API document), the completion of the Core Vocabulary, some work on the identification of devices and user agents, and (optionally) a Note on an API extension to deal with structures (of device descriptions), and calls for implementations and data contributions. It was proposed that the group aim for a Candidate Recommendation in April, one month ahead of the scheduled end of the group’s charter. This will give time for implementations to be presented. Already there is progress on implementations from a number of group participants, based on work already undertaken, especially the work during the previous face-to-face meetings. There are some outstanding matters to consider in the Core Vocabulary. Some essential properties may yet be included (e.g. “script support” – possibly linked to “ability to support the OpenAjax Hub”) and there needs to be some description of “Aspects”, a concept introduced during the previous face-to-face. It was proposed that Aspects could be incorporated as an annex to the Core API, as perhaps the Core Vocabulary should be. The group requested investigation by the W3C team to determine if the Vocabulary of Device Properties and Vocabulary of Device Aspects could be re-cast as annexes of the Core API. Furthermore, a comparison between Aspects and a similar concept in UAProf was suggested. There will be another face-to-face in March, at which the group expects to have an editors’ draft of the Core API and a final version of the Core Vocabulary for ratification. The recent departure of Rhys Lewis as coordinator of the UWA Ontology was noted, but the group feels that there are sufficient resources to keep this work active. New people are also expected to join and assist. [Editors Meeting] There will be a face-to-face meeting of the editors of the Core API document, in Dublin, Ireland, at the end of January. Editors are requested to attend, and other group members may attend at their own discretion. [AOB#1] It was noted that the Mobile Web 2.0 mobileOK test suite has started with a service launch planned for later this year. With growing attention on the production of good quality Web presentation on mobile devices, one can also expect a growing demand for device descriptions for adaptive solutions. [AOB#2] For the meetings in March, it is anticipated that the DDWG will be allocated the latter part of the week for the face-to-face. [Roadmap] Based on the discussion in this meeting, the roadmap for 2008 looks as follows: - Core API editor’s meeting at the end of January; - Core Vocabulary contributions cease at the end of first week of February; - Core API “Editors’ Draft” ready for the F2F in March; - final version of Core Vocabulary “WG Note” ready by the F2F in March; - Core API “Candidate Recommendation” in April; - calls for implementations and data contributions in May.
Rotan Hanrahan