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

I'll put the issue on the agenda for Monday.

---Rotan.

-----Original Message-----
From: jmcf@tid.es [mailto:jmcf@tid.es] 
Sent: 23 November 2007 09:55
To: Rotan Hanrahan
Cc: Jo Rabin; public-ddwg@w3.org
Subject: Re: ISSUE-23 (ContextKeyList): identify method provides only one key or a list of keys? [DDR API Recommendation]

So

PROPOSED RESOLUTION: The identifyByHttpHeaders method will only return a 
ContextKey. If there is uncertainty in the key it is up to each DDR 
Implementation how to manage it

Could we resolve on this on Monday's telco?

Best Regards

Rotan Hanrahan escribió:
> I think Jo captures this usage of the context key quite well, and reflects the result of the analysis that was conducted some time ago. I take the point about exception throwing not necessarily being the only mechanism for expressing doubt about the returned value. Perhaps we need to consider this a bit more. Should values include a confidence measure? If one were present, would a developer think to use it? At least with an exception, the developer is forced to deal with it.
>
> ---Rotan
>
> -----Original Message-----
> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Jo Rabin
> Sent: 20 November 2007 09:30
> To: public-ddwg@w3.org
> Subject: RE: ISSUE-23 (ContextKeyList): identify method provides only one key or a list of keys? [DDR API Recommendation]
>
>
> I'm sympathetic to where Jose is coming from on this, but think that at the point we decided to make the context key opaque we made the right decision.
>
> It's then up to the methods provided for querying the Context Key to tell you about doubt, multiplicity and so on - I view the Context Key only as being an implementation specific encapsulation of evidence.
>
> As Rotan says, if the evidence is HTTP headers then there may be considerable doubt about what is actually present, and if you query the context key that doubt should be reflected. How a particular implementation deals with doubt is not up to us to prescribe, imo. What we need to do is provide a range of responses to allow different implementations to do different things.
>
> If you ask "What is the width of this device" and the device is not known, then I am not sure that an exception should be thrown. Returned values should be expressive in some way of doubt. What's the difference between extreme doubt (like, I haven't a clue) and serious doubt (like, most members of this family are around the 300px mark).
>
> Another point in this "context", is that even if the DDR does not know the device, it may nonetheless be able to give you a 100% confidence value for the width, for example if the HTTP headers don't contain sufficient information to determine the device, they may, nonetheless, contain an explicit screen width. Consequently, asking the question leads to a precise answer, even in the absence of knowing what the device is.
>
> So as I say, I think the context key is a single object which can be queried. Whether, internally, the DDR does early binding on device detection - i.e. it looks at the evidence and says "Ahah, that's MSIE on an unknown platform" or whether it does late binding - i.e. it keeps the evidence and resolves it according to the question, is really up to it.
>
> Saying that there is a set of context keys insists that there is early binding, which would make it difficult, imo, for an implementation to late bind.
>
> Jo
>
>
>   
>> -----Original Message-----
>> From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
>> Behalf Of Rotan Hanrahan
>> Sent: 19 November 2007 17:09
>> To: public-ddwg@w3.org
>> Subject: 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 Friday, 23 November 2007 10:03:39 UTC