W3C home > Mailing lists > Public > public-ddwg@w3.org > November 2007

November 2007 Face-to-Face summary

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Sun, 25 Nov 2007 14:34:54 -0000
Message-ID: <D5306DC72D165F488F56A9E43F2045D39C6B47@FTO.mobileaware.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 12:13:51 GMT