RE: ISSUE-23 (ContextKeyList): identify method provides only one key or a list of keys? [DDR API Recommendation]

[Copied internally for tracking purposes]

I still think a single context key is the most appropriate approach. The context key represents the delivery context based on the available evidence. It does not represent individual devices, unless the evidence is sufficient to narrow the delivery context to the point where only one device could have produced the evidence.

So, suppose the evidence (e.g. HTTP headers) identifies a particular browser, but not a particular device model. That's fine. That's as good as I can get at this point. If I want to know what image formats the browser supports (assuming it's not affected by the hardware in which it is running) then I can use this particular context key to query the DDR for this information.

However, if I want to use the same context key to discover the width of the screen, then that's probably not something I can know because there wasn't enough evidence to identify the hardware. (Correct me if I'm wrong, but José seems to suggest that if I ask this question, then what I should get back is a set of all possible values for all devices in which this browser is known to operate.)

Instead, I would prefer one of two approaches:

1. I get an exception to indicate that there is not enough evidence (represented by the key) to be able to give a reliable answer.

2. I get the "most likely" answer.

Somehow the second option is unlikely to work. There may be dozens of devices that could be in this context. Would the DDR need to know the distribution of instances of this device among the population of users? Would it need to know the distribution amongst the customers of the operator? Or perhaps the usage statistics for the application being used? Or the usage patterns for the current time of day? And so on??? While it might be possible to identify the most likely screen to be used on a particular device, it's unlikely to be possible to select from a set of devices. For this reason, I'd go with an exception approach, because the "most likely" approach seems to rely on magic.

So, just as a final reminder. The context key represents the delivery context. Just one context, derived from whatever evidence was provided. How far you are able to query using this context key will likely depend on the quality of the evidence you provided, which we know can be troublesome at times if all you are relying on is the HTTP headers.

---Rotan.



-----Original Message-----
From: [...] On Behalf Of Mobile Web Initiative Device Description Working Group Issue Tracker
Sent: 19 November 2007 16:16
To: member-ddwg@w3.org
Subject: ISSUE-23 (ContextKeyList): identify method provides only one key or a list of keys? [DDR API Recommendation]



ISSUE-23 (ContextKeyList): identify method provides only one key or a list of keys?  [DDR API Recommendation]

http://www.w3.org/2005/MWI/DDWG/Group/track/issues/


Raised by: Jose Manuel Cantera Fonseca
On product: DDR API Recommendation

There could be some cases where the same set of HTTP Headers can be identified as different contexts i.e. more than one device / browser can correspond to that set of headers. So in that case what will be the mechanism used by the API for managing that uncertainty:

a) Return multiple keys to the caller:

ContextKeyList list = identifyByHttpHeadersExt(HttpHeaders headers);

The key list could be ordered from the most likely to the less. 

b) Return a single key to the caller and that key will manage the uncertainty:

ContextKey key = identifyByHttpHeaders(HttpHeaders headers);

The implications from the rest of the DDR-API are the following

In option a) it is impossible that 

DDR.getPropertyValue(Property,Component) return multiple values because each key is representing only "one context"

If we go for option b) one key will be representing potentially multiple contexts and the former method could also return a set

Received on Monday, 19 November 2007 17:09:54 UTC