Re: [AP880] Review LC-2053 and clarify to group

The text "best possible user experience" is in the spotlight anyway, for 
being fluffy and un-testable.

Probably needs to say "exploit the capabilities of the device" or some such.

It's best practice no 2, you know.

http://www.w3.org/TR/mobile-bp/#lcd

Jo

On 13/11/2008 11:40, Rotan Hanrahan wrote:
> I suppose one point is that "the best possible user experience" might be
> possible to achieve without delivering well-formed markup (thanks to
> built-in browser tolerance) but despite this you should really aim to
> produce well-formed markup. This might be important if, for example, the
> end-user has some assistive technology attached to the device of which
> you are not aware.
> 
> Saying that where a target markup type has a requirement to be
> well-formed, the markup generated by the proxy MUST also be well-formed,
> seems like good advice.
> 
> Staying silent on the matter of validation of generated markup would, to
> me, be fair enough given the previous discussion.
> 
> Put simply: the base-line is "well-formed where applicable".
> 
> ---Rotan.
> 
> -----Original Message-----
> From: Jo Rabin [mailto:jrabin@mtld.mobi] 
> Sent: 13 November 2008 11:32
> To: Rotan Hanrahan
> Cc: casays@yahoo.com; public-bpwg-ct@w3.org
> Subject: Re: [AP880] Review LC-2053 and clarify to group
> 
> I don't disagree with this argument, but am not sure what specific 
> change to the text are entailed.
> 
> "Under 4.2.8.1 Alteration of Response
> 
> A proxy should strive for the best possible user experience that the 
> user agent supports. It should only alter the format, layout, dimensions
> 
> etc. to match the specific capabilities of the user agent. For example, 
> when resizing images, they should only be reduced so that they are 
> suitable for the specific user agent, and this should not be done on a 
> generic basis."
> 
> In what respects should this text be altered, and is there anywhere else
> 
> in the document that requires clarification?
> 
> thanks
> Jo
> 
> On 13/11/2008 08:43, Rotan Hanrahan wrote:
>> To be consistent with the work of the DDWG, I would rephrase the
>> conclusions of the two cases to say: "the transcoder must inspect
>> evidence from the HTTP request (mainly the user-agent id of the
>> requesting client) so as to take the appropriate decision not to
>> transform."
>>
>> The point is that the HTTP request header contains a lot of evidence
>> about the delivery context that generally proves useful to adaptation
>> technology. Admittedly the User-Agent field is the most useful
>> determinant amongst this evidence. In the DDWG it was agreed to use
> the
>> general term "Evidence" but to cite a specific example where Evidence
> is
>> constructed from data in the HTTP request header. This terminology is
>> also reflected in the API [1].
>>
>> ---Rotan.
>>
>> [1] http://www.w3.org/TR/DDR-Simple-API/#sec-Evidence
>>
>>
>> -----Original Message-----
>> From: public-bpwg-ct-request@w3.org
>> [mailto:public-bpwg-ct-request@w3.org] On Behalf Of Eduardo Casais
>> Sent: 13 November 2008 08:27
>> To: public-bpwg-ct@w3.org
>> Subject: [AP880] Review LC-2053 and clarify to group
>>
>>
>> The comment LC-2053 is found here:
>>
> http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-200
>> 80801/2053
>>
>>
>> a)    Context
>>
>> LC-2053 assumes the main scenario of the CTG: transcoders adapting
>> desktop-optimized content into a mobile-compatible format.
>>
>> It considers the following situations:
>>
>> 1. Servers that produce desktop-optimized content, with mobile clients
>> that are able to process desktop-optimized content directly.
>>
>> 2. Servers that produce mobile-optimized content and clients that only
>> accept mobile-optimized content, but the format of the content itself
>> (i.e. internal declarations and HTTP MIME type declarations) cannot
>> serve to determine whether it is mobile-compatible, and can even be
>> mistaken for a desktop-optimized one.
>>
>> The intent of LC-2053 is to enforce a basic consistency requirement
> that
>> content not be transcoded when the terminal can handle the original
>> content directly.
>>
>> The difficulty alluded to in LC-2053 is that the mechanisms and
>> heuristics presented in the CTG draft do not deal adequately with the
>> aforementioned cases.
>>
>>
>> b)    Case 1 rationale
>>
>> Contrarily to conventional mobile phones, some classes of wireless
>> devices (PDA, tablets, communicators) have a built-in browser (derived
>> from desktop software) which is able to process desktop-optimized Web
>> content directly.
>>
>> Since the device is wireless, its requests and responses to them may
> be
>> intercepted by a transcoder (usually in the operator's
> infrastructure).
>> When the content accessed is desktop-optimized, it will have
>> corresponding MIME type (e.g. text/html), declarations, DOCTYPE (e.g.
>> for HTML 4.0, 3.2), etc. The server may omit a no-transform directive
> if
>> it wants to allow automatic conversion to mobile-compatible formats
> for
>> other mobile phones.
>>
>> Neither the URI, nor the MIME type, nor the DOCTYPE, nor the
>> content-cache field indicate that a transformation is unsuitable.
>>
>> Conclusion: the transcoder must inspect the user-agent id of the
>> requesting client so as to take the appropriate decision not to
>> transform. 
>>
>>
>> c)    Case 2 rationale
>>
>> There is a whole class of mobile devices that only accept
>> mobile-optimized content, but the content itself cannot be identified
> as
>> such. This affects mainly i-Mode devices, but similar conditions
> prevail
>> in other environments (such as Softbank).
>>
>> i-Mode content is usually presented in a variant of HTML that is
>> advertised as text/html, but does not include a DOCTYPE (as per i-Mode
>> specifications).
>>
>> Because of the long standing of i-Mode, corresponding Web sites do not
>> necessarily follow a pattern imode.* or */imode.
>>
>> Because i-Mode service provisioning is mediated through operator
>> gateways that take care of some automatic adaptations (notably mapping
>> between UTF-8 and Shift_JIS in Japan), origin servers do not
> necessarily
>> include a no-transform directive.
>>
>> Hence, neither the URI, nor the MIME type, nor the (absent) DOCTYPE,
> nor
>> the content-cache field indicate that a transformation is unsuitable
>> (which would convert i-Mode mobile-optimized content to a lower-grade
>> mobile-compatible format without the extra features of i-Mode).
>>
>> Conclusion: the transcoder must inspect the user-agent id of the
>> requesting client so as to take the appropriate decision not to
>> transform. 
>>
>>
>> The conclusions are generalized to ensuring the avoidance of
>> transformations when devices accepting a certain class of content and
>> accessing the same class of content.
>>
>> E.Casais
>>
>>
>>       
>>
>>
>>
>>

Received on Thursday, 13 November 2008 11:48:08 UTC