Ian Hickson wrote:
On Thu, 8 Oct 2009, Jonas Sicking wrote:
- why is a new URI scheme needed? Can't you just use urn:uuid?
I think we'd really like to avoid creating a new scheme if we could
reuse an existing one. I know Arun was looking for an existing scheme,
but not sure if he looked at the 'urn' scheme.
I think we need a new URL scheme because otherwise we're going to end up
with really complicated origin rules (e.g. the origin of
"urn:isbn:0123..." is a unique ID, but the origin of "urn:uuid:0123..." is
the special file API origin). Reusing urn:uuid would also mean basically
Unless I'm missing something, you already have that distinction. The
only thing to decide is how to detect which rule should apply. As the UA
mints those URIs it would be able to answer that.
hijacking the urn:uuid semantics in browsers and overriding them with
something else, such that, e.g., nobody could reuse this scheme in other
contexts if there was any risk of the context coming into contact with
brosers. And of course there's the implementation cost; APIs generally
make it much easier to implement a new scheme than to implement part of
the space created by the urn: scheme.
I'm not suggesting to "hijack" urn:uuid semantics. What I'd like to
understand is why the URI scheme matters here. How to deal with a given
URI should be the decision of the UA, which should know what it refers to.
Slightly related to that: is there a particular reason why the
"filedata" URI scheme mandates the use of a UUID? Shouldn't be any
locally unique identifier sufficient?
BR, Julian
