- From: Marcos Caceres <marcosc@opera.com>
- Date: Tue, 7 Jul 2009 15:46:42 +0200
- To: Robin Berjon <robin@berjon.com>
- Cc: Francois Daoust <fd@w3.org>, public-webapps@w3.org
On Tue, Jul 7, 2009 at 2:43 PM, Robin Berjon<robin@berjon.com> wrote: > Hi all, > > sorry I didn't jump in earlier, I was taken with entirely different > considerations. > > François is entirely right in his evaluation of the way in which widget URIs > work, which is to say that in a document at the root of the widget you can't > treat <a href='/foo'> and <a href='foo'> any different. Yes, I understand that. > 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 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. > - 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. > 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. > Technically I have a small preference for the first > option, process-wise I prefer the clarification. My preference is that everything be treated as a URI. However, because the current model treats the values as paths, the model is incomplete. To treat the value of zip paths as URIs, they need to be converted to URI strings. _HOWEVER_, we can deal with this in the future. Lets agree that this is the way it's going to work for now. -- Marcos Caceres http://datadriven.com.au
Received on Tuesday, 7 July 2009 13:47:39 UTC