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

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 Tuesday, 7 July 2009 16:06:39 UTC