File API comments

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

Received on Friday, 9 October 2009 12:56:27 UTC