[widgets] Proposal to update Dig Sig spec; deadline May 3

Widget People - if you have any objections/concerns re Marcos' proposal 
below, please respond by May 3 at the latest. (For some additional 
context, the start of the thread is [1]).

Marcos - if no major objections/concerns are raised by this deadline, 
please proceed as you propose below.

-Thanks, AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0306.html

-------- Original Message --------
Subject: 	Re: [widgets] Dig Sig spec
Date: 	Tue, 26 Apr 2011 14:19:44 +0200
From: 	ext Marcos Caceres <marcosscaceres@gmail.com>
To: 	Arthur Barstow <art.barstow@nokia.com>
CC: 	public-webapps <public-webapps@w3.org>



On Tuesday, April 26, 2011 at 2:02 PM, Arthur Barstow wrote:
>  Well, you started with a relatively ambiguous characterization of a need
>  to eliminate "redundancies and inconsistencies" and now I see you think
>  the spec as written has resulted in "willful violations of the spec" and
>  of course those are quite different.
Correct. But one really led to the other. The reality is that very few people who implemented the spec really read the spec in detail. Most people seemed to have been working from the examples. This is normal and to be expected. Cleaning it up a bit should make it easier to follow.
>
>  Since this spec is in the Candidate state (and as such, perhaps already
>  deployed), I think it would be helpful if you would please flesh out all
>  the changes and bug(s) you propose must be fixed ^1. Then we should be
>  able to have a more informed discussion re "if it's OK to have a go at
>  rewriting".
I'm ok with that, but would prefer to do it like this:

1. make a mirror copy of the spec.

2. make all the edits I think need to be made. It's not many, as the spec is relatively small (~14 pages).

3. make a diff of the two documents to build the list of changes.

4. propose the complete list of changes to the group.

5. let the group decide which changes they accept or reject or need further discussion. If the new spec is take wholesale, then great. Otherwise, it's easy to backtrack on proposed changes.

This is how I've done this kinds of changes in the past and it's always worked out ok.

Received on Tuesday, 26 April 2011 12:51:01 UTC