- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Wed, 18 Jun 2008 15:21:56 +1000
- To: "public-webapps@w3.org" <public-webapps@w3.org>
In preparation for LC, I've updated the widgets requirements document. I did a small editorial cleanup, and, to reflect the work Arve and I did on the API spec, I've added the following requirements: R28. Network State Change Events A conforming specification must specify a means that allows authors to check if the widget resource is connected to Web. A conforming specification must also specify a mans by which connection and disconnection events can be captured by an author through script. Motivation: Current development practice or industry best-practices, ease of use. Rational: To allow authors to programmatically capture when a the widget user agent has got or lost a connection to the Web. R30. Device Specific APIs and Services A conforming specification should specify a mechanism, either through an API or through the configuration document, that allows instantiated widgets to bind to third-party APIs that allow access to device-specific resources and services. A conforming specification is not required to specify any APIs to device specific resources or services, but shouldprovide some means of binding to those APIs if they are available. Motivation: Current development practice or industry best-practices, ease of use. Rational: To endow widgets with functionality beyond what is currently available to HTML documents, allowing widgets to be used as means to bridge special device capabilities and operating system services with data on the Web. Examples of device-specific services and resources that could be made available through script include cameras, SMS, and the address book. There are other WGs working on this requirements such as the Ubiquitous Web Applications Working Group (UWA-WG), and the Open Mobile Alliance (OMA) Device Capabilities Working Group. R34. Icon API A conforming specification SHOULD specify a means that allows authors to control the iconic representation of a widget resource at runtime. Motivation: Current development practice or industry best-practices. Rational: To allow widget to communicate events and state changes to the user in contexts outside the running widget. For instance, for a weather widget, an icon could change to reflect the current weather conditions. R35. Configuration Document Data A conforming specification SHOULD specify a means that allows authors to access any relevant data they declared in the configuration document for the widget resource. Motivation: Current development practice or industry best-practices. Rational: To allow authors to easily access metadata they declared in the configuration document at runtime. R36. Open Default System Web Browser A conforming specification SHOULD specify a means that allows authors to open URLs in a browsing contexts outside the widget engine. Motivation: Current development practice or industry best-practices. Rational: To allow author to open a URL in the default system web browser. For example, in an news aggregator widget, to allow the end user to navigate to the source of a particular news item. -- Marcos Caceres http://datadriven.com.au http://standardssuck.org
Received on Wednesday, 18 June 2008 05:22:35 UTC