Hi,
Oops, it looks like I have a few more points to make on path resolution.
These comments apply to the editor's draft 11 June 2009 version of the
Widgets 1.0: Packaging and Configuration specification.
Comments apply to the "Rule for finding a file within a widget package"
section in 9.1 Processing rules:
http://dev.w3.org/2006/waf/widgets/#rule-for-finding-a-file-within-a-widget-
Comment 1 is minor.
Comment 2 is more important in my view.
Comment 3 is not a big deal, although I think the spec introduces
complexity where it's not needed.
Comment 1: relative can't be absolute
-----
Step 3: "meaning that the path is an Zip absolute path"
How can path be a Zip absolute path? It is defined in step 1 as the "Zip
relative path to the file entry being sought". A zip relative path
cannot start with a "/".
Updating to definition of "path" to the "valid path to the file entry
being sought" should solve the problem (valid path = zip-rel-path |
zip-abs-path)
Comment 2: links resolution in e.g. start file
-----
The specification implies but does not define how links in documents
other than the configuration document are to be handled (or did I miss
something?). In particular, how is a user agent supposed to resolve
relative links to packaged files that appear in the start file?
If the "rule for finding a file within a widget package" is to be
followed, the behavior is going to be "strange" in some cases. Consider
the case of a configuration document whose start file is defined as:
/startfolder/index.html
If index.html then uses relative paths to include an image, e.g.
"bar.gif", I would expect the user agent to behave as a regular Web
browser, and resolve "bar.gif" in the same folder as "index.html", i.e.
"/startfolder/bar.gif". Leaving localization aside for a second, step 5
of the rule for finding a file within a widget package will be reached,
and that means "bar.gif" will actually be searched "at the *root* of the
widget package", and not in "/startfolder". That's weird.
I think you should explain how to construct the Zip "valid path" of a
file entry from a relative path that may appear in a document and the
path of the document in question, i.e. from "bar.gif" to
"/startfolder/index.html" in the previous example.
Comment 3: localization and absolute URIs
-----
We more or less already exchanged emails on that, but... I don't
understand the need to have absolute paths bypass localization.
Consider the two examples below:
1. a config document that contains a <content
src="startfolder/index.html" /> directive
2. a config document that contains a <content
src="/startfolder/index.html" /> directive
I think people are used to using relative and absolute paths in links
interchangeably. Since the config document is at the root of the widget,
I would expect the two examples to have the same effect. Here, if the
widget's package contains a locales/fr/index.html, it may be used in the
first case (provided "fr" is in user agent locales of course), but it
won't ever be used in the second case.
I realize that when an absolute path is treated the same way as a
relative path, the "Complex example" of 8.4 Localization Examples:
http://dev.w3.org/2006/waf/widgets/#complex-example
... cannot be implemented as such in practice. I think that's fine,
there should not be any way for something in a "locales/[LANG]" folder
(or wherever else for that matter) to bypass the localization algorithm.
Having one complicates things more than anything else, IMHO.
Francois.
