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

Re: http://dev.w3.org/2006/waf/widgets/#the-feature-element

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Fri, 13 Feb 2009 00:06:34 +1000
Message-ID: <b21a10670902120606n2951e1bdu12b5cae6f8123ac9@mail.gmail.com>
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.


> 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

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"/>

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"/>

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"

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"

> 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 Caceres
Received on Thursday, 12 February 2009 14:07:15 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:14 UTC