Jonas Sicking wrote:
On Tue, Nov 17, 2009 at 9:12 PM, Julian Reschke <julian.resc...@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
