- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Fri, 13 Feb 2009 00:06:34 +1000
- To: Kai Hendry <hendry@aplix.co.jp>
- Cc: public-webapps <public-webapps@w3.org>
HI Kai 2009/2/7 Kai Hendry <hendry@aplix.co.jp>: > > Currently a widget developer declaring the dependency on a feature > might simply write: > > <feature name="http://bondi.omtp.org/api.geolocation"> > > Since the required attribute will be unset and as a > http://dev.w3.org/2006/waf/widgets/#boolean-attribute it will default > to false. Correct. > So the unwitting developer effectively specified an optional > dependency for his widget, which is not expected default. I'm ok to be cautious about this. I guess if you declare it, you want it. > So I would like to propose something syntax like: > <feature name="http://www.w3.org/geo/api/" optional="true" /> > > In the rare case where the widget developer has accounted for the > possibility the feature might not be available. > > And simply specifying <feature name="http://www.w3.org/geo/api/" /> > would make that named feature a mandatory requirement for the widget > to function. Understood, but I personally don't agree we should change it in the way you recommend. How about this instead: a <feature> that is a parent of another feature is optional (unless marked as required), and the last child in a chain is required unless explicitly marked as optional. A <feature> on its own is required. Consider the following examples. This <feature> is required: <feature name="I have no children, so I am required"/> This feature is optional: <feature name="I have been made explicitly optional" required="false"/> The first feature is optional, the second is required: <feature name="i am optional"> <feature name="i am required, as I am the last in the chain"/> </feature> Likewise, the first and second features are optional and the last is required: <feature name="i am optional"> <feature name="I am also optional"> <feature name="i am required, as I am the last in the chain"/> </feature> </feature> This feature is marked as not required, hence overriding the default: <feature name="I was required, but now I'm not" required="false"/> The following makes the whole chain optional: <feature name="I not required"> <feature name="not required"> <feature name="I serve no purpose, as my parent is required" required="false"/> </feature> </feature> The following is a bit weird because the first is required, which makes the fallback useless (but that is ok): <feature name="I was not required, but now I am" required="true"> <feature name="I serve no purpose, as my parent is required" required="false"/> </feature> > If the feature is unavailable, the widget run time should decline to > install the widget. What the UA does with a widget that it cannot run should be left as an implementation detail (e.g., delete it; store it for later in case the feature becomes available in the future, etc.). A more detailed example might be using a mp3 to radio API, but that feature might only be available when the radio tuner accessory is plugged into the phone. What do you think? If you, and the group, likes the proposal, I will add it to the spec along with the examples. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Thursday, 12 February 2009 14:07:15 UTC