Archives for: October 2007

Wednesday, October 24th 2007

Permalink 22:09:47, Categories: Meeting Summaries

Meeting Summary - 22 Oct 2007

[Meeting summary - 22 October 2007] End of properties, Korea agreed, Boston scheduling, Publications. [Properties] The wiki now reflects the state of the group regarding decisions about properties that are to be part of the Core Vocabulary. It was decided that next Monday would be the end of this round of deliberations on the vocabulary, with all future discussions to take place from January. This will give space to the group to concentrate on the API. One of the issues not yet resolved is the significance of device "brand" and "model". As the association of hardware/software to brand/model is not one-to-one, is unpredictable and is not generally not essential for real time adaptation, it's value as a core property is questionable. However, for non-realtime authoring phase use, the brand/model is very useful. It was suggested that perhaps the group's work on structures could provide a mechanism for associating brand/model information with entries in a repository. This remains an open issue. [Korea] Following a group vote, a decision was reached to accept the invitation to hold a face-to-face meeting in Korea next March. [Boston] An ongoing poll reveals that there will be several active DDWG participants at the Boston face-to-face in November, but (not surprisingly) several are also engaged in work with other W3C groups during that week. The group chairs will coordinate their respective agenda to make optimal use of member availability. [Publications] The two legacy documents are on track for publication. A draft of the Core Vocabulary document will be attempted during the F2F. With the discussions on the vocabulary being parked from next Monday, there should be an opportunity now to concentrate on the API document. Meanwhile the group also hopes to close the discussion on the outstanding high-level Requirements document during the F2F. [DOM bindings] A recent (Oct 17) draft document from the CSS Working Group includes several items of interest regarding the use of IDL for specifications involving DOMs. Some of this information can inform the DDWG's work on drafting an API for the DDR. An issue has been raised to ensure that members of the group become familiar with the document. [Admin] The group's internal tracker now has the means to flag items for review. There has also been some progress on the merger of the group wiki to a new platform. Attendees: Anders, Andrea, Bryan, Dimitar, Jo, Matt, Martin, Mike, Rafa, Rotan.
Rotan Hanrahan

Thursday, October 18th 2007

Permalink 15:54:45, Categories: Meeting Summaries

Meeting Summary - 15 October 2007

[Meeting Summary - 15 Oct 2007] Vocabulary resolutions, Korea F2F. [Vocab] This week’s conference call was energetic and productive. The main topic on the agenda was to make decisions on the many proposed core vocabulary properties, taking into account the many responses and other comments received to date. Over the past week, the group had been voting to identify those properties that were core, not core and deserving of further debate. It was assumed that those who had engaged in the voting had strong opinions to express. The first property discussed related to H.264 (Baseline Profile Level 1.0). This deals with streaming video rates. It was felt that this property was outside of the scope of a core vocabulary that was focussed only on the essential properties for adapting Web content for mobile delivery contexts. The group intends to respond to the proposal by indicating how domain specific, custom and advanced vocabularies can be created; and the role of the UWA ontology in this regard. It was resolved that H.264 is not part of the core vocabulary. The next property was the DOM Level of the browser. It was felt that the DOM Level did not have a strong bearing on the adaptation of content. Knowing the DOM Level might be useful in adapting scripts that access the DOM. In the same vein, the group considered the XMLHTTPRequest support of the browser, and again this was felt to be a script-oriented property. Both of these properties would be considered core to an adaptation process for mobile Ajax, but not for a simple adaptation process that is dealing with simple Web content. It was decided that these properties would be communicated to the OpenAjax Alliance, with a view to encouraging them to create a vocabulary for adaptation of Ajax, following the example of DDWG. Support for ECMAScript (or JavaScript) was also discussed. It was felt that knowing that a browser supports scripting is beneficial for more than just Ajax applications. It was therefore resolved that this property should be in the core vocabulary, but there would still need to be further discussion on whether it should represent ECMAScript and/or JavaScript. The proposed property of Characters Per Line was debated. It was suggested that this property would be useful for pagination. However, it was also seen as a throwback to the old days of WML content, where fonts were very simple and the character density was an important property. Today, with variable fonts and more complex layouts, character density is less precise. In the absence of exact font information, and approximation based on screen resolution would probably suffice. To do things like sophisticated line wrapping, you would need much more detailed information about the fonts, which the group agreed would go far beyond a simple adaptation. For simple adaptation, the screen width would be a sufficient means to approximate the character density and thus the Characters Per Line property was resolved to be non-core. It was pointed out that no matter what the DDWG decides will be in the core, there will be people who will say some properties are missing. The best that the group can achieve is a basic vocabulary that will support simple content adaptation, and be sufficient to demonstrate the operation of the DDR API. This needs to be explained in the Vocabulary document. The group then turned its focus on some properties that all agreed were core: the dimensions of the screen. The width and height were seen by everyone as essential for content adaptation. While previous proposed properties were rejected from the core, these two properties were immediately resolved to be core properties. With this practice on the decision process, the group agreed to take the discussion to the electronic forum, where the remaining candidate properties would be debated, and some further resolutions taken. This debate, and the conclusions, would be visible on the public mailing list and the wiki. [Korea] Finally the group acknowledged an invitation to hold a face-to-face meeting in Korea in 2008. The group will send a formal response after polling the members. Attendees: Matt, Andrea, Pontus, José, Jo, Rotan, Martin, Dimitar, Kevin, Jongpil, Bryan, Nacho
Rotan Hanrahan

