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

Re: [widgets] Base folder and resolution of relative paths

From: Francois Daoust <fd@w3.org>
Date: Tue, 19 May 2009 10:32:20 +0200
Message-ID: <4A126E94.3050107@w3.org>
To: Jere.Kapyaho@nokia.com
CC: marcosc@opera.com, public-webapps@w3.org
Hi Jere,

Here are a few +1.
I'm not sure I can be of any further help to be honest. You seem to have 
raised all the questions that needed to be raised, and weighed the 
benefits and drawbacks of various proposals accordingly, and I'm not an 
expert in that field.

Jere.Kapyaho@nokia.com wrote:
> Hi Francois,
> the idea of treating the widget package essentially as a local HTTP server
> in terms of resources is quite interesting, although like you said there
> will be differences. In terms of localized resources, it seems a good
> strategy to use the same mechanism as HTTP and Accept-Language to select
> localized resources. I donıt know if anyone has done it like this before in
> the context of an application; maybe not. But somehow I think we donıt go
> all the way to q values. (?)
> The most important concept here is really that the locale (or language tag,
> if you will) is specific to any given resource. That does have the risk of
> having partially localized applications, as you observed, but that is really
> the developerıs concern. They just need to make a concerted effort to
> localize all that is needed.


> Of course there will always be widgets that have nothing localized, so the
> mechanism must allow the fallback content to be found as the last step of
> the lookup. The drawback there is that if resources are always looked for
> according to the UA language list, it might be wasted effort (and a
> performance hit) for those widgets that donıt have anything localized. The
> search would go all the way from the deepest branch to the root in vain
> before finding the fallback content.

I don't think performance will be that impacted (parsing/rendering 
resources is probably times longer than looking up for resources) but 
that's correct.

> Iım thinking the widget locale (as derived from the UA language list) should
> be organized by primary subtag so that the most specific tag comes first,
> like so: ³en-us, en, fr-ca, fr-fr, fr². At least Marcos seemed to like this
> idea. That would simplify things by making the base folder essentially the
> first tag in the widget locale. (Or could this be folded to just "en-us,
> fr-ca, fr-fr"? Content negotiation should know to drop the subtags
> successively anyway.)

It looks good, but I don't feel I know enough on locale specificities to 
take any position. Up to you! ;)

> Assumptions/premises:
> - The content negotiation is applied only to widget: URIs (incidentally,
> would a relative URI inside widget content then always be considered a
> widget: URI?)

Not sure what you're referring to with "content negotiation", here. Why 
would content negotiation not be applied to external http: URIs? Widgets 
that communicate with an external server run by the company that 
produced the widget should be common. The same localization mechanism 
would probably be applied both in the widget and server-side.

> - When referring to content inside the widget package, the
> Olocales/some-language-tagı part is never included in the URI. Instead, the
> content negotiation mechanism should kick in and find the resource given
> just a relative URI like 'flag.png'.


> - If the content negotiation finds no localized content (i.e. there is no
> requested representation for the resource), a resource with the specified
> name in the root of the widget is used. If not present, it is probably an
> error.

+1 without the final "probably". If not present, it is an error.

> I'm trying to help Marcos hammer out these things in the P&C spec, so I
> really appreciate your feedback.

Good luck! :)

Received on Tuesday, 19 May 2009 08:33:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC