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

Hi Francois,

On Sun, Jun 14, 2009 at 7:47 PM, Francois Daoust<fd@w3.org> wrote:
> 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)

Fixed. Used your text.

>
> 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?

You are absolutely right. However, the WG decided that URI resolution
is out of scope for the P&C specification so we only recently
published Widgets 1.0: URI Scheme specification:
http://dev.w3.org/2006/waf/widgets-uri/

To make sure that it is clear that the P&C spec will not be handling
URIs outside the scope of the config.xml, I've added the following
note to the spec:

"Note: This specification does not define how links in documents other
than the configuration document are to be dereferenced. For handling
links in other documents, such as (X)HTML, CSS, SVG, ect., please
refer to the [Widgets URI] specification."

Is the above text sufficient?

> 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.

As above, this will be handled by a different spec.

> 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.

I agree, but this will all be handled by the widgets URI specification.

>
>
> 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.

I guess the logic is that authors, for whatever reason (e.g., force
testing a locale without needing to change the locale on their
device), are going to use absolute URIs, so I'm of the opinion that we
support them.

> 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.

Yes, they would have the same effect iff the folder structure was:

widget.wgt
  /startfolder/

But, for whatever reason, the folder structure was as follows, it
would also work:

widget.wgt
  startfolder/index.html
  fr/startfolder/index.html
  jp/startfolder/index.html

> 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.

Yes, for case 1, so long as:

widget.wgt
  fr/startfolder/index.html

And yes, it will not be matched in case 2... which is what I would expect.

> 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.

I personally don't agree (I personally like the way it works right now
and seem consistent with the way I would expect absolute paths to
work). However, I think I will defer this to the working group for a
resolution; others may agree with your position or I might not be
understanding your proposal.

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 1 July 2009 12:16:17 UTC