W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [widgets] Widgets URI scheme... it's baaaack!

From: Robin Berjon <robin@berjon.com>
Date: Wed, 9 Sep 2009 16:17:58 +0200
Cc: public-webapps <public-webapps@w3.org>
Message-Id: <88AB3AD7-3D00-4231-96D4-D1D1C452FA45@berjon.com>
To: Mark Baker <distobj@acm.org>
On Sep 8, 2009, at 17:18 , Mark Baker wrote:
>> function getSection () {
>>  return location.href.replace(/^http:\/\/magic.local\/([^\/]+).*/,
>> "$1").toLowerCase();
>> }
>> I won't say that it's necessarily the best-written code, but it's  
>> not daft
>> enough to be shrugged off and it's not particularly contrived. It's  
>> easy to
>> come up with a bunch of similar cases. If you get one  
>> implementation with
>> more market-share than the others, then they'll have to copy its  
>> behaviour,
>> and we'll then have to specify it.
> The regex could just as easily have been written to exclude the
> authority component of the URI.  Do you have a better example?

It could have, but it wasn't — interoperability isn't what happens  
when people write to a W3C working group to get their code debugged,  
it's what happens when real people write code on their own.

Let us assume that we don't at all say what is returned by the many  
attributes that normally expose URIs. What regex would you "just as  
easily have written" to match an unspecified value? Here are some  
samples from several implementations given an image linked to as /img/ 

  A: http://magic.local/img/dahüt.svg
  B: file://mushroom.local/img/dahüt.svg
  C: file:///img/dahüt.svg
  D: file:///C|/img/dahüt.svg
  E: \\myphone\img\dahüt.svg
  G: http:///img/dah%FCt.svg
  H: cool-product:/img/dah%u0055%u0308t.svg
  J: many more things...

Another situation is a security manager that applies different  
policies based on scheme, authority, etc. URIs are useful — they can  
identify and locate stuff.

Let's imagine we say nothing and you're an implementer: what would you  
do? Everyone in this discussion understands that introducing new  
schemes should be done with caution — what I don't understand is what  
architectural value you are seeing in not using URIs to identify  
resources, encouraging non-interoperable solutions, or sweeping the  
issue under the rug by delegating to a special name instead of a scheme.

We have a semantics that match no existing scheme. We have a locator  
behaviour that matches no existing scheme.  Resources should be  
identified by URIs. All we're doing is applying the Web architecture.

Robin Berjon - http://berjon.com/
Received on Wednesday, 9 September 2009 14:18:41 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC