Hi Marcos,
Marcos Caceres wrote:
Hi Francois,
On Mon, Jul 6, 2009 at 6:01 PM, Francois Daoust<[email protected]> 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.
Yes. I didn't manage to extract anything more concrete from the spec :(
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.
My point is that the i18n thing should only see absolute URIs, the same
way an HTTP server only sees requests for absolute URIs and is unaware
of the way the URI was initially written.
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".
I don't think the mapping from a relative to an absolute URI should
depend on the delivery context. The same rules should yield the same
absolute URI no matter the user's locale, IMO.
OR, it could "silently" map to:
"/about.html" = "widget:///about.html" = (but resource served was
"/locales/en/index.html").
I'd have nothing against that, except that if you have in the same
config file a link to "about.html" and a link to "/about.html", you'll
get the same absolute URI, but the result of the mapping would be
different. But then that is not such a big deal for config files as
there is no real reasons for this file to contain two links to the same
resource...
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.
Just to be clear, I think the only modification that may be needed to
the widgets packaging spec is to replace the whole bullet point that
starts with: "If the path starts with a U+002F SOLIDUS" in current
section 10.1.3 by:
[[ 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 leading U+002F SOLIDUS ("/") from path. ]]
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.
Yes. Technically, the processing rules work fine.
Conceptually, I find it strange to have the same absolute URI return
different representations based on the way the URI was initially written.
Francois.
