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

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.

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


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

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

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

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.

Thanks,
Francois.

Received on Monday, 6 July 2009 16:02:35 UTC