- From: Marcos Caceres <marcosc@opera.com>
- Date: Thu, 19 Mar 2009 07:34:27 +0100
- 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 UTC