[W3C] Best practices / specifications 2

> 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?

We can argue about b) vs c), but a) (HTTP fields
originating from the user agent itself) are probably
the most relevant anyway. In any case, the UAProf 
standard already provides for extending and overriding
attributes from a default terminal profile with 
information provided by network elements.

> 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.

If they are not checkable, then they do not belong
in a normative document.

> 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.

This new proposed title is exclusively centered on proxies, 
and still too general (the guidelines are just for the 
exchange of coordination information among parties, not
about how they process Web content).

What about "Signalling guidelines in a transcoding environment"?
If makes it clear it is about signalling, i.e. setting up the
context for the transcoded Web traffic, and not transformations
per se. Furthermore, it encompasses proxies and other parties
(notably servers). 

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

In that case, I suggest eliminating the chaff, including
the warm, feel-good sentences about taking care of user
experience and other such aspects. It may result in a dry 
document, but one that leaves no ambiguities and that is
testable against claims of conformance.
 
> Although unclear from the minutes I sent you, that's the gist 

Honestly, these minutes are rather difficult to grasp
for somebody who was not present at the meeting. Will
there be a redacted version of the decisions with their
rationale?

> 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?

I had listed DOCTYPES and MIME types that 
conclusively identify mobile content 100% of 
the time: WML, compact-HTML, XHTML-basic and 
the variants thereof for i-Mode, XHTML-mobile
profile, and variations of all these formats
by Openwave. 

You can eliminate application/xhtml+xml as not 
being conclusive (as is text/html of course),
but the other MIME types and DOCTYPES are 
unambiguously for mobile browsers. This makes 
for a pretty accurate and reliable algorithm,
and guarantees a core default behaviour by
transcoders that applications can rely on.

E.Casais

Received on Thursday, 30 October 2008 15:17:06 UTC