- From: Marcos Caceres <marcosc@opera.com>
- Date: Wed, 8 Jul 2009 16:10:27 +0200
- To: Francois Daoust <fd@w3.org>
- Cc: Robin Berjon <robin@berjon.com>, public-webapps@w3.org
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? 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/ > > > > > > > -- Marcos Caceres http://datadriven.com.au
Received on Wednesday, 8 July 2009 14:11:22 UTC