On Jul 7, 2009, at 15:46 , Marcos Caceres wrote:
On Tue, Jul 7, 2009 at 2:43 PM, Robin Berjon<ro...@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 cont...@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/
