- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 19 Mar 2009 15:24:58 +0100
- To: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>
- Cc: public-webapps@w3.org
On Thu, Mar 19, 2009 at 1:15 PM, Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com> wrote: > Hi Marcos, All, > > I would like to raise a comment in support of making the configuration > document at the root of the widget mandatory. > > The localisation model currently described by [1] allows for multiple > configuration documents; zero or one at the root of the widget and zero or > one at the root of each locales folder. > > While we support the approach of allowing localisation of the configuration > document (with the addition of the fallback mechanism that has been > previously discussed), one concern we had with such an approach was that it > doesn't make sense to localise some of the information in the > configuration document, for example: the feature element, (the replacement > for) the access element, the license element, the id and version attributes > (and maybe others?). In fact in some cases, allowing different values > could present security risks. > > Previously we (Vodafone) had considered an approach of requiring user agents > to, for example, create a list of all feature elements present in any valid > configuration document. We had not yet thought how to handle the case in > which the different configuration documents contain different id attribute > values. > > However, now that there is a proposal to make the configuration document at > the root of the widget mandatory, I would like to propose that a better > (although not pretty) solution would be specify which attributes and > elements are localisable. The non-localisable attributes / elements would > only be valid if included in the configuration document at the root of the > widget. > > Thoughts? Proposal: not localizable: <widget>'s id and version attributes. <feature> and its <options> <access> The following elements would be localizable: widget (but no id or version, derived from root config, if available) name description author license icon content preference screenshot FWIW, I think this will confuse authors... and irritate the poor souls who need to implement this :) Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Thursday, 19 March 2009 14:25:40 UTC