W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

[widgets] Comments on Widgets 1.0: Packaging and configuration, 9.1 Processing rules

From: Francois Daoust <fd@w3.org>
Date: Sun, 14 Jun 2009 19:47:23 +0200
Message-ID: <4A3537AB.2000700@w3.org>
To: public-webapps@w3.org
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.
Received on Sunday, 14 June 2009 17:47:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT