Re: [W3C] Best practices / specifications 2

Gents,

I picked up on this thread yesterday having been out of the loop for a 
few days. Looks like a great discussion. As a service to the community 
(sic) would it be possible to summarise points of agreement and 
disagreement, with a view to reviewing on Tuesday's Call?

With reference to some of the recent episodes:

 > trying to achieve and stick to clear, precise, and testable normative
 > statements in the rest of the spec without wishful thinking and other
 > Care Bears references.
yes, I agree on this too, it will make the document shorter as well, 
which is a good thing.

 >  "Signalling guidelines for Web Content Transformation Proxies"
 >
 > I like it. I'm not a native English speaker though, is there anything
 > behind "signalling" that would make it a bad choice? What do others 
think?

We could spend a lot more time discussing the title, but need to be sure 
that the dividend in clarity is worth the expenditure of time. I'd 
prefer not signalling as it's one of those words that is spelled 
differently in different varieties of English. And in any case we go 
beyond signalling in that we discuss how they process Web content, in part.

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

I agree, the general impression is that UAPROF is somewhat unreliable, 
and the accept headers are not precise enough.

Jo


On 31/10/2008 13:11, Francois Daoust wrote:
> 
> Hi Eduardo,
> 
> Ref normative statements:
>> If they are not checkable, then they do not belong
>> in a normative document.
>>
> [...]
> and:
>  >> 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.
> 
> Yes. I think you're right.
> 
> We should make it clear, probably in the Scope section, what we are not 
> trying to achieve and stick to clear, precise, and testable normative 
> statements in the rest of the spec without wishful thinking and other 
> Care Bears references.
> 
> That's the generic direction we've resolved to follow.
> FWIW, previous drafts were informative only, we've switched to "real" 
> normative statements shortly before the publication, which may explain 
> why we're still between waters on that front.
> 
> 
> About the title:
>>> FWIW, the title will be changed to: "Guidelines for Web Content 
>>> Transformation Proxies" [...]
>>
>> 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).
> 
> Note that it's meant to be focused on proxies.
> We will actually replace the normative part on Content Providers with an 
> informative part (probably as an appendix). It was decided in response 
> to a comment received complaining that Content Providers should not have 
> to be forced to do something (i.e. through the use of MUST). We agreed 
> that the normative statements should be followed by the content 
> transformation proxy. The rest are informative guidelines for Content 
> Providers.
> 
> [...]
>>
>> What about "Signalling guidelines in a transcoding environment"?
> 
> See above, we now focus intentionally on Content Transformation proxies 
> and not mentioning Web makes it look as we're talking about 
> transformation in any context (e.g., XSLT). Your proposal could be 
> amended to:
> 
>  "Signalling guidelines for Web Content Transformation Proxies"
> 
> I like it. I'm not a native English speaker though, is there anything 
> behind "signalling" that would make it a bad choice? What do others think?
> 
> 
> [...]
>>> 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?
> 
> OK. The minutes are taken by the participants of the meetings, not 
> always accurate and not always clear.
> 
> There are no redacted version of the decisions, I'm afraid.
> Minutes are immensely useful for us, but I will try not to forget that 
> pointing someone to the minutes of a call he hasn't participated in is 
> definitely not a good idea.
> 
> [...]
> 
> Francois.
>

Received on Friday, 31 October 2008 15:08:59 UTC