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: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 18 Nov 2009 00:12:34 -0800
Message-ID: <63df84f0911180012i388133bay38c36a0806e72179@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
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.

/ Jonas
Received on Wednesday, 18 November 2009 08:13:40 GMT

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