- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 6 Jul 2009 18:36:02 +0200
- To: Francois Daoust <fd@w3.org>
- Cc: public-webapps@w3.org, Robin Berjon <robin@berjon.com>
Hi Francois, On Mon, Jul 6, 2009 at 6:01 PM, Francois Daoust<fd@w3.org> wrote: > Marcos Caceres wrote: >> >> Hi Francois, >> >> A brief response to your question below... >> >> For the Disposition of Comments, can you please respond to this email >> and indicate if you are satisfied with the WG's responses? > > One final attempt below (did I already say that? Sigh, apologies if I did). > Could you have a look? > > > [...] >>> >>> Per the rule for finding a file within a widget package [1] defined in >>> the >>> packaging spec, the start file is resolved in step 3, and matches >>> "widget.wgt/start.html". No localization because it is an absolute path. >>> Per the Mapping widget URIs to Widget Resources [2] section in the widget >>> scheme spec, the starting "/" gets removed before applying the rule for >>> finding a file within a widget package [1], so "about.html" enters the >>> rule >>> steps, localization occurs, and "widget.wgt/locales/fr/about.html" gets >>> matched. >> >> This is a bug in the URI spec. Absolute path is an absolute path, IMO. >> I will ask Robin, who is editing the URI spec, to fix this. >> >>> From a user perspective, why should there be a difference between the way >>> links in the config file and links in other files are mapped to widget >>> resources? >>> >> >> I agree. This should be consistent: the URI spec needs to follow the P&C >> spec. > > I agree this should be consistent. > I disagree the widget scheme spec can be fixed though. oh oh :( > Relative references (relative URI references include both relative and > absolute paths) are introduced in section 1.2.3 of RFC3986: > http://tools.ietf.org/html/rfc3986.html#section-1.2.3 > > Two excerpts from the section: > > [[ A relative reference (Section 4.2) refers to a resource by describing > the difference within a hierarchical name space between the reference > context and the target URI. ]] > > [[ relative references can only be used within > the context of a hierarchical URI ]] > Admittedly, and with no disrespect, I find the above quotes mindbogglingly abstract. Alas... I'll try to use my own practical understanding of what those terms mean. > > Relative references are then properly defined in section 4.2: > http://tools.ietf.org/html/rfc3986.html#section-4.2 > ... which reads: > > [[ The URI referred to by a relative reference, also known as the target > URI, is obtained by applying the reference resolution algorithm of > Section 5. ]] > > A relative reference is "just" a shortcut to an absolute URI that takes > advantage of the usual tree structure of documents (and makes it possible to > somehow become independent of the scheme and location of the documents, as > the absolute URI is constructed from the base URI that may depend on the > context). Ok. The context for resolution is the the config.xml, which always sits at the root (base URI = "widget:///"). widget.wgt config.xml en/index.html fr/index.html index.html So, all relative references are resolved relative to config.xml. However, because we have this i18n thing that sits in the middle, it can intercept requests for resources and send back a different file. > The reference resolution algorithm explains how to convert the relative > reference into an absolute URI. In my example case, this would turn > "/about.html" AND "about.html" into "widget:///about.html". Ok, I was arguing: "/about.html" = "widget:///about.html". And: "about.html" = "widget:///" + UA Locale + "/about.html". OR, it could "silently" map to: "/about.html" = "widget:///about.html" = (but resource served was "/locales/en/index.html"). > In short, handling absolute and relative paths differently is inconsistent > with the way URIs should be handled. There is no way for both paths to > produce different absolute URIs (is there?). I agree. Now I'm unsure how to proceed with the P&C spec. > A concrete example as to why it matters in practice would be a resource > cache in a widget engine. The usual key to search such a cache is an > absolute URI, and not a relative URI reference (firstly because that would > require to store the base URI as well, and secondly for efficiency reasons > because the same resource may be targeted by two different relative URI > references). No way to implement this simple cache for the time being > without tweaking the key to something different from a simple absolute URI! > > > The widget scheme spec correctly references section 5 of the URI spec as the > first step to take to map a URI to a widget resource. It doesn't need to and > should not be fixed! > > > I don't object should the WG decide to keep the processing rules as they > stand. I am satisfied that it carefully reviewed my arguments. > I'm still unsure if something is broken here or not. It seems that "technically" it is ok, but conceptually it is broken. -- Marcos Caceres http://datadriven.com.au
Received on Monday, 6 July 2009 16:37:05 UTC