W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

RE: [widgets] Further argument for making config.xml mandatory

From: Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>
Date: Thu, 19 Mar 2009 15:54:27 +0100
Message-ID: <0BE18111593D8A419BE79891F6C4690902B1CC9B@EITO-MBX01.internal.vodafone.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT