- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 18 Nov 2009 09:46:11 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- CC: arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
Jonas Sicking wrote: > On Tue, Nov 17, 2009 at 9:12 PM, Julian Reschke <julian.reschke@gmx.de> 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
Received on Wednesday, 18 November 2009 08:47:00 UTC