Thursday, October 11th 2007

Permalink 11:26:46, Categories: Meeting Summaries

Meeting Summary - 8 October 2007

[Meeting summary – 8 Oct 2007] Vocabulary contributions, Screen orientation, Publications, Documents status. After a pause in the teleconference schedule, DDWG resumes its regular weekly meetings. [Contributions] Many new vocabulary properties were proposed from the MyMobileWeb project. Some of the project’s properties come from WURFL and some are specific to the project. A number of the properties were considered to be core to the MyMobileWeb project and have been submitted for consideration in the DDR Core Vocabulary. Some of the submitted properties deal with simple features, while others deal with bugs and limitations. The UWA ontology can represent these properties. It is expected that any of the recent submissions that are not eventually made part of the DDR Core Vocabulary will still be represented in the UWA ontology. One submitted property was Preferred Image Format. It was pointed out that the preferred format might also depend on what was in the image itself (a face, or a diagram, or text) and not just on the rendering ability of the device. This is an example where the application context can also influence adaptation. In general, accessing the delivery context is more than just accessing the static properties that would be stored in a DDR. A generic delivery context API is outside the scope for the DDWG, but is likely to feature in any particular adaptation implementations. In some contexts, the value of certain properties can be known a priori, and therefore can be recorded in a repository. Some properties vary from context to context, but remain static in any particular context. Some properties cannot be known in advance, but may have a default value that can be overridden when the actual value is discovered. Access to all these properties cannot be satisfied by the DDW API, whose scope is for those properties whose value can be known in advance. [Screen orientation] On a related topic, the OMA has asked for feedback on developments regarding the access to screen orientation information. This is a property that for some contexts is static, while for other contexts it is dynamic. The DDWG will provide some feedback to the OMA on this matter, particularly on how the orientation information is handled in dynamic contexts. [Publications] The group has resolved to publish the final versions of the Landscape and Ecosystem documents, with congratulations to the editors (past and present) and contributors. Publication is expected before the end of the month. [Vocabulary document] The wiki pages of the vocabulary have been updated to include all (except today’s) recent submissions. The group must now evaluate and decide upon the properties, which are considered to be core, and which are not. All will be forwarded to the UWA for consideration in the ontology. The names of the properties have not yet been decided. An attempt will be made to ensure that there is some agreement on naming between the vocabulary and the ontology, but such agreement is not essential. Where there is the possibility of confusion, or where unnecessary complexity can be avoided, appropriate alternative names may be used. For example, the issue of “supported features” has been discussed recently and the group decided that it makes more sense to record “features that are claimed to be supported” rather than “features that are fully 100% verified to be supported”, given that the latter would probably be empty in many real-world cases. However, for the DDR Core Vocabulary it may make more sense to use the name “supports”, while mapping it to the ontology definition for “claims support for”. The group will commence its deliberations on the recent vocabulary submissions immediately. [API document] There was an editors call about two weeks ago, but no substantial progress since then. The editors are committed to making progress as much as possible, and will aim to have publishable material this month. Present: José, Rotan, Matt, Martin, Anders, Bryan, Jo, Pontus, Andrea, Rodrigo, Jongpil, Nacho
Rotan Hanrahan

Tuesday, October 2nd 2007

Permalink 02:40:08, Categories: Meeting Summaries

Summary of Joint Call (DDWG+UWA) - 24 September 2007

