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

I still think that more than one config document is the most confusing aspect of this. Having just one (mandatory) config document, with the localized parts tagged with xml:lang attributes would be the simplest. However, as I understand it, the separate config files were recommended by the W3C I18N group.

If this decision would be reversed, then anything in the config document that could (as per the schema) have an xml:lang attribute would by definition be localizable/localized. Others (like id, version etc.) would not be. That would also free the implementation from collecting all the various config documents, just to create and store an intersection of the elements. If you have two values for the same element, then who wins? The most specific (from the config in the localized folder), or the least specific (the default/fallback one from the root)?

Proposal (feel free to ignore, due to pressure to be feature complete): make the config file mandatory, but allow it only in the root, then allow multiple elements with unique xml:lang attributes for those elements that are localizable.

--Jere


On 19.3.2009 16.24, "ext Marcos Caceres" <marcosc@opera.com> wrote:

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