Re: [W3C] Best practices / charsets / fuzzy 2

eduardo.casais@areppim.com wrote:
[...]
> One difficulty I see is that two aspects are mixed in
> this notion of "user experience":
> 
> 1. Ergonomics [...]
> 2. Feature support [...]
[...]
> Let us consider the terminal capabilities (termcap), as 
> defined by:
> a) the information sent in HTTP accept-*, user-agent and
> related fields (mainly for IE devices);
> b) the information contained in an attached user agent profile,
> when published by the device via x-wap-profile;
> c) additional information from the transcoder operator, 
> representable in a schema compatible with (b), when
> available.
[skipping the precise mechanism]
> 
> As a result, a transcoder will select XHTML mobile
> profile over WML, XHTML 1.2 over 1.1 or 1.0, with 
> tables instead of lines with hard line breaks, a
> page size as close to 60000 instead of too small 10000 
> or too large 512000, 16bit colour pictures instead of 
> b&w (which will neither be 96x48 nor 240x320 if the 
> screen is 176x220), and it will be encoded in KOI8-R 
> instead of UTF-8 if that is what the terminal prefers.


The whole idea is very tempting.

Point c) leaves the door open to the transcoder using whatever value it 
may want to use. It would be good if there was some way for the Content 
Provider to trust the device description data that is being used within 
the transcoder. Appendix D.3 in "Scope for Future Work" envisions this 
possibility:

"D.3 Sources of Device Information
The process of adapting content at the origin server, or transforming it 
in a proxy is likely to have a dependency on a repository of device 
descriptions. An origin server's willingness to allow a transforming 
proxy to transform content may depend on its evaluation of the 
trustworthiness of device description data that is being used. There is 
scope for enhancement of the trust relationship by some means of 
indicating this."

In the meantime, I just wonder whether specifying a precise mechanism 
that cannot be enforced because of c) and because of the fact that the 
whole notion of "user experience" cannot be formally defined carries 
more value than a simple text "It should only [restructure content] to 
match the specific capabilities of the user agent". The precise 
mechanism does look as if we have solved the problem whereas that's not 
truly the case in practice.
Any thoughts on that from others participants of the Task Force?

Side note: out of curiosity, why do you want to use tables instead of 
lines with hard line breaks?


[...]
> A shame that the older version was eliminated, since the 
> text was actually quite good and addressed my concern 
> directly!

OK, I will propose to put some similar text back.


[...]
> A straightforward way is to insert "next page" in russian 
> as numeric character entities and keep everything as 
> iso-8859-1. No analysis of the actual character set 
> and conversions needed. Much faster. Slightly bulkier
> (about 49 bytes instead of 9).

Yes. That's a good point.


[...]
> I am a bit puzzled by the fact that on the one side one 
> acknowledges that transformations may break applications 
> and calls upon transcoder deployers to perform them 
> carefully, and on the other side one refuses to state 
> what are worst or best practices in this respect, or
> even list the potential troublesome consequences of
> doing it.

Coming up with a set of normative worst practices (i.e "do not [foo]") 
that could survive time is not easy.
If people think it's necessary, I personally would not mind having a 
list of potential troubles associated with different types of 
re-structuring operations.


[...]
>> In the meantime, "Cache-Control: no-transform" is indeed the only 
>> reliable method we could find. It may not work for WML 
>> (although do WAP 
>> gateways actually respect this directive in practice?), 
> 
> Well,
> 
> a) Shouldn't the CTG group have investigated the issue 
> and found the final answer to your question already?
> All the more so since representants of an operator that
> has probably tested every WAP gateway for its own needs
> is present in the redaction committee. If you know this 
> is an issue, why leave it hanging?
> 
[...]

We do note that the Cache-Control: no-transform directive is 
incompatible with WAP/WML proxies in the document:
  http://www.w3.org/TR/ct-guidelines/#sec-alteration-of-response

We quickly investigated (although not that much I should add) and indeed 
were told that it will break with some WAP gateways. We did not look 
into this in details because recommending the Cache-Control: 
no-transform directive still holds no matter the results: unless we 
missed something, it's the only existing mechanism we may use.

In the D.5 "Scope for future work" appendix (I know, it does look as 
everything is in scope for future work :(), we also note that more 
fine-grained values would be needed:
  "The BPWG believes that amendments to HTTP are needed to improve the 
inter operability of transforming proxies. For example, HTTP does not 
provide a way to distinguish between prohibition of any kind of 
transformation and the prohibition only of restructuring (and not 
recoding or compression)."


[...]

Thanks,
Francois.

Received on Thursday, 30 October 2008 11:01:22 UTC