[DDWG and UWAWG Joint Meeting Summary – 24 September 2007] The DDWG and UWAWG held a one hour joint call to discuss matters of mutual concern. In particular, issues relating to the UWA ontology and its relationship to the planned DDR Core Vocabulary were discussed. What follows is representative of that discussion. The DDWG plans not only to create a vocabulary of device properties, whose semantics will be captured in the UWA ontology, but also to create an API with which the value of such properties can be obtained. Developers are generally expected to require simple data types and uncomplicated methods. When retrieving information from the repository, simple Boolean results will suffice. Questions like “Does the current device support GIF images?” will be asked. It is possible that such questions may be followed by more in-depth questions, such as “Does the device’s support for GIF include Animated GIF?” [Note: for much of the discussion, the participants used "supported image formats" as a key example, while acknowledging that the issues go much further than images.] It may seem from the point of view of the API that these properties are all Boolean in nature, that the data to answer such questions is stored as Booleans and that the ontology represents concepts such as “support for an image format” as Booleans. However, this is not the case. From the point of view of the ontology, support for one or more image formats is best represented as an enumeration, whose permitted members may extend as new image formats (or sub-formats or classifications) are identified. With this approach, the ontology does not need to be rewritten to accommodate new image formats. New image formats may occur because a vocabulary may be revised to encompass more than its predecessor. New image formats can also occur as a result of advances in image technology, which prompts the revision of the vocabulary. The way in which the vocabulary and the ontology represent properties (such as supported image formats) does not determine how the corresponding data is stored in a repository. Only the mapping between the concepts represented in the ontology and the values represented in the vocabulary are important. It was agreed that this mapping should form part of the vocabulary definition. There may also be metadata associated with vocabulary items. Once again using supported image formats as an example, a device may support several image formats but in certain contexts it is preferable to use one format over another. Such preferences may be represented in many ways. The example of HTTP “q values” was mentioned. An ordered list is another possibility. If this metadata is represented in the ontology in a particular manner, it is possible that the API will represent the same information in a different manner. It is a role of the vocabulary definition to ensure that there is a mapping between the two. This assumes, of course, that the API designers choose to expose such metadata via the API. While it is possible, and likely, that DDR API will have a simplified view of the data described in the UWA ontology, there is no requirement that the DDR API can also provide a view that is directly mapped to the ontology. For example, if the API may represent “support for feature X” as a Boolean method while the ontology uses enumerations for the same data, then it is not necessary that the API also provide the means to access this data as an enumeration. Nevertheless, there are use cases where accessing the data in the manner represented by the ontology is preferable. The DDR API is intended to support the adaptation of Web content, but this may happen at run time and/or at design time. Boolean methods are likely to be preferable for run time use, but there are design time questions that will require enumerations. For example: “What image formats are supported by this (category of) device?” It will up to the DDWG to determine how complete such methods will be in the core API. It is unlikely that the DDWG will attempt to create an API of extreme complexity and sophistication with respect to accessing ontologies. Other groups and existing technologies are better placed to provide these solutions. Assuming enumerations of values will be found in the ontology, the source of the permitted members of such enumerations must be determined. Using the familiar image formats example, it was pointed out that the DDWG may decide that “GIF” is a sufficient value to represent support for all variants of the GIF format. However, another group that is also contributing to the UWA ontology may, for its own reasons, decide that it needs “GIF” and “GIFa” to distinguish the static and animated variants. This would introduce a conflict in the semantics of “GIF”, and the ontology cannot permit such conflicts. The participants discussed ways to resolve this. The most obvious solution is that the ontology does not capture specific values, and instead relies on these being defined externally. It is only necessary that the ontology know the “type” associated with these values, and that an implementation can uniquely and unambiguously reference these typed values. URIs were designed for such a purpose. Thus the ontology could represent supported image formats for a device as an enumeration of URIs where each URI identifies a typed value. The issue of the definition of “GIF” is therefore resolved, because the two groups would use different URIs for “GIF”. The DDWG could define a namespace for the properties in the core vocabulary, and apply this namespace to “GIF” to distinguish it from a similarly named “GIF” belonging to a different vocabulary in a different namespace. While this sounds like a reasonable resolution to the problem, the participants were cautioned not to devise a solution that that could lead to the creation of many namespaces. Sticking to one is preferred, such as a common namespace for MIME types. The DDWG expects that the vocabulary will reference the ontology for the semantics of the data held in the repository. However, it is expected that both the vocabulary and the ontology will evolve over time. Different versions of each will be released as new requirements are addressed. This leads to an issue of versioning. There was a short discussion on the manner in which a particular version of the vocabulary would reference a particular version of the ontology, but it was inconclusive. To make the work more concrete, the participants were asked to consider some examples of how the DDR API would deal with the Boolean method of determining support for a feature. It is assumed that a Delivery Context Key has already been obtained as a result of device recognition. Here are the three method formats that were suggested to answer the query: “Does the current device support GIF?” supportsGIF(thisDC) supports(thisDC, “cv:claimsGIFSupport”) supports(thisDC, “cv:claimsImageFormatSupport”, “cvif:GIF”) The three proposals were discussed briefly. The first was considered to be inflexible, because new image formats would require new method names to be created, and therefore a new API to be drafted. The second is more extensible, but the third is even more extensible. In order to learn in a practical way if the third format is appropriate for the DDR API, the DDWG members present resolved to incorporate this into the next published draft of the API. Feedback will help refine this approach and make progress. The hour allocated to the meeting rapidly expired and the participants closed the meeting at this point. The next opportunity for a joint meeting will be in November. Attendees: Andrea, Bryan, Jo, Jose, Kevin, Martin, Matt, Mike, Rhys, Rotan, Steph, Rafa, Dave
Rotan Hanrahan