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
