Re: (Dis)Proving that 303s have a performance impact.

On Mon 2013-Feb-18, at 15:24, Kingsley Idehen <kidehen@openlinksw.com>
 wrote:

> Since you have the luxury of adding whatever you see fit to the spec, while being selective about my responses [1][2], here is a simple and concise request:
>
> Please remove the notice about hashless URIs from the spec. It serves no purpose bar a weasel-style mechanism for negating the results of  last vote about the definition of a WebID.


Nobody's being selective about your responses, it's just that there isn't consensus yet, and reaching one has been severely hampered by a steady stream of messages consisting of...

• you've got loads of real-world experience and everybody else is dealing solely in theory and so you must be right and the rest are wrong;

• complaints that your messages are being selectively paid attention to; and

• an ultimatum that if a particular guidance note is not removed, you'll leave the group.

All of this is grade-A histrionics, though I am wondering why the messages have continued given the ultimatum.

You have stated that you think *the very presence* of a short note which explains why an otherwise completely unexplained (within the spec) aspect of the examples is written as such is both unnecessary and confusing. Clearly, others disagree with you.

Your above-linked [1] poses a question and makes an assertion:

The question:

Q: Why is it there?

The assertion:

A: You don't need that piece of confusion. The examples can be hashed based and just leave it at that.


The answer to that question is, as has now been stated a few times, “because otherwise it's not clear to the untrained eye what the purpose of the fragids in the examples is, and those who aren't complete novices minded to just copy & paste examples will either not know what they're for (bad) or ignore them completely (worse)”.

You also assert that the presence of it is confusing.

Taking the assertion first: I'm really struggling to wrap my head around the concept that the principle of a one-sentence line of explanatory text is confusing and can't for the life of me fathom a scenario where that's true unless it duplicates something already being stated clearly and obviously in the spec. Clearly, the form of words used might itself be confusing — but that's easy to solve by changing them to be clearer.

Now, if the answer above is liable to be correct for more than an exceptional set of people (and it seems very likely that it will be once the spec is being read beyond the SW community), then that only leaves the issue of whether a guidance note will satisfy that issue and whether it will introduce more problems as a side-effect, as you state.

So it boils down to this simple question:—

Is it likely to be helpful to some readers of the spec to include a short note to explain the purpose of hash URIs in the examples, or is it likely to be otherwise confusing?

My stance is simply this: with the right form of words, it's very likely to be helpful, and shouldn't be confusing to anybody.

To advance things, it may — as you suggested previously, Kingsley — put that to a vote, though it is worth noting that when you wrote [2] it wasn't especially clear what should be voted on except the exact words as written by Andrei, which wouldn't have been at all helpful.

M.

>
>
> Those of us that oppose the distracting notice do so for  because it conflates the following distinct concerns:
>
> 1. WebID Definition -- an HTTP URI based identifier that denotes an Agent .
> 2. WebID oriented Profile Document Definition-- a document that describes an Agent with the additional goal of verifying the identity of said Agent .
> 3. WebID oriented Authentication Protocol -- a TLS based protocol (WebID+TLS) that enables the verification of an Agent identity using its WebID.
> 4. How to Publish a WebID oriented Profile Document with WebID+TLS protocol in mind -- the actual act of publishing a Profile Document that seeks to deliver Web-scale verifiable identity using the WebID+TLS protocol .
>
>
> Hopefully, this is concise and understandable.
>
> Links:
>
> 1. http://lists.w3.org/Archives/Public/public-webid/2013Feb/0027.html -- initial request (clearly verbose and incomprehensible) .
> 2. http://lists.w3.org/Archives/Public/public-webid/2013Feb/0045.html -- another .
> 3. http://lists.w3.org/Archives/Public/public-webid/2013Feb/thread.html -- threaded view of this mailing list .
>
> Bye.
>
> Kingsley
>>
>>
>>
>> --
>>
>> 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
>>
>>
>>
>>
>>
>>
>
>
> --
>
> 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
>
>
>
>
>
>

--
Mo McRoberts - Technical Lead - The Space
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA
Project Office: Room 7083, BBC Television Centre, London W12 7RJ



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Monday, 18 February 2013 15:59:16 UTC