Comments to Widgets 1.0 Requirements Last Call WD

Hi all,

Here are my comments to the Widgets 1.0 Requirements Last Call WD. (http://www.w3.org/TR/widgets-reqs/)

It took me some time to follow up on the action item to inititate this discussion, but after a thorough review, here are the key points that I would make at this time re the significance of the widget requirements to the mobile widget environment. They are looking for feedback before Aug 1, so if anyone has further comments, they should be sent soon.

Similar to "R21. Security Declarations", the following requirement should be added:
R21. Resource Declarations
A conforming specification must specify a means for declaring that the instantiated widget will have an impact on sensitive device or network resources, which may impact device performance or the user experience.
Motivation:
Security <http://www.w3.org/TR/widgets-reqs/> , current development practice or industry best-practices <http://www.w3.org/TR/widgets-reqs/> .
Rationale:
		To declare the resource requirements of the widget, allowing the widget user agent to respond accordingly by adjusting its resource policies and warning the end-user. Example of resource sensitive services that could require notification are automated operation involving network access or screen display, which can impact overall service cost and device battery life; or persistent storage requirements, which can affect device performance and reliability of the environment for other applications.

Re "R36. Open Default System Web Browser", I propose a modification (in red/underline below)
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 <http://www.w3.org/TR/widgets-reqs/> .
Rationale:
		To allow author to open a URL in the default system web browser. For example, in a news aggregator widget, to allow the end user to navigate to the source of a particular news item. Alternatively, if the widget has ability to directly present web content, a specific resource may exceed its capabilities, thus the user can be offered the option of opening the resource in the default system web browser, which may have greater capabilities.


These requirements should be added in 4.5 User Agents:

Rxx. User-Agent Header

A conforming specification must specify that the widget must identify itself in HTTP requests through the  user-agent header, either as the complete header or as an extension to the default user-agent header provided by the runtime environment.

Motivation:
Current development practice or industry best-practices <http://www.w3.org/TR/widgets-reqs/> , interoperability <http://www.w3.org/TR/widgets-reqs/> .
Rationale:
		To provide the ability for web servers to determine if it is possible to serve the widget, or to adapt to the capabilities or special requirements of the widget. For example, a widget may attempt to access a service which is not compatible with the widget, and rather than provide a possibly incorrect response (which could cause further issues with the widget), the web server can provide a specific error response noting the incompatibility.


Rxx. User-Agent Profile Header

A conforming specification must specify that the widget should identify its capabilities in HTTP requests through the Profile header as described by [CCPPexchange] (http://www.w3.org/TR/NOTE-CCPPexchange).

Motivation:
Current development practice or industry best-practices <http://www.w3.org/TR/widgets-reqs/> , interoperability <http://www.w3.org/TR/widgets-reqs/> .
Rationale:
		To provide the ability for web servers to determine if it is possible to serve the widget, or to adapt to the capabilities or special requirements of the widget, using semantic methods based upon detailed capabilities information provided by the widget.

Rxx. Accept Header

A conforming specification must specify that if a Profile header is not included in HTTP requests, the widget must include all supported MIME types for widget resources in the Accept header.
 
Motivation:
Current development practice or industry best-practices <http://www.w3.org/TR/widgets-reqs/> , interoperability <http://www.w3.org/TR/widgets-reqs/> .
Rationale:
		To provide the ability for web servers to determine if it is possible to serve the widget, or to adapt to the capabilities or special requirements of the widget, using semantic methods based upon detailed capabilities information provided by the widget.

Rxx. Default Use of Runtime Environment Configured Proxy

A conforming specification must specify that by default, widget HTTP requests must be made through the proxy server (if any) configured for use in HTTP requests issued through the runtime environment or host device.
 
Motivation:
Security <http://www.w3.org/TR/widgets-reqs/> , current development practice or industry best-practices <http://www.w3.org/TR/widgets-reqs/> , Web and offline distribution <http://www.w3.org/TR/widgets-reqs/> , interoperability <http://www.w3.org/TR/widgets-reqs/> .
Rationale:
		To ensure that widgets can be served in environments for which an HTTP proxy is required to be used, or be given value-added services available only through the HTTP proxy. For example, the runtime environment may be pre-configured to offer proxy services for all HTTP clients. Unless the widget has special requirements for use of a different proxy, the default proxy configuration should be used.


Bryan Sullivan | AT&T