W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

[widgets] Widgets Requirements LC

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Wed, 18 Jun 2008 15:24:51 +1000
Message-ID: <b21a10670806172224j40208edbo78d5cb54d4531060@mail.gmail.com>
To: "public-webapps@w3.org" <public-webapps@w3.org>

In preparation for LC, I've updated the widgets requirements document:

http://dev.w3.org/2006/waf/widgets-reqs/

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:25:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:26 GMT