- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Tue, 9 Sep 2008 21:44:10 +0100
- To: "Web Applications Working Group WG" <public-webapps@w3.org>
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
Received on Tuesday, 9 September 2008 20:44:59 UTC