- From: Nathan <nathan@webr3.org>
- Date: Thu, 20 May 2010 22:53:58 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- CC: arun@mozilla.com, Robin Berjon <robin@berjon.com>, Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
Jonas Sicking wrote: > On Wed, May 19, 2010 at 1:09 PM, Arun Ranganathan <arun@mozilla.com> wrote: >>>> 3. The renaming of the property to 'url' also suggests that we should >>>> cease to consider an urn:uuid scheme. >>>> >>> I'm not sure that one follows from the other. The property's called 'url' >>> because that's what will be familiar to authors, but the magic string that >>> goes inside of it could still be a URN. FWIW, I'm a developer and sticking a URN in a .url property really doesn't seem familiar at all - even a '.id' property with an id that was consistently generated would be much better. If the scope of the identifiers is limited to a single ua, on a single machine, and specific to that single ua (as in I can't expect to request the identifier outside of the ua that provided it on x machine and get the same results) then I (personally) can't see why there's a need for anything more than a simple unique identifier (sha1 or suchlike) And if the above is true, then surely this would negate the need for .url, registering a new URI scheme, or URN namespace - and all in save you all from lots of headaches & time wasted, close the issue, and save the developer community from years of further confusion (or should i say conflated understanding of what a URL is), and benefit the entire web by saving us from yet another (predominantly unneeded) URN namespace or URL scheme. Best & leave this in your capable hands. Nathan
Received on Thursday, 20 May 2010 21:55:05 UTC