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

Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 18 Nov 2009 09:46:11 +0100
Message-ID: <4B03B453.6010307@gmx.de>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC