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

Meeting summary - 17 Sept 2007

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Thu, 20 Sep 2007 10:40:26 +0100
Message-ID: <D5306DC72D165F488F56A9E43F2045D30141699A@FTO.mobileaware.com>
To: <public-ddwg@w3.org>

[Meeting summary - 17 Sept 2007] Supports vs Claims, Booleans vs

Today's entire teleconference was dedicated to issues 20 and 21 on the
issues list. Issue 20 is about the use of simple Boolean
representations, in contrast to structured representations such as sets.
The usual example is the representation of support for image formats.
Should one have a separate Boolean property for each format
(supportsGIF, supportsJPEG, etc) or should one have a set
(["GIF","JPEG",...]) that then needs to be scanned to see if your
specific format is supported? Meanwhile, issue 21 deals with the meaning
of these Boolean values. Does "Supports XHTML" mean that the entire
XHTML specification is supported 100% by the browser? If so, then
unfortunately (almost) all browsers will have a FALSE value. The
alternative interpretation of the property is that this is what is
*claimed* to be supported, and any deviations from the claim (where
true) will have to be investigated via more refined queries to the

Andrea supplied some background to the WURFL experience in this area:
"In WURFL we found that there were many different interpretations of
tags so members tried to summarise this. XML was chosen to communicate
the information because of widespread support, and we went with very
simple property names, and we went with Boolean values because of ease
of management." Developers demonstrated a preference to work with simple
Booleans, and therefore this is an important consideration for the
design of the DDR API.

Rotan proposed that the same degree of simplicity could be provided via
the API, while still permitting the ontology to represent unbounded
properties as sets/enumerations. In effect, the API can hide the nature
of the ontology for those developers who prefer to keep things simple.
Similarly, in cases where the entire set of values is required, the API
can provide this too.

Assuming the API can provide the desired Boolean values, how should
developers treat these values? In practice, if a value of TRUE indicates
support for a feature, it does not necessarily mean that the support is
complete (e.g. GIF but not animated GIF, XHTML tables but not nested
tables). Furthermore, as Bryan noted, in cases where there are
alternative supported formats, the Boolean values do not indicate which
of the supported formats are preferred. This idea is already present in
HTTP's "q values". It may be possible to answer a question about feature
support by supplying a list ordered according to preference.

As a further refinement of the idea, a Boolean value could be
accompanied by metadata to indicate that more information is available.
For example, support for XHTML may be indicated as TRUE, but a refined
query may reveal that certain XTHML features are not (properly)
supported. This was described as the "yes, but" approach.

Jo pointed out that if we accept the idea of representing properties as
members of enumerations, we should consider the possibility that these
enumerations may be extended independently by different groups. For
example, one group (the DDR Core Vocab team) may decide that "GIF" will
represent support for any GIF format, whereas another group may decide
that "GIF" means single-frame images while "GIFa" means multi-frame
(animated) images. The conflicting semantics of "GIF" means that these
cannot be resolved in the same ontology, unless something like
namespacing is employed.

It was generally agreed that extensibility is desirable, as is
simplicity. Where individual vocabularies decide to create their own
values, it should be easy to do so, subsequently easy to create mappings
between values known to the vocabulary and corresponding values in the
ontology, and finally this extensibility should not negatively impact
other groups who employ the common ontology.

The group decided that this debate was a good candidate for the agenda
of the joint teleconference scheduled for next week.

Matt Womer (W3C)
Martin Jones (Volantis)
Andrea Trasatti (dotMobi)
Jongpil Yi (Samsung)
Rotan Hanrahan (MobileAware)
Jose Manuel Cantera Fonseca (Telefonica)
Anders Ekstrand (Drutt)
Bryan Sullivan (AT&T)
Rafael Casero (SATEC)
Jo Rabin (dotMobi)
Pontus Carlsson (Drutt)
Rodrigo Garcia Acevedo (CTIC)
Received on Thursday, 20 September 2007 09:40:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:14 UTC