RE: Comments on Device Description Repository Requirements 1.0

Rotan,

Thanks for the quick response.

Regarding your 2nd comment, I'm still failing to understand how will this
work with the best effort approach. If device A identifies itself as A,
which doesn't exist on the repository, there should be a general guideline
on what best effort query will return, don't you agree?

Whatever this method is, and I'm sure there will be a lot of discussion on
it - I'm guessing that in today's open market most queries would be of this
type (best effort) - and the response must at least be understood by the
clients of the DDR.

Lior

-----Original Message-----
From: Rotan Hanrahan [mailto:Rotan.Hanrahan@MobileAware.com] 
Sent: Thursday, May 04, 2006 3:52 PM
To: Lior Sion; public-ddwg@w3.org
Subject: RE: Comments on Device Description Repository Requirements 1.0

There are two Requirements identified in the document:

[DDR-QRY-EXACT] It SHOULD be possible for an Actor to query the DDR
specifying an exact match required in response to the query

[DDR-QRY-BEST-EFFORT] It SHOULD be possible for an Actor to query the DDR
specifying a best-effort match required in response to the query.

In the case of an exact match query, a failure to match would be reported as
a "miss", as you call it. In the case of a best-effort match query, the
response would be the nearest matching device. There are a number of
implementation possibilities regarding the representation of approximation.
The specific interpretation of "closest" would be something we would
consider in the implementation workshop. If more than one interpretation is
necessary, a means for the Actor to indicate the required interpretation
would be necessary. I do not wish to go into the specifics of
implementations at this point. Instead I wish just to confirm that the issue
you have mentioned is one that the group is aware of, and wishes to consider
as part of future implementation strategies.

Regarding the device/browser distinction, we acknowledge that information
about both may be necessary to achieve proper content adaptation. We would
only expect a device to be identified if the client
(browser) specfically indicates the device in which it is executing, or if
the delivery environment has some alternative means of detecting the
hardware during the interaction between client and server. The specifics of
the recognition process are out of scope for the DDR, which merely assumes
that a means of uniquely identifying the client/device exists, and that the
representation of the unique identity can be conveyed to the DDR in queries.

Regards,
---Rotan.
________________________________

From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Lior Sion
Sent: 04 May 2006 13:38
To: public-ddwg@w3.org
Subject: Comments on Device Description Repository Requirements 1.0




Hi, 

I have a questions about v1.0 of the req: 

(a) 2.1.1, especially flow 2.1.7: what is the expected result of a "miss" on
the repository? Would the answer be "device not found" or will the
repository look for the closest know device? Will it mark the answer as
"closest"? How will this closest be found? 

I think that in today's market, and also in the foreseen future, this is one
of the main issues. Device identification changes, sometimes slightly -
different devices come with identical browsers - what would count as a
"hit"? The correct browsers version or the device version? 

Thanks, 

Lior Sion 



************************************************************************
************
This footnote confirms that this email message has been scanned by PineApp
Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************
************



 
 
****************************************************************************
********
This footnote confirms that this email message has been scanned by PineApp
Mail-SeCure for the presence of malicious code, vandals & computer viruses.
****************************************************************************
********


 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************


 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************