- From: Rafael Casero <rcasero@satec.es>
- Date: Sun, 25 Nov 2007 10:08:43 +0100
- To: public-ddwg@w3.org
- Message-ID: <47493B9B.1000400@satec.es>
+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 >>> >>> >>> >>> >> >> >> >> >> > > >
Received on Monday, 26 November 2007 07:57:15 UTC