- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 17 Feb 2014 08:51:12 -0600
- To: "Charles McCathie Nevile" <chaals@yandex-team.ru>
- Cc: "Stephen Zilles" <szilles@adobe.com>, "public-w3process@w3.org" <public-w3process@w3.org>
On Feb 17, 2014, at 5:04 AM, "Charles McCathie Nevile" <chaals@yandex-team.ru> wrote: > On Sat, 15 Feb 2014 01:25:40 +0100, Ian Jacobs <ij@w3.org> wrote: > >> On Feb 14, 2014, at 6:16 PM, Stephen Zilles <szilles@adobe.com> wrote: > >>> My reading of 7.2.4 is a requirement not "feasibility". >> >> I continue to believe the limit of our endeavor is enabling, not producing actual implementations. > > While we don't produce them in the sense of actually making them, if all you want to do is allow for the potential that they can be made you could stop work now and have that. Which would be cheaper. But less useful to the world. > > If specs aren't good enough that people who pick them up in Brasil, Russia, China or Senegal, with a reasonable idea of technology and an admittedly shaky grasp of english, can implement something that interoperates, then the Web is going to be the sad product of misunderstanding rather than reach its full potential… You just wrote in your previous paragraph "can implement something" which is the same "can" I have in mind. This is not a critical issue, so I'll let it go. Ian > > cheers > >> Ian >> >>> >>> Fir 7.4.1 I had suggested a different set of changes in an earlier message; e.g., use "Revising a CR" rather than "Revised CR" to avoid the apparent creation of a new state. >>> Steve Z >>> >>> Sent from my Motorola ATRIX™ 4G on AT&T >>> >>> >>> -----Original message----- >>> From: Ian Jacobs <ij@w3.org> >>> To: Charles McCathie Nevile <chaals@yandex-team.ru> >>> Cc: "public-w3process@w3.org" <public-w3process@w3.org> >>> Sent: Fri, Feb 14, 2014 21:27:20 GMT+00:00 >>> Subject: Re: Ian Jacobs comments [Was: New draft - please review] >>> >>> >>> On Feb 14, 2014, at 3:00 PM, "Charles McCathie Nevile" <chaals@yandex-team.ru> wrote: >>> >>> > With one exception, I have addressed all these comments (and the exception I expect to address later tonight). >>> >>> Thanks, Charles. Notes inline. >>> >>> Ian >>> >>> > >>> >> - 7.1: "Individual Working Groups and Interest Groups may adopt >>> >> additional processes for developing publications, so long as they do >>> >> not conflict with the requirements in this chapter." >>> >> >>> >> Proposed editorial change: "Different Working Groups and Interest >>> >> Groups typically evolve different internal processes for developing >>> >> documents. Such processes MUST NOT conflict with the requirements in >>> >> this chapter." >>> >> >>> >> I think the word "Additional" does not quite capture what I think >>> >> you are referring to: operational details (which may very by group). >>> > >>> > Other processes are in addition to the base requirements of the process which cannot be broken. I had't used MUST because this chapter doesn't cover charters and working groups - that's a different part of Process that was ruled out of scope for this round of updates. >>> > >>> > I therefore oppose this change. Feel free to raise an issue. >>> >>> I understand your point and agree the requirement should not appear in this section. Counter proposal: >>> >>> "Different Working Groups and Interest Groups typically evolve different internal processes for developing >>> documents; these complement but do not override the requirements in this chapter." >>> >>> (or, "these augment but do not override") >>> >>> >>> >> - 7.2.4: >>> >> 1) "to ensure that independent interoperable implementations of each >>> >> feature of the specification will be realized." Suggest s/will/can/ >>> > >>> > That is a significant change that I oppose. The point is not that it is possible to make interoperability, but that the specification is sufficiently clear that this is what *will* happen. >>> >>> I don't object to "will," but I think "can" reflects the "feasibility" goal better than will here. >>> >>> > >>> > This is part of the rationale for saying "2 interoperable implementations" is a rule of thumb that suggests we're on the right track, not a statement of what the world is actually looking for in a standard, and therefore providing 7.2.4 instead of that rough rule. >>> >>> >>> >> - 7.4.1: Suggest deleting this section and simply incorporating >>> >> what's needed in 7.4. >>> > >>> > I disagree. This section was added because nobody could work out what was required (because it is unclear). >>> >>> What I had in mind was to say, for example where it says in next steps "Return to CR" something like: >>> >>> "If there are any substantive changes made to a Candidate Recommendation other than to remove features explicitly identified as "at risk", this is the required next state." >>> >>> And then, looking back at the entrance criteria for 7.4, they all pretty much still apply for a revised CR, so can't we just reuse them as-is? >>> >>> >> - 7.4: "The Director must announce the publication of a Candidate >>> >> Recommendation to other W3C groups and to the public, and must begin >>> >> an Advisory Committee Review of the specification on publication." >>> >> >>> >> Suggest deleting "on publication" as unnecessary (and possibly >>> >> over-constraining). >>> > >>> > It is a rational requirement. I don't think it is *over*-constraining to mention when the review begins, and I don't see a better alternative. >>> >>> My point is that the beginning of the sentence says "must announce the publication". So now we know there has been a publication. The sentence then adds "and must begin an AC review". So saying "on publication" is unnecessary since you already referred to the >>> publication event. >>> >>> >> - 7.9 Rescinding a W3C Recommendation >>> >> >>> >> I still believe this section is confusing. See my suggested changes >>> >> from December: >>> >> http://lists.w3.org/Archives/Public/public-w3process/2013Dec/0043.html >>> > >>> > The current approach was resolved by the TF as ISSUE-78 https://www.w3.org/community/w3process/track/issues/78 >>> > >>> > If you think we should make further changes, please reopen that issue. >>> >>> Noted. >>> >>> >>> -- >>> Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs >>> Tel: +1 718 260 9447 >>> >>> >>> >>> >> >> -- >> Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs >> Tel: +1 718 260 9447 >> >> >> > > > -- > Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex > chaals@yandex-team.ru Find more at http://yandex.com > -- Ian Jacobs <ij@w3.org> http://www.w3.org/People/Jacobs Tel: +1 718 260 9447
Received on Monday, 17 February 2014 14:51:14 UTC