Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
Robin Berjon wrote: On Nov 18, 2009, at 13:13 , Julian Reschke wrote: Robin Berjon wrote: ... Couldn't we just register a URN NID for this? It seems that one has to go through fewer hurdles, and no matter how transient I believe that it's a useful thing to identify. ... Yes, that's possible and probably would cause less eyebrows being raised... It also doesn't seem like a lot of work, registration doesn't require specifying the behaviour of the beast (which we'd leave where it is today). We could take the urn:transient-data NID, or urn:data-handle (whichever way the bike is shed today) and toss a UUID at the end of it; then declare victory. If you go that way I'd recommend a UUID + a user-defined suffix; this allows implementations to generate less UUIDs; for instance a single one per session plus a sequence number. BR, Julian
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
On Nov 18, 2009, at 13:13 , Julian Reschke wrote: Robin Berjon wrote: >> ... >> Couldn't we just register a URN NID for this? It seems that one has to go >> through fewer hurdles, and no matter how transient I believe that it's a >> useful thing to identify. >> ... > > Yes, that's possible and probably would cause less eyebrows being raised... It also doesn't seem like a lot of work, registration doesn't require specifying the behaviour of the beast (which we'd leave where it is today). We could take the urn:transient-data NID, or urn:data-handle (whichever way the bike is shed today) and toss a UUID at the end of it; then declare victory. -- Robin Berjon - http://berjon.com/
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
Robin Berjon wrote: ... Couldn't we just register a URN NID for this? It seems that one has to go through fewer hurdles, and no matter how transient I believe that it's a useful thing to identify. ... Yes, that's possible and probably would cause less eyebrows being raised... BR, Julian
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
On Nov 18, 2009, at 06:12 , Julian Reschke wrote: > Arun Ranganathan wrote: >> 3. We could not directly call out a URI scheme at all. The benefit of doing >> this is we can specify *behavior* without actually getting into details >> about the actual identifier scheme used. But, the chief reason to not take >> this course of action is that leaving *anything* unspecified on the web >> platform leads to reverse engineering in ways that we can't envision >> currently. Developers may rely on quirks within one implementation and >> incompatibly use them with other implementations. Having to "mimic" another >> user agent's behavior has been a common outcome on the web, due to lack of >> specifications -- *many* examples of this exist on the web throughout its >> history. One lesson from the browser competition of the past is to avoid >> leaving things to guesswork. I'd like us to agree on something, and I'd >> like that agreement to be bolstered with concrete implementor feedback. >> ... > > Not requiring a specific scheme is not exactly the same thing as "leaving it > unspecified". If the *only* use of the identifier is within the API, the > syntactical form of the identifier really doesn't matter as long as it's > understood by the those parts of the platform that need to. > > Requiring a specific scheme here seems to be a case of *overspecifying*. It always seems that way, until one day one of the implementers gets smart. Say, if you're returning an opaque URL, why not put useful information in it as well? So where one vendor returns virtual:4F922EFF-02F8-42CD-9E96-04E909E099F3 another will start returning file-handle:2017/?type=image/svg+xml;size=4242;dahut=true;unicorn=pink. And then you have authors finding that useful, using it, complaining to other implementers that they don't support it, etc. Just because we seem to be going through an enlightened period of reasonably responsible UA vendors doesn't mean it'll last, either. Couldn't we just register a URN NID for this? It seems that one has to go through fewer hurdles, and no matter how transient I believe that it's a useful thing to identify. -- Robin Berjon - http://berjon.com/
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
On Wed, 18 Nov 2009 01:03:23 +0100, Arun Ranganathan wrote: 1. We could coin a new scheme such as the originally proposed filedata: scheme. This has the advantages of associating behavior (and semantics) with a scheme, so that existing schemes aren't confused or co-opted inappropriately. However, actually registering a new scheme used by browsers seemed problematic (with overhead due to coordination with multiple groups). I'm willing to revisit this idea given enough feedback, but to date, haven't really received enough of it. It's not implementor feedback, but I think this is the best solution. I think it's valuable that you can tell what the URL is for just by looking at it. Jonas gave an example of how that might be used in practice. From what I've heard so far it does not matter much for Opera either, but I rather have a new scheme. It also seems safer in case something comes up down the road. -- Anne van Kesteren http://annevankesteren.nl/
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
Jonas Sicking wrote: On Tue, Nov 17, 2009 at 9:12 PM, Julian Reschke wrote: 3. We could not directly call out a URI scheme at all. The benefit of doing this is we can specify *behavior* without actually getting into details about the actual identifier scheme used. But, the chief reason to not take this course of action is that leaving *anything* unspecified on the web platform leads to reverse engineering in ways that we can't envision currently. Developers may rely on quirks within one implementation and incompatibly use them with other implementations. Having to "mimic" another user agent's behavior has been a common outcome on the web, due to lack of specifications -- *many* examples of this exist on the web throughout its history. One lesson from the browser competition of the past is to avoid leaving things to guesswork. I'd like us to agree on something, and I'd like that agreement to be bolstered with concrete implementor feedback. ... Not requiring a specific scheme is not exactly the same thing as "leaving it unspecified". If the *only* use of the identifier is within the API, the syntactical form of the identifier really doesn't matter as long as it's understood by the those parts of the platform that need to. Requiring a specific scheme here seems to be a case of *overspecifying*. As far as I'm concerned, the reason to specify a scheme here is for code that would stuff a bunch of URIs into an array, then walk through the array and depending on what type of URI it is do different things. Say a function that takes an array of URIs of images to pre-cache (in order to allow the images to be displayed in a user interface without ugly half-loaded images). The code might look something like: var imgCache = []; function cacheURIs(uris) { for each (var uri in uris) { // No need to waste resources on caching local images, they load fast enough anyway if (uri.substr(0, 9) != "urn:uuid:") { img = document.createElement("img"); img.src = uri; imgCache.push(img); } } } Now, we can certainly debate how likely it is that someone will write code like the above. For example, when would you have a mixture of remote and local uris like that? But I don't think it's impossible, so I wouldn't think it's overspecifying. ... If the use case is, given an arbitrary URI, to distinguish one identifying a file object from others, then *either* a distinct scheme (1) is needed, or an API could be added that answers that question. (1) In that case, re-using "urn:uuid" seems to be a bad idea, because it precludes that scheme being used for anything else. BR, Julian
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
On Tue, Nov 17, 2009 at 9:12 PM, Julian Reschke wrote: >> 3. We could not directly call out a URI scheme at all. The benefit of >> doing this is we can specify *behavior* without actually getting into >> details about the actual identifier scheme used. But, the chief reason to >> not take this course of action is that leaving *anything* unspecified on the >> web platform leads to reverse engineering in ways that we can't envision >> currently. Developers may rely on quirks within one implementation and >> incompatibly use them with other implementations. Having to "mimic" another >> user agent's behavior has been a common outcome on the web, due to lack of >> specifications -- *many* examples of this exist on the web throughout its >> history. One lesson from the browser competition of the past is to avoid >> leaving things to guesswork. I'd like us to agree on something, and I'd >> like that agreement to be bolstered with concrete implementor feedback. >> ... > > Not requiring a specific scheme is not exactly the same thing as "leaving it > unspecified". If the *only* use of the identifier is within the API, the > syntactical form of the identifier really doesn't matter as long as it's > understood by the those parts of the platform that need to. > > Requiring a specific scheme here seems to be a case of *overspecifying*. As far as I'm concerned, the reason to specify a scheme here is for code that would stuff a bunch of URIs into an array, then walk through the array and depending on what type of URI it is do different things. Say a function that takes an array of URIs of images to pre-cache (in order to allow the images to be displayed in a user interface without ugly half-loaded images). The code might look something like: var imgCache = []; function cacheURIs(uris) { for each (var uri in uris) { // No need to waste resources on caching local images, they load fast enough anyway if (uri.substr(0, 9) != "urn:uuid:") { img = document.createElement("img"); img.src = uri; imgCache.push(img); } } } Now, we can certainly debate how likely it is that someone will write code like the above. For example, when would you have a mixture of remote and local uris like that? But I don't think it's impossible, so I wouldn't think it's overspecifying. / Jonas
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
Arun Ranganathan wrote: Is there a particular reason why a specific URI scheme needs to be called out at all? (there are other schemes that may be more flexible, for instance because they allow using a UUID/String pair for identification). This is a useful question to answer :) I assume everyone understands use cases for this identifier. Ian's email discusses a few [1] which have been supplemented with a few more. There are a few ways to proceed: ... > 2. We could reuse an existing scheme. This seemed desirable if there was little chance of confusion and collision, and it avoids multi-group coordination. Using urn:uuid was an obvious choice given assumptions on UUID uniqueness, but it is hardly a "pave the cowpaths" choice since it isn't currently used on the web platform in any way I can recognize. I don't think that it matters at all whether it's widely used, as long as it's properly specified. That being said it is used in WebDAV (lock token URIs) and Atom (Atom:id). ... 3. We could not directly call out a URI scheme at all. The benefit of doing this is we can specify *behavior* without actually getting into details about the actual identifier scheme used. But, the chief reason to not take this course of action is that leaving *anything* unspecified on the web platform leads to reverse engineering in ways that we can't envision currently. Developers may rely on quirks within one implementation and incompatibly use them with other implementations. Having to "mimic" another user agent's behavior has been a common outcome on the web, due to lack of specifications -- *many* examples of this exist on the web throughout its history. One lesson from the browser competition of the past is to avoid leaving things to guesswork. I'd like us to agree on something, and I'd like that agreement to be bolstered with concrete implementor feedback. ... Not requiring a specific scheme is not exactly the same thing as "leaving it unspecified". If the *only* use of the identifier is within the API, the syntactical form of the identifier really doesn't matter as long as it's understood by the those parts of the platform that need to. Requiring a specific scheme here seems to be a case of *overspecifying*. Best regards, Julian