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, 2 Sep 2009 16:33:32 +0200
Cc: Anne van Kesteren <annevk@opera.com>, Arve Bersvendsen <arveb@opera.com>, marcosc@opera.com, public-webapps <public-webapps@w3.org>
Message-Id: <1AE4FA3A-E505-46B2-A806-04E67EDC2E5C@berjon.com>
To: Mark Baker <distobj@acm.org>
On May 23, 2009, at 19:21 , Mark Baker wrote:
> Right.  That's the same point Arve made.  I don't see a problem with
> it.  Sure, a widget will be able to discover an implementation detail
> of its widget container - the base URI - but it's still up to the
> container to permit or deny access to other resources from that widget
> when asked to dereference it, whether the widget discovered the URI
> via a mechanism such as the one you describe, or even if it simply
> guessed it.

Calling it an implementation detail doesn't make it one. Say I have a  
script in which I need to identify resources that I'm currently using  
from within the widget. Since I don't want to have to care how the  
designers linked them in, I'll use their absolute URIs to compare  
them. If implementation A returns "http://magic-widget-host.local/dahut.svg 
", and implementation B "file:///special-widget-mount/dahut.svg", and  
C gives me "made-up:/dahut.svg we don't exactly have interoperability.

This gets more interesting once you bring the localisation mechanism  
from P+C into play, whereby the Zip relative path and the relative URI  
are different when you have multilingual content.

-- 
Robin Berjon - http://berjon.com/
Received on Wednesday, 2 September 2009 14:34:07 GMT

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