- From: Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>
- Date: Thu, 19 Mar 2009 15:54:27 +0100
- To: <marcosc@opera.com>
- Cc: <public-webapps@w3.org>
>FWIW, I think this will confuse authors... and irritate the >poor souls who need to implement this :) Other suggestions are of course welcome! One alternative would be to separate out the non-localisable data into a separate document, eg manifest.xml... But this is also likely to irritate implementers :( >-----Original Message----- >From: marcosscaceres@gmail.com >[mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres >Sent: 19 March 2009 14:25 >To: Priestley, Mark, VF-Group >Cc: public-webapps@w3.org >Subject: Re: [widgets] Further argument for making config.xml mandatory > >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 15:00:10 UTC