- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 7 Jan 2010 16:37:14 +0100
- To: cyril.concolato@telecom-paristech.fr
- Cc: Scott Wilson <scott.bradley.wilson@gmail.com>, public-webapps <public-webapps@w3.org>
On Thu, Jan 7, 2010 at 4:10 PM, Cyril Concolato <cyril.concolato@enst.fr> wrote: > 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. Don't worry about Robin, I'll personally make sure he stays well away from any future versions of the spec :) But seriously, I think URIs have proven themselves to be pretty robust and usable; they also provide (fairly) well-understood structured semantics, which some implementers may find useful - hence the reason we chose them for the name instead using a opaque string or something else. Also, we have not tied naming to any particular URI scheme, which also gives a great deal of flexibility. -- Marcos Caceres http://datadriven.com.au
Received on Thursday, 7 January 2010 15:38:11 UTC