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

2009-11-18 Thread Jonas Sicking
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.

/ Jonas



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

2009-11-18 Thread Julian Reschke

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



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

2009-11-18 Thread Anne van Kesteren
On Wed, 18 Nov 2009 01:03:23 +0100, Arun Ranganathan a...@mozilla.com  
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

2009-11-18 Thread Julian Reschke

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

2009-11-18 Thread Robin Berjon
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

2009-11-17 Thread Julian Reschke

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