RE: Request for Comments on Widgets 1.0 Requirements Last Call WD

[Sullivan, Bryan]

Hi Art,
The MWBP WG consolidated comments are attached as a HTML document.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ] On Behalf Of Arthur Barstow
Sent: Thursday, July 31, 2008 5:25 AM
To: [EMAIL PROTECTED]
Cc: ext Marcos Caceres
Subject: Fwd: Request for Comments on Widgets 1.0 Requirements Last Call
WD


This is a reminder August 1 is the end of the comment period for the
Widgets 1.0 Requirements Last Call Working Draft.

-Regards, Art Barstow


Begin forwarded message:

> From: Arthur Barstow <[EMAIL PROTECTED]>
> Date: June 26, 2008 4:46:23 PM EDT
> To: [EMAIL PROTECTED]
> Cc: Marcos Caceres <[EMAIL PROTECTED]>
> Subject: Request for Comments on Widgets 1.0 Requirements Last Call WD
>
> Dan, Jo, MWBP WG,
>
> On June 25 the Web Applications WG published a Last Call Working Draft
> of the Widgets 1.0 Requirements document:
>
> [[
> <http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/
<http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/> >
> Abstract: This document lists the design goals and requirements that a
> specification would need to address in order to standardize various
> aspects of widgets. Widgets are small client-side Web applications for
> displaying and updating remote data, that are packaged in a way to
> allow download and installation on a client machine, mobile phone, or
> mobile Internet device. Typical examples of widgets include clocks,
> CPU gauges, sticky notes, battery-life indicators, games, and those
> that make use of Web services, like weather forecasters, news readers,
> email checkers, photo albums and currency converters.
>
> Introduction: A widget is an interactive single purpose application
> for displaying and/or updating local data or data on the Web, packaged
> in a way to allow a single download and installation on a user's
> machine or mobile device. A widget may run as a stand alone
> application (meaning it can run outside of a Web browser), or may be
> embedded into a Web document. In this document, the runtime
> environment on which a widget is run is referred to as a widget user
> agent and a running widget is referred to as an instantiated widget.
> Prior to instantiation, a widget exists as a widget resource. For more
> information about widgets, see the Widget Landscape document.
> ]]
>
> We would appreciate any comments your WG has on this LC document,
> especially those requirements relevant to your WG's domain/scope.
> The comment period ends 1 August 2008.
>
> -Regards, Art Barstow
>

Title: MWBP comments to Widget Requirements Last Call WD

General comments:   Somewhere, perhaps in section 4.2, there should something about how resources (media etc) need to be compatible with the target device types, and that resource dependencies (screen, input device, network, processing, etc.) need to be spelled out. Widgets should be able to express these dependencies in a semantically useful way through a standardized schema and attribute ontologies/vocabularies such as W3C has been working on, e.g. the MWI DDWG’s DDR Core Vocabulary, DDR Simple API, and the ongoing work of the UWA’s Delivery Context Ontology. The specific text below related to _expression_ of user agent characteristics (via the User Agent, Accept, and Profile headers in HTTP requests) is important in the meantime as a standardized way to at least disclose web application (and host device) capabilities, but longer term a way of expressing dependencies is important also.   Re R16 Visual Rendering Dimensions: the text states that there must be a way of declaring initial dimensions in pixels, which is potentially at odds with the limited canvas available on many mobile devices. Resource/capability _expression_ as described above would at least ensure the dimensions were defined in a standardized way.   Other that described in “R28. Network State Change Events”, is there something specific that can be said re requirements supporting widgets that are intermittently connected?   Suggestions for specific text:   1) As design goals, a new section 3.1 can specifically introduce the mobile web best practices that W3C has developed / is developing. Here is some proposed text: 3.1 W3C Mobile Web Best Practices   Some typical use cases for widgets are similar to use cases for mobile Web browsing, and will benefit from consideration of objectives and constraints similar to the mobile environment, e.g. usability, interoperability, and resource efficiency. In particular, widgets that are used in mobile devices should behave well as mobile web applications,  i.e. as web applications running in mobile devices. For widgets in mobile devices or similar contexts, widget specifications should take into consideration the W3C recommendations in the Mobile Web Best Practices 1.0 and Mobile Web Application Best Practices, and where possible provide enabling capabilities so that widgets can more consistently comply with the recommendations.   2) Add the references:   MWBP Mobile Web Best Practices 1.0. J. Rabin, C. McCathieNevile, W3C Recommendation, July 2008. Available at http://www.w3.org/TR/mobile-bp/    MWABP Mobile Web Application Best Practices. B. Sullivan. A. Connors, W3C Working Draft (Recommendation), July 2008. Available at http://www.w3.org/TR/mwabp/     3) 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, current development practice or industry best-practices. 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.   3) Re "R36. Open Default System Web Browser", a proposed 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. 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.     3) In 4.5 User Agents, add the requirements:   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, interoperability. 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, interoperability. 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, interoperability. 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, current development practice or industry best-practices, Web and offline distribution, interoperability. 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.