W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: File API commens

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 8 Oct 2009 10:48:51 -0700
Message-ID: <63df84f0910081048w75acda8fv697d8f7e54efa61e@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Larry Masinter <masinter@adobe.com>, public-webapps@w3.org, arun@mozilla.com
On Thu, Oct 8, 2009 at 9:53 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> Jonas Sicking wrote:
>>
>> ...
>> 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.
>>
>> Would it need to be urn:somename:uuid though? like urn:fileid:uuid?
>> ...
>
> What's wrong with urn:uuid, which is defined in RFC 4122 and already cited?

Ah, now I see what you mean. So the URI would be

urn:uuid:<uuid>

for example

urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

The other thing that needs to be ok is that the lifetime of the URI
"working", i.e. the time it actually successfully returns the contents
of the File, is limited to the lifetime of the Document the File was
created in. I guess you could simply view that as the resource behind
the urn changing once the Document goes away.

>> Also, Anne pointed out that we probably want fragment identifiers to
>> work in whatever URI is returned. Would that be possible if we use
>> 'urn'? If I'm reading rfc2141 right, it seems to say it's undefined.
>
> Fragment identifiers are independent of the URI scheme
> (<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.5>).

Excellent.

/ Jonas
Received on Thursday, 8 October 2009 17:49:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:34 GMT