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

Re: [widgets] Comments on Widgets 1.0: Packaging and configuration, 9.1 Processing rules

From: Francois Daoust <fd@w3.org>
Date: Wed, 08 Jul 2009 18:05:55 +0200
Message-ID: <4A54C3E3.7030609@w3.org>
To: marcosc@opera.com
CC: Robin Berjon <robin@berjon.com>, public-webapps@w3.org
Hi Marcos,

Marcos Caceres wrote:
> Hi Francois,
> Just to be clear, I made the change you requested (relative and abs
> URIs behave exactly the same). I think that concludes all issues
> raised in this thread.


> For the Disposition of Comments, can we get your acknowledgment that
> you are satisfied?

I am satisfied! :-)

Many thanks,

> Kind regards,
> Marcos
> On Tue, Jul 7, 2009 at 6:06 PM, Robin Berjon<robin@berjon.com> wrote:
>> On Jul 7, 2009, at 15:46 , Marcos Caceres wrote:
>>> On Tue, Jul 7, 2009 at 2:43 PM, Robin Berjon<robin@berjon.com> wrote:
>>>> Or at least, not
>>>> without deciding that we have our own rules for relative URI reference
>>>> absolutisation, which I fervently hope we don't.
>>> I think we all agree we want URIs to behave as they do in browsers.
>> I hoped we would :)
>>>> I think that there are two ways to resolve this comment:
>>>>  - drop the distinction that's in the spec between /foo and foo in
>>>> config.xml
>>> I'm ok to do this. It now reads:
>>> "If the path starts with a U+002F SOLIDUS (e.g., "/style/master.css"),
>>> meaning that the path is an Zip absolute path, then remove the first
>>> U+002F SOLIDUS from path. "
>>> The algorithm continues as normal (i18n is applied, etc.) and no
>>> longer is the behavior different (i.e., the root of the widget package
>>> is not searched first, but last).
>>> So, this means that the behavior of both "/abc" and "abc" are now
>>> exactly the same.
>> That's fine by me.
>>>>  - make it very clear that that distinction exists only in config.xml
>>>> (which
>>>> uses paths, not URIs)
>>> If they are paths or not depends on the processing model. But yes, the
>>> current model assumes paths.
>> Right. The interesting thing here is that this means that the processing is
>> merely clarified.
>>>> Since I don't personally see a strong use case for the distinction, I'm
>>>> happy either way.
>>> I do see strong need to sort this out. It might be that in the future,
>>> for whatever reason, we want to treat these as URIs. For example,
>>> allowing content@src to point to a document on the Web.
>> That could happen, yes. And when it does, whatever URIs that appear in there
>> will be absolute I would expect (or there would be some other mechanism
>> providing a base). If so, then there will be a way to distinguish between
>> absolute URI references (it starts with a scheme) or to distinguish based on
>> the use of the previously mentioned other mechanism. Or we could use another
>> attribute (say content/@href). I agree it could be useful going forward, but
>> I don't believe we've painted ourselves into a corner.
>>> _HOWEVER_, we can deal with this in the future. Lets agree that this
>>> is the way it's going to work for now.
>> +1
>> --
>> Robin Berjon - http://berjon.com/
>>    Feel like hiring me? Go to http://robineko.com/
Received on Wednesday, 8 July 2009 16:06:37 UTC

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