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

+1 to support resolution (I will not be able to participate in Monday's
call)


Raf.Casero

-------- Mensaje Original --------
>
> 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
>>>
>>>
>>>
>>>     
>>
>>
>>
>>
>>   
>
>
>