Re: [widgets] feature: inconsistent behavior ?

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