- From: Marcos Caceres <marcosc@opera.com>
- Date: Fri, 4 Sep 2009 17:40:19 +0200
- To: Robin Berjon <robin@berjon.com>
- Cc: Mark Baker <distobj@acm.org>, Anne van Kesteren <annevk@opera.com>, Arve Bersvendsen <arveb@opera.com>, public-webapps <public-webapps@w3.org>
On Wed, Sep 2, 2009 at 4:33 PM, Robin Berjon<robin@berjon.com> wrote: > 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. And here is where the fun starts. How do we reconcile the above without a new scheme? > 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. > Exactly. -- Marcos Caceres http://datadriven.com.au
Received on Friday, 4 September 2009 15:41:19 UTC