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

Re: [widgets] feature: inconsistent behavior ?

From: Cyril Concolato <cyril.concolato@enst.fr>
Date: Wed, 06 Jan 2010 11:08:57 +0100
Message-ID: <4B446139.1090101@enst.fr>
To: marcosc@opera.com
CC: public-webapps <public-webapps@w3.org>
Marcos,

Le 06/01/2010 10:52, Marcos Caceres a écrit :
> On Wednesday, January 6, 2010, Cyril Concolato<cyril.concolato@enst.fr>  wrote:
>> Le 05/01/2010 23:54, Marcos Caceres a écrit :
>>
>> On Wed, Dec 16, 2009 at 10:13 AM, Cyril Concolato
>> <cyril.concolato@enst.fr>    wrote:
>>
>> Hi,
>>
>> The test df.wgt contains a feature without name. In this case, the feature
>> element is ignored and the widget remains valid.
>> The test d4.wgt contains an invalid feature name. In this case, the widget
>> should be considered as invalid. I don't understand that. I understand the
>> rationale that if a feature is required, the UA shall not process the
>> widget. Whether it does or not understand the feature, it doesn't matter. Is
>> it because you foresee evolution in the syntax of feature names, which
>> wouldn't be IRI ? If not, I suggest to make this test pass and ignore the
>> feature element.
>>
>>
>>
>> Sorry, but it was a resolution that all correctly named features are
>> considered required (it's why we had to create the required
>> attribute). I'm against changing this.
>>
>> It's not because "all correctly named features are considered required" (on which I agree) that "invalid feature names must lead to invalid widgets" (on which I disagree). I think invalid feature names should be ignored.
>>
>
> But they (the invalid feature) are "required" by default (required
> value defaults to true), hence the widget would probably crash or be
> rendered useless at runtime regardless. Consider:
>
> <feature name='foo:bar'/>
>
> which manifests itself as 'window.theMightyFoo' at runtime, iff the
> feature is available. The author, having implicitly said in the config
> doc "feature foo:bar must be there for my widget to work" will have to
> now write additional error handling code to check if the feature is
> available. This would be fine if the author said:
>
> <feature name='foo:bar' required='false'/>
>
> in which case, the author has made an explicit statement that he or
> she has (hopefully) coded the widget on the premise that the feature
> may not be there at runtime.

I think you misunderstood me.

There is a difference between an 'unsupported'/'unavailable' feature as 'foo:bar' in your example and an 'invalid feature name' as in the test-suite example:

<widget>
<name>d4</name>
<feature name="invalid feature IRI" required="true"/>
</widget>

I'm not asking that 'unsupported'/'unavailable' features are ignored as indeed this would contradict the default value of 'required'. I'm asking that 'invalid' feature are ignored (whether they are required or not). This would be consistent with the rest of the spec.

Cyril

-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.blog.telecom-paristech.fr/
Received on Wednesday, 6 January 2010 10:09:22 GMT

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