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

On Sun, Feb 17, 2013 at 7:59 AM, Melvin Carvalho
<melvincarvalho@gmail.com>wrote:

> "Note
>
> Hash URIs are encouraged when choosing a WebID since 303 redirects require
> an extra HTTP request for an Agent to get from the WebID<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#dfn-webid>to the WebID
> Profile<https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#dfn-webid_profile>.
> All examples in the spec will use such hash URIs."
>
>
> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#the-webid-http-uri
>
> This has come up in some other threads.
>
> Leaving the # vs slash "perma debate" aside, may I propose that this part
> is removed.
>
> While, I am in favour of the sentiment of using # URIs but I dont see any
> evidence that this note will have the desired effect.  Why even mention
> 303s at all?  All the examples use # URIs so, imho, this point is not
> really needed, and may add confusion to implementers.
>
I agree, and your argument above makes sense, Melvin. By
not mentioning 303s anywhere in the spec, we would keep the spec simple and
bring less confusion. We use hash URIs in all our examples, and people who
are new to WebID and looking at implementing this will use hash URIs.
People who prefer to use 303s are free to do so. If they know about 303s,
they most likely know what they are doing and the trade offs etc. The wiki
could present different views on how to implement WebID (including 303s
with a big warning if you like) but the spec would be free of such
implementation details. Again, the spec becomes more simple and straight
forward as a result.

re establishing the relation between the WebID URI and the Profile
document: we can simply say that the Profile document is whatever you get
by dereferencing the WebID URI according to the HTTP protocol. The WebID
URI must be different from the Profile document URI, and hash URIs is the
most intuite way to do that.

A this point, a vote might be more fruitful to solve this than another
perma-thread.

-- 
Steph.

PS: argument above is in line with Elf's point too re obviousness of HTTP
redirects.