- From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
- Date: Sun, 25 Nov 2007 14:34:54 -0000
- To: <public-ddwg@w3.org>
Spanning three days, the DDWG face-to-face meeting took place during the second week of November in Boston as part of a series of events organised by the W3C. The meeting incorporated a joint meeting with UWA, so that at one point 26 people were present. The three days were very productive. A general summary appears below, substantially in the order in which they were addressed. The first order of business was to address the recent work on the design of the DDR API, being conducted through the medium of the Java programming language because of familiarity and abundant tool support. It was agreed that the evolving prototype code should be managed by the W3C CVS server. The functions from the draft API had been translated to Java interfaces, with some of the methods given concrete implementations (to provide an interface for WURFL). Some refactoring of the interface and method names was conducted in order to carefully align the names with their semantics. This refactoring was a recurring activity during the three days. The group discussed the intended use of IDL as an implementation-neutral means of specifying the DDR API. It was noted that IDL had a number of limitations that restricted its ability to use certain current language approaches. It was noted that IDL continues to be used in other W3C specifications, but that this does not necessarily mean it is appropriate for the DDR API. Object instantiation became a design issue, especially as IDL does not fully support the range of possibilities in languages like Java. Three approaches were suggested: 1) enhance IDL in a custom fashion to support additional language constructs, 2) use factory classes to instantiate all objects, 3) use constructors without parameters and provide setter methods for all. The group decided not to use the first approach because of the absence of tool support for any extensions to IDL. It was noted and resolved that the factory approach should be the basic class model, thus ensuring that each object had only one instantiation, and that this could improve efficiency. For cases where multiple instantiations were required, a clone method could be provided, plus appropriate setter methods. Property names would play an important role in the API. It was resolved that these names would have a default namespace of "none", thus requiring that whenever a property name is used, the API must explicitly determine the actual namespace. Once the API determines an actual default namespace, this is immutable. Property names in vocabularies of the DDR are expected to make reference to the ontology being created by the W3C UWA. In a joint meeting with UWA members, the use of the ontology was discussed in detail. Three significant providers of delivery context information were presented: 1) the W3C DDR provides a priori (static) information via a repository API at the server, 2) the W3C DCCI provides current delivery context information via a DOM2 interface at the client and 3) the OMA DPE provides current delivery context information at the platform level from the client to the server. There is a role for all three technologies, and it is important that for reasons of interoperability they use the same ontology. There is no requirement that the architectures of the respective technologies are the same, or need to take each other into consideration. Only the APIs of the respective technologies are significant. Because of the central role of the ontology, there will be a need for careful management of its evolution. Any introduction of new elements for the ontology that are deemed to be "core" will need to be controlled. Custom solutions can opt to use an independent ontology for concepts not already in the common ontology. Everything in the ontology is uniquely identified (i.e. a flat namespace) although there are additional hierarchical relationships. Some reasons for the failure of UAProf were also mentioned, with everyone expressing hope that the introduction of DDR, DCCI and DPE would finally solve the problem of access to the deliver context. There was a discussion of the use of brand, model and version properties. Initially it was suggested that these properties could be managed separately from the information about a particular device, but subsequently it was agreed that these properties could be applied to many aspects of the delivery context (e.g. the browser, the hardware, the embedded camera etc.). Following the meeting with UWA, the work returned to focus on the API methods for retrieving data from the repository. The group considered the use of objects as parameters, versus the use of strings. The former provides more control, but the latter would be easier to use for most developers to use. It was furthermore resolved that the data returned by a query should be an object, typically one that (where necessary) can provide additional information such as the numeric value, the units, whether the result is a default or a measured value and so on. With a view to ensuring that the API could be easily adopted, it was resolved that the API would support methods that took property parameters as strings. In particular, this approach would be used for "convenience" methods. (The group light-heartedly referred to such methods as the "fast food version".) It was decided that the main factory methods should belong to a single class, with a possibility for objects so created to be capable of being factories. Initially, it was thought that the bootstrap sequence would involve a service object that would create the DDR object, establish the default namespace and be responsible for the recognition process. This was further refined to permit independent instantiation of the recognition process (accessible through an object) because it should be possible for independent parties to create the repository and the recognition process. The recognition process is responsible for creating the context key from whatever evidence is supplied to it (e.g. HTTP headers). It will be up to those responsible for deploying the solution to ensure that the context key created by the recognition process is compatible with the implementation of the repository. The API specification will merely indicate that the context key is an opaque object. In the vocabulary, it is possible that properties may apply to more than one part of the delivery context. For example, the width in pixels could apply to the main screen, or to a secondary screen. It might also apply to other aspects of the device, such as the camera. For this reason, it was decided that the response to a query about a property could return a multiple of property values, covering one or more components in one or more aspects. As an example, a query for width could return an unordered set of three property values, obtained from two screen components and one camera component. If one wishes to obtain a property value for a particular component (in any aspect) then the query needs to be applied to an object representing the component. For this reason the group agreed on a class to represent components. Furthermore, to identify individual aspects it was decided that an additional vocabulary of aspects would be required. A convenience method would also be provided that, given a particular property, would narrow the options down to a default component and return the value for that component. The component that is selected would represent the "most likely" component, chosen according to an implementation-dependent strategy. For example, if requesting the "width" in a particular context, it would be reasonable to assume this refers to the display aspect and that it is the main display component that is to be examined. Additional methods to determine the default component were also deemed necessary. Through this discussion, the signatures of a number of query methods were eventually agreed, and these will be made available in Java form in public in due course. There was further discussion on the use of constants and strings as parameters to the query methods. A number of alternatives were considered. One suggestion was that all constants would actually be defined in the API, but while this would be good practice for a particular implementation, in general the use of string parameters was considered the most convenient. The focus then turned to whether one could parse the string, and thus include a namespace in the string. However, it was felt that the use of a property object to identify the property being queried would be sufficient, as the construction of such a property object would require a namespace. In the case of the convenience methods, implementations are free to select the namespace internally. There was more discussion on the separate matter of device structures (i.e. the ability to define collections of devices based on some expression that represents membership criteria). Several use cases were considered, details of which have already been presented via the DDWG wiki. The text of these use cases will be revised. One particular use of structures was noted: they can provide the means of disambiguation when communicating between different parts of a business organisation. For example, the marketing department can request from the IT department that PDAs have a particular style, and by using a formal structure it is possible to unambiguously define what is meant by "PDA", and furthermore this is a machine readable definition that can be used directly in the content adaptation solution. It was suggested that the use of the XPath expression syntax would be useful, and would also afford the possibility of combining the DDR structures mechanism with the DISelect technology of the UWA group. The group also spent some time drafting the introductory text for the DDR Core Vocabulary document, which was subsequently made available to the document editor, with the intention of a first draft being published as soon as possible. Some minor inconsistencies in the property names were also noted, and will be resolved in future publications. The three days of meetings concluded with a statement of intent to make progress over the following weeks, particularly with respect to the API, with the intent to publish material ahead of the December deadline. Rotan Hanrahan, group chair.
Received on Sunday, 25 November 2007 14:35:16 UTC