[whatwg] Reserving XRI and URN in registerProtocolHandler

On 11/26/2010 7:13 PM, Julian Reschke wrote:
> On 26.11.2010 11:54, Brett Zamir wrote:
>> ...
>> My apologies for the lack of clarity on the approval process. I see all
>> the protocols listed with them, so I wasn't clear.
>>
>> In any case, I still see the need for both types being reserved (and for
>> their subnamespaces targeted by the protocol handler), in that
>> namespacing is built into the XRI unlike for informal URNs which could
>> potentially conflict.
>> ...
>
> I'm still not sure what you mean by "reserve" and what that would mean 
> for the spec and for implementations.
>
I just mean that authors should not use already registered protocols 
except as intended, thinking that they can use any which protocol name 
they like (e.g., the Urn Manufacturers Company using "urn" for its 
categorization scheme).
> I do agree that the current definition doesn't work well for the "urn" 
> URI scheme, as, as you observed, semantics depend on the first 
> component (the URN namespace). Do you have an example for an URN 
> namespace you actually want a protocol handler for?
>
ISBNs.
> Finally, I'd recommend not to open the XRI can-of-worms (see 
> <http://en.wikipedia.org/wiki/Talk:Extensible_Resource_Identifier>).

Ok, looks like I misappropriated this based on an incomplete 
understanding. Still, at least the part about having a namespaced naming 
protocol makes sense to me. For example, if Wikipedia offered its own 
article names up for referencing using its own namespace to define which 
scheme was being used, but in a generic way so they could be 
dereferenced to articles on Britannica, Citizendium, etc., sites 
wouldn't need to be showing preference to only one encyclopedia when 
they added links (or at least give the choice to their users by using 
the attributes I proposed be added to <a/> such as "alternateURIs" for 
the fallbacks after "href" or "defaultURIs" for the priority ones before 
"href").

Brett

Received on Friday, 26 November 2010 07:55:28 UTC