W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > October 2008

Re: [W3C] Best practices / specifications 2

From: Francois Daoust <fd@w3.org>
Date: Fri, 31 Oct 2008 14:11:59 +0100
Message-ID: <490B041F.4080109@w3.org>
To: eduardo.casais@areppim.com
CC: public-bpwg-ct@w3.org, Tom.Hume@futureplatforms.com

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 13:12:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 31 October 2008 13:12:36 GMT