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

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

From: Marcos Caceres <marcosc@opera.com>
Date: Thu, 19 Mar 2009 07:34:27 +0100
Message-ID: <b21a10670903182334q5504af78r5062e2c20b53e6ae@mail.gmail.com>
To: Robin Berjon <robin@berjon.com>
Cc: Arve Bersvendsen <arveb@opera.com>, public-webapps WG <public-webapps@w3.org>
On Thu, Mar 19, 2009 at 7:27 AM, Robin Berjon <robin@berjon.com> wrote:
> 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).

Will fix required. Required denotes if a feature is absolutely needed
for the widget to function (i.e., without this feature, the widget
serves no purpose.)

-- 
Marcos Caceres
http://datadriven.com.au
Received on Thursday, 19 March 2009 06:35:14 GMT

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