Re: [W3C] Best practices / specifications

eduardo.casais@areppim.com wrote:
[...]
>> 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. 
> 
> It is a matter of defining a hierarchy: a) > b) > c) when
> it comes to the relevance of attributes. Nothing difficult. 

That's where I disagree. The need for device description repositories
also came from the fact that the other sources of information were not
reliable enough.
So c) > b) > a) would be my choice. But then, that depends on c). And
that also depends on who you are. Mobile operators who produce UAProf
descriptions will say that b) is more accurate. Who decides?


[...]
> The scope for future work does not specify how capability 
> negotiation takes place, but defines another mechanism for 
> parties to exchange information about the confidence they
> have in each other's device information. Not quite the same
> thing: maybe a party has better information about a device,
> but what counts is whether the transformation will be better
> -- and that is apparently not the topic for future work.

POWDER is pointed out as a potential idea for content providers to
express transformation preferences.
We should probably reference CC/PP for the client side, I agree.


[...]
> A specific mechanism, such as I proposed, is defined, based
> on standards, measurable, and testable. It does not encompass
> the entire user experience -- and does not attempt to, hence
> is a partial solution. However, it enforces some very basic
> consistency and optimization requirements.

I agree. I'm not as confident on the "measurable" and "testable" parts,
and still fear it would look as if it attempts to encompass everything,
which is why I prefer the suggestion you make below...


[...]
> If you do not want to or are not able to specify what 
> is meant by "best possible user experience" or "careful
> transformation", then I propose you simply eliminate
> all references to such recommendations.

I don't think we should stay totally silent either. But the use of 
normative
statements that can't be checked may not be appropriate.


> After all,
> the CTG is, contrarily to its title, not about
> best (or worst) transformation practices

FWIW, the title will be changed to: "Guidelines for Web Content 
Transformation Proxies" which does not fix the misunderstanding, but all 
the alternatives we could think of looked more like long abstract 
sentences than potential titles.


[...]
> but about _signalling mechanisms_ between 
> parties in a transcoding environment. In the same
> way that I do not remember seeing recommendations
> for "appropriate applications" in the HTTP standard, 
> maybe the CTG should just refrain from inserting
> any text on the quality of transcoding or lack
> thereof. In short, reduce the text to what is the
> W3C goal, more or less summarized as follows:
> 
> a) This is how transcoders signal their presence
> to servers and clients.
> b) This is how clients can react to the activity
> of transcoders.
> c) This is how servers indicate to transcoders
> what they may/may not do.

Yes, that's exactly what we're trying to achieve, and what we're trying 
to restrict us to do.


> d) We do not define what transformations are,
> which ones are good, which ones are bad; we do
> not recommend any way to perform specific
> transformations. We do not endorse any kind of
> transformations. A non-exhaustive, provisional
> list of issues that are raised by transcoding 
> operations can be found in the appendix."

Although unclear from the minutes I sent you, that's the gist of the
resolution we took along with the resolution on character encoding:
"Mention the out of scope nature of the details of restructuring under
4.3.6 somewhere (cf insertion of headers, footers etc.)"


[...]
> I have had the dismal experience to see transcoders
> transform tables (not for formatting, just to present
> figures), and which could be perfectly rendered as 
> such on end-user devices, into lines with hard breaks...
> 
> This would correspond to a capability negotiation
> / optimization for the attribute "TablesCapable".

Understood. Thanks.


>> 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.
> 
> So what about that Vary field?

I meant to say the only real "switch", where by switch I mean something 
that carries the expectation of the server.
We do recommend the use of Vary, and the use of the Link element in HTML 
content.
None of them work in all cases.


> And no, it is not the only mechanism. That is why there
> are heuristics, and why it is important to specify them
> in detail -- especially since they are based on standards
> (MIME types, XML declarations, HTTP field Content-type,
> domain names).

[...]
> And you rejoin what I stated: you cannot really achieve
> a consistent framework without a special-purpose (though
> hopefully tight) protocol. As long as it does not exist,
> it is necessary to make the most out of existing mechanisms
> -- and that also means taking care of the difficult cases
> (WML, lcd sites) with heuristics.

I agree that we are fairly limited by the use of existing mechanisms.
If we specify heuristics with SHOULD and MUST though, we would convert 
heuristics into precise algorithms.
If it looks 80% mobile, is it mobile?
If it looks 80% mobile today, will it look 80% mobile tomorrow?
If it looks 80% mobile, is it mobile for low-end devices?

Francois.

Received on Thursday, 30 October 2008 14:02:08 UTC