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 06:12:08 +0100
Message-ID: <4B038228.3060003@gmx.de>
To: arun@mozilla.com
CC: Web Applications Working Group WG <public-webapps@w3.org>
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
Received on Wednesday, 18 November 2009 05:12:45 GMT

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