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

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

From: Marcos Caceres <marcosc@opera.com>
Date: Fri, 4 Sep 2009 17:40:19 +0200
Message-ID: <b21a10670909040840r6145ce7el1494da4038603564@mail.gmail.com>
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.


Marcos Caceres
Received on Friday, 4 September 2009 15:41:19 UTC

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