Re: SHOULD/MUST fragment identifier definition question

On Mon, Dec 10, 2012 at 12:20 PM, Henry Story <henry.story@bblfish.net> wrote:
>
> On 10 Dec 2012, at 19:36, Stéphane Corlosquet <scorlosquet@gmail.com> wrote:
>
>
>
> On Mon, Dec 10, 2012 at 8:10 AM, Henry Story <henry.story@bblfish.net>
> wrote:
>>
>> A question to supporters of SHOULD/MUST:
>>
>> This is to be found in the terminology section:
>>
>> for MUST:
>>
>> http://dvcs.w3.org/hg/WebID/raw-file/d21603d3972a/spec/identity-respec.html#terminology
>> [[
>> A WebID is a URI with an http or https scheme, which contains a  URI
>> fragment identifier (i.e. a #id ) and which uniquely denotes an Agent
>> (Person, Organization, Group, Device, etc.). The URI without the fragment
>> identifier denotes the WebID Profile page.
>> ]]
>> should the text contain a MUST there, or is the above strong enough?
>>
>> for SHOULD:
>>
>> http://dvcs.w3.org/hg/WebID/raw-file/http-hash-uri-should/spec/identity-respec.html#terminology
>> [[
>> A WebID is a URI with an HTTP or HTTPS scheme which uniquely denotes an
>> Agent (Person, Organization, Group, Device, etc.). This URI SHOULD include a
>> fragment identifier (a string after a "#" character).
>> ]]
>>
>> Does a hash URI require a string after the hash character?
>>
>> Facebook for example does not have such a string as you can see here:
>>
>>   curl -H "Accept: text/turtle" http://graph.facebook.com/bblfish
>>
>> Also is the terminology section the normative one?
>
>
> Yes, it is.
>
> The ABNF for URI [1] does not prevent the fragment from being empty, so
> empty frag hash URIs are legal. Note however that in javascript in the
> browser you can't use window.location.hash to know whether it's a hash URI
> or not because it returns the empty string whether you have a hash with the
> empty frag ID or or no hash at all (you'd have to parse windown.location
> manually, but I'm not sure if people would think to do that). Also, I would
> not be surprised if some APIs generating URIs out there would not append a
> hash unless a frag string is passed in, but that doesn't concern us and
> doesn't mean we have to disallow the empty frag. It does look odd and people
> might be tempted to remove it thinking it's useless. Having an explicit
> fragid makes it obvious that it is intended and it's not a mistake, but
> that's just usability, nothing that needs to be required in our spec. I'm of
> two minds about this: Henry, what change do you propose exactly? what would
> you remove from the definition? we could say "A WebID is a URI which
> contains a fragment identifier or ends with '#'".

....contains a fragment identifier, for example  #id . This can include
the empty string fragment*, but that has usability problems including
javascript parsing that is beyond the scope of this spec.

or * despite usability problems that are beyond this spec.

I think it is good to explain the extent, including potentially
questionable corner cases and how the corners are concave.

>
>
> Mhh, perhaps that's just solved by considering the # as having an empty
> string fragment... I had not thought of that... In that case it is easier to
> leave the text as is. ( I have removed the ( eg. text in the questionair
> definitions ) )
>
>
> Steph.
> PS:
>
> [1] http://tools.ietf.org/html/rfc3986#appendix-A
>
>
> Social Web Architect
> http://bblfish.net/
>

Received on Tuesday, 11 December 2012 08:25:20 UTC