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

Re: [widgets] <option>s on <feature>s

From: Robin Berjon <robin@berjon.com>
Date: Thu, 19 Mar 2009 07:27:52 +0100
Cc: "public-webapps WG" <public-webapps@w3.org>
Message-Id: <561E6C05-FBF5-49CB-8780-C2C72AF6398D@berjon.com>
To: Arve Bersvendsen <arveb@opera.com>
On Mar 18, 2009, at 23:29 , Arve Bersvendsen wrote:
> On Wed, 18 Mar 2009 23:22:54 +0100, Robin Berjon <robin@berjon.com>  
> wrote:
>> I see a limited use case for the sort of example you propose, but  
>> I'm nevertheless going to push back against it. One reason is that  
>> it can already be described with features, to witness:
>>
>> <feature name="url_describing_filesystem_api/music/read"/>
>
> Getting in to the edge cases here: What if I have an application  
> where falling back to read access is acceptable, if write fails (In  
> other words, failure to adhere to some option is not fatal)?

What you describe seems to be:

<feature name="url_describing_filesystem_api/music/write">
   <feature name="url_describing_filesystem_api/music/read"/>
</feature>

but I don't think that's what you mean. I believe you mean that the  
author wants read, and optional write:

<feature name="url_describing_filesystem_api/music/read"/>
<feature name="url_describing_filesystem_api/music/write"  
required='false'/>

(The spec needs clarification on @require, but the feature  no pun  
intended  is there).

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Thursday, 19 March 2009 06:28:31 GMT

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