W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [widgets] Dig Sig spec

From: <Frederick.Hirsch@nokia.com>
Date: Fri, 29 Apr 2011 18:19:25 +0000
To: <marcosscaceres@gmail.com>
CC: <Frederick.Hirsch@nokia.com>, <Art.Barstow@nokia.com>, <public-webapps@w3.org>
Message-ID: <54921F28-9A35-473A-B156-927A45415CE3@nokia.com>
Marcos 

I'd suggest you first send an email with the top 10 substantive changes to the list, e.g. which algorithms change from mandatory to optional or optional to mandatory etc, which processing rules you are relaxing, etc

this would take less time for you and be much clearer to all.

thanks

regards, Frederick

Frederick Hirsch
Nokia



On Apr 26, 2011, at 8:19 AM, ext Marcos Caceres wrote:

> 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 Friday, 29 April 2011 18:20:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT