Hi All,
Here is a summary of the new <feature> element (and some associated
APIs) that we added to the widget Configuration Document at the Turin
F2F (replaces the <requires> element).
When combined with digital signatures, the <feature> element acts as a
secure device capability discovery mechanism and a API binding
mechanism (in effect, it hopefully simplifies what DCCI tries to
achieve without all the burden of ontologies and treating everything
as DOM nodes, etc).
<widget ...>
<access>
<feature [required="yes/no"]
id="uri"
name="localname"/>
</access>
</widget>
The attributes are as follows:
id:
the URI that identifies the feature (eg. "urn:org.w3.www.someAPI" or
"http://www.w3.org/api/device/camera/").
required:
if the feature is mandatory for this widget to work properly. If a
feature is not available, the widget will not run.
name:
a developer friendly shorthand that a developer can use to call up
the API in JavaScript (eg. getFeature("Phone GPS")). The intent is to
hide nasty URIs from developers and giving them some simple syntactic
sugar instead. For example:
<widget ...>
<access>
<feature id="http://w3.org/api/device/camera"
name="camera"/>
</access>
</widget>
Then, at runtime, we introduce the following API:
Widget.features; // a list of the declared features that were available.
Widget.getFeature("name of feature"); //the "name" of a feature as
declared in the <feature> element
Usage example:
In the start file:
<!doctype html>
<script>
if(Widget.getFeature("camera")){
camera = Widget.getFeature("camera");
camera.powerOn(...some call back...);
camera.takePicture(...some other call back...);
}
</script>
The <feature> element allows for fallback, so that if one feature is
not available, another may be used in its place. Eg. load proprietary
API for camera and if it fails, load the W3C one:
<widget name="sportPhotoWidget">
<access>
<feature id="http://cannon.com/api/device/camera?shutterspeed=1000"
name="Cannon camera">
<feature id="http://w3.org/api/device/camera"
name="generic camera" required="true"/>
</feature>
</access>
</widget>
With this proposal, we make a leap of faith in that we want future
APIs standardized by the W3C to be identifiable via a URI (the same
leap of faith that seems to DCCI make). I guess we need to encourage
the TAG to support this practice and hope that we can convince the
GeoLocation guys to add a URI to their spec.
thoughts, comments, etc....
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au