RE: Comments on Device Description Repository Requirements 1.0

Thank you Tim. I will answer your points using insights from the many
discussions within the group. It is possible that other individual
opinions in the group may differ, so we may see other comments here on
the public list.

a) Non-mention of cacheing.

The group views cache technology as a part of an implementation strategy
that could be used in support of the DDR system requirement identified
as [DDR-SYS-DDR-QUERY-AVAILABILITY]. There are many other
implementation-related issues that will be raised as we discuss how best
to realize the DDR using available technologies. It is exactly these
issues that motivated the group to propose the DDR implementation
workshop [1]. The group intentionally refrained from introducing any
implementation bias when drafting the Requirements. It is our sincere
hope that the workshop will attract people from the Data Access
community, the Semantic Web community, DNS administration people,
database managers, etc., in addition to the usual suspects (device
manufacturers, mobile operators, adaptation specialists...).

Although the Requirements do not mention the use of a cache, it is
obvious to most that a cache will be required. The exact nature of the
cache has yet to be determined, though lessons from existing Web cache
technology (and others) will be valuable.

b) Re-use of existing technology/techniques.

It is not the intention of the group to create a new technology for the
sake of creating something new. Cache technology, as exhibited in the
Web and in the DNS, has been mooted within the group as a viable
approach to providing execution efficiencies within the DDR. The
Requirements also avoided mandating any specific query technology,
though they do indicate that Web Services technologies must be possible,
in recognition of market trends. If SPARQL could provide a good
interface to the DDR, we would expect this to be raised at the workshop.

c) Device vendor supplying device information

The device vendor is not the only source of device information, but in
the use cases where a device vendor plays a role, this role is one of
providing device information. Not all vendors provide such information,
and those that do might not produce reliable information. Furthermore,
the placing of such information on the vendor Web sites (e.g. in the
form of UAProf files) sometimes risks these files "going missing"
because the sites are managed by Marketing.

Recognising this problem, the OMA is gathering validated profiles into a
collection on its own site, though the OMA recognises that validated
profiles are only guaranteed valid in terms of syntax, and that the
reality of the information in those profiles may still require some
additional verification. The collection in the OMA is not a solution in
the sense of the proposed DDR.

The DDR would provide a "place" in which vendors and other interested
parties could contribute information, and where some independent
verification could take place. This is recognised within the
Requirements in the Overview of Use Case 3 where we say: "the scenario
where a Device Vendor (or other appropriate actors such as an
open-source Framework Provider) creates and makes available a new device
description". Thus the DDR is not making a choice to take information
exclusively from device vendors.

I hope this response offers some clarity.

Regards,
---Rotan Hanrahan (chair).

[1] http://www.w3.org/2005/MWI/DDWG/workshop2006/
 

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Tim Berners-Lee
Sent: 04 May 2006 02:20
To: public-ddwg@w3.org
Cc: tag
Subject: Comments on Device Description Repository Requirements 1.0


I have suggested that the TAG and DAWG look at this spec.

Glancing through
http://www.w3.org/TR/2006/WD-DDR-requirements-20060410/
the following things occur to me.

A requirement:

a) 2.11.  Use-case 1. Utilization of device description information from
the DDR

  The requirements don't say anything about cacheing.

    If really every single request for content from a phone goes through
the flow show, the server will be under intolerable load and a complete
bottleneck.  It is clearly necessary for the content provider, or an
intermediate node, to keep a cache of previous requests. This requires
the cache control facilities

and two informal thoughts:

b) An unwritten requirement is that new technology is not invented where
existing technology exists.

(For example, HTTP caching provides the facilities necessary (proxy
architecture, cache read-through, expiry time, etc) and do providing  
the DDR lookup over HTTP clearly allows the client architecture.   
SPARQL may provide a suitable protocol)

c) "The Device Vendor develops, manages (e.g. updates existing device
profiles when devices are upgraded)". That's interesting.  I understood
that in the past, device vendrors have nor always been forthcoming with
such information.  Will the DDR only use vendor data, or possibly third
party data?  Clearly vendor data makes more sense, so long as it is
provided.  Presumably the DDR architecture is not affected by this
choice.

Tim

Received on Thursday, 4 May 2006 08:52:16 UTC