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

Hi Marcos,

Marcos Caceres wrote:
> Hi Francois,
> On Mon, Jul 6, 2009 at 6:01 PM, Francois Daoust<fd@w3.org> 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.

Received on Monday, 6 July 2009 20:58:21 UTC