- From: Cyril Concolato <cyril.concolato@enst.fr>
- Date: Thu, 07 Jan 2010 16:10:38 +0100
- To: Marcos Caceres <marcosc@opera.com>
- CC: Scott Wilson <scott.bradley.wilson@gmail.com>, public-webapps <public-webapps@w3.org>
Le 06/01/2010 20:46, Marcos Caceres a écrit : > On Wed, Jan 6, 2010 at 11:30 AM, Scott Wilson > <scott.bradley.wilson@gmail.com> wrote: >> >> On 6 Jan 2010, at 10:08, Cyril Concolato wrote: >>> >>> 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. >> >> >> If a feature is required by the widget, and it isn't available for any >> reason (including an invalid IRI) then its reasonable for the UA to assume >> this Widget just won't work and reject it. It may simply be a typo, e.g.: >> >> <feature name="http;//bondi.omtp.org/api/camera.capture" required="true"/> >> ^ typo! >> >> I don't think it would be useful for this to silently fail. >> > > FWIW, I agree with Scott. However, Cyril's point is valid in the the > behavior is a bit inconstant with the spec... but, as Scott has shown > through his example, it's with good reason. Now that I understand the rationale, I'm fine to leave it as is. It just means that the spec will not be extensible to features not named with IRI. I don't know if in Robin's v27 of the spec, there won't be a different way to name features. Regards, 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 Thursday, 7 January 2010 15:11:04 UTC