Re: WebID 1.0 -- Section 3 -- Removal of Note

On 2/17/13 2:52 PM, Henry Story wrote:
> On 17 Feb 2013, at 19:56, ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org> wrote:
>
>>>  From my perspective telling a reader of a spec that using 303 redirect will require an extra HTTP requests sounds a bit like stating the obvious...
> Thanks Elf. The argument that it is obvious that 303s are less efficient for requiring an extra redirect, is the best argument I have read  here against having this section up to now. It is nice to see commonsense sprouting from the darkness of the winter night. Spring must be on its way.
>
> I would have embraced your argument fully had the length of this thread not show how non-evident this actually seems to be to many.

Elf: you've just received a typical response from Henry who 
(unfortunately) doesn't understand the role of a community group chair 
person or the  editor of a spec. Thus, even though he agrees with your 
point, nothing will change.

Henry:

This isn't a dictatorship in disguise. Do check up the essence of 
parliamentary process. Don't try to use a W3C community group (or 
related) to push your personal agenda. It will never succeed. Thus, stop 
wasting the limited time of folks that are trying to make something of 
WebID and its application re. the  WebID+TLS protocol.

Your choices are as follows (once again):

1. Call a vote .
2. Perform a proper Linked Data experiment -- you'll have a hypothesis, 
observations (in the form of empirical data), and conclusion  at your 
disposal.
3. Remove the unnecessary notice.

Why are you averse to what's outlined above?


>
> Henry
>
>
> Social Web Architect
> http://bblfish.net/
>


-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Sunday, 17 February 2013 21:00:34 UTC