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

We need also to consider the huge legacy of existing mobile devices, many of which will continue to be in use for many more years. For these devices, it is too late to require that the UA headers are sufficiently identifying. Furthermore, with the best will in the world, it is still not possible to impose compliance for all new Web-enabled devices (beyond just the phones) around the world. There will always be the awkward cases to deal with. Plus, W3C is a world-wide organisation, so our solution should function in all (or at least most) of the situations we may find around the world.
 
Of course, convincing browser creators to include good UA identifiers is a good idea. It would certainly make life easier for the adaptation providers. So keep up the campaign. Meanwhile, the use of exceptions (for cases where evidence is insufficient) is still my preferred option, and it appears to be yours too. I agree that in this case, the right response is to fall back to some default delivery context (DDC), which I understand to represent reasonable assumptions to make when you don't know anything (or enough) about the client.
 
---Rotan.

________________________________

From: public-ddwg-request@w3.org on behalf of Sullivan, Bryan
Sent: Mon 19/11/2007 21:01
To: public-ddwg@w3.org
Subject: RE: ISSUE-23 (ContextKeyList): identify method provides only one key or a list of keys? [DDR API Recommendation]




Rotan,
If we are successful in promoting the requirement that user agent headers must include the host device vendor/model/version (as many mobile operators do, and vendor compliance is very good with some notable exceptions...), then the case in which you can't determine the device is truly an exception case. If you have no other evidence (e.g. coming from OMA DPE, or other approaches e.g. based upon user profile lookup), then you are left with the DDC as your only fallback for device aspects. That may be just enough negative pressure to ensure that browser vendors really don't leave us in the dark.

If you do have this other information, it should have factored into the context key.

So I agree that (1) is the best approach when the device is unknown, and the DDC will have to be your assumption for device aspects.

Best regards,
Bryan Sullivan | AT&T | Service Standards
bryan.sullivan@att.com
-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan
Sent: Monday, November 19, 2007 9:09 AM
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 Monday, 19 November 2007 22:14:45 UTC