RE: Comments to Widgets 1.0 Requirements Last Call WD

Hi Jo,
Adding a little to this thread, we should send them specific text if
possible. They have asked for any level of input so I would not be
concerned just due to the last call status. But of course we should be
flexible coming in with comments at this point.

On (a), we could say:
"As web applications, widgets that are used in mobile devices should
behave well as *mobile* web applications. The Mobile Web Application
Best Practices addresses key issues for web applications running in
mobile devices, e.g. usability, interoperability, and resource
efficiency. Widget specifications should take into consideration the
recommendations in the Mobile Web Application Best Practices, and where
possible provide enabling capabilities so that widgets can more
consistently comply with the recommendations."

On (b), that was specifically the point of the Accept, UAProf, and User
Agent header recommendations. Using existing, specific means is better I
think than leaving it more fuzzy and potentially having the widget spec
developers come up with some new way of spelling this out.

On (c), I specifically wrote that in a fuzzy way because I believe there
is no semantic way yet (I'm not aware of one) to express such resource
requirements, e.g. at least similar to what we have with *capabilities*
in Accept/UAProf and the new DDR/DCO. I think though that the sense of
your proposal is slightly different and I think also useful, i.e. that
the widget should have a way to express what device
resources/capabilities are important for its operation. The most direct
way to represent that may be through an API requirement manifest,
something that describes physical resources using the same vocabulary
the DDWG has developed, and things which the UWA DCO will define.

On (f), as the primary example of a semantically useful capabilities
expression mechanism that is defined today, at least for mobile devices,
I believe UAProf is essential to reference directly. We need WebApps to
think in the direction of semantic capabilities expression; if it takes
an evolved path with the UWA DCO/DDR then great, but the statically
defined UAProf will still be an important component in the overall
device capabilities management landscape, for the forseeable future. So
we should ensure it is considered in widget specifications, especially
for the mobile context.

I can always provide my comments directly to WebApps (I will do so for
some), but it would be good for the BPWG, representing the MWI, to add
emphasis to the message that there is value in widget support of
mobile-focused technologies in support of existing best practices.
UAProf is one such technology.

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: Jo Rabin [mailto:jrabin@mtld.mobi] 
Sent: Sunday, July 20, 2008 3:08 AM
To: Sullivan, Bryan
Cc: public-bpwg@w3.org
Subject: Re: Comments to Widgets 1.0 Requirements Last Call WD

Thanks for a comprehensive review, Bryan.


My comments on the spec and on Bryan's comments are:

a. to note the similarity in use cases between mobile Web browsing and
Widgets (in that they are usually targetted, action oriented etc.) and
to suggest some reference to the work of the BPWG on Best Practices to
see what's translatable - especially for example - the text in BP2 about
backing off requests etc. at periods of low activity.

b. something about how resources (media etc) need to be compatible with
target device types and that resource dependencies need to be spelled
out, somehow, somewhere.

c. Something about what resources (screen, input device, network,
processing, etc.) are needed for effective operation - similar to
Bryan's R.21 I think

d. 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, though
might be covered under c. above.

e. Something about intermittently connected widgets?

f. I don't think that we should ask for inclusion of reference to UAPROF
as suggested below. Other than that I agree with the general thrust of
the comments - but I think we should remember that the document is at
last call, so perhaps we should stop short of offering "proposed text".


Jo

On 18/07/2008 22:53, Sullivan, Bryan wrote:
> 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
>

Received on Thursday, 31 July 2008 12:37:06 UTC