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

Julian Reschke wrote:
> Arun Ranganathan wrote:
>> The latest revision of the FileAPI editor's draft is available here:
>>
>> http://dev.w3.org/2006/webapi/FileAPI/
>> ...
>>
>> 4. A suggestion to *not* have a separate scheme ("filedata:") in lieu 
>> of urn:uuid:<uuid>[2] has been the basis of a rewrite of that feature 
>> in this version of the specification.
>> ...
>
> 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:

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.


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.  
Also, "urn" isn't used on the web platform as an attribute on 
interfaces, but "url" is, so we once again have a consistency argument.  
While consistency is desirable, I don't think we should be too hung up 
on it.  To make a longer story shorter, urn:uuid addressed the use case 
fairly well, and seemed a useful starting point. 


[ Now between 1. and 2., I'd say the deciding factor might be 
implementation feedback.  For instance, Firefox's code is such that 1. 
and 2. are both (pretty much) *equally* feasible.  We also got some 
feedback from Microsoft [2], but that feedback seems to be preliminary, 
with more to come.  I'm also not sure concern over origin issues are 
valid here [2], since a perusal of the issues with jar: (which urn:uuid 
has been compared to) doesn't reveal any cogent origin effrontery.  I'd 
really like *more* implementor feedback on this issue.  ]


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.

-- A*

[1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1110.html

[2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0462.html

Received on Wednesday, 18 November 2009 00:04:05 UTC