[Widgets] - Requirements Working Draft 23 June 2008 Review

Marcos,
Here are my comments on the Requirements (W3C Working Draft 23 June 2008)


> 1. Introduction
> [...] This document does not address the requirements of "web widgets", such
as iGoogle Gadgets or Windows Live Gadgets.
I Think we can add a wording at the end of the sentense to read: ³...,
although this version of the widget specification, the Working group will
address the web widget in the next iteration of the widgets specifications.²

> 3. Design Goals
> Longevity: ...
I think in this chapter we should talk about the versioning of a widget. I¹m
not sure it should be presented as a specific item, or if it can be added
inside the logevity section in relation to the longevity of the content
provided and related updates it will need over time.

> R7. Internationalization Guidelines
> Rationale: [...] (e.g. 'resources/en/' for all English content,
'resources/en-au/' for further localized Australian-English content, and so on).
Insert an ³and² in between the 2 english example to stress the need to allow
both

>R15 & R16
Is there a reason why they should not be ³must² instead of ³should²?

> R19. Iconic Representations
> Rationale: [...] For example, an a small graphic of a calendar may represent a
calendar widget.
³an a² should be corrected
But I propose to add the following after: ³And a small graphic of today¹s
calendar page may also represent this same calendar widget²

> R27. Widget State Change Events
This requirement must be available both ways, you should be able to capture
the change of state when it happens, but you should also be able as an
author to force the state change as well. I propose the following text:
³A conforming specification must also allow the author to programmatically
change the state of the widget to allow a change in the view of the
instantiated widget.²

> R28. Network State Change Events
In the specific case of a network drop, the author will need to know when
the network works again, in order to not have to code a checking loop, it is
important to put together a mechanisme whereby it¹s the widget engine that
wakes up the widget when the network is back on.
What do you think?

> R29. Modal Priority
> [...] (or any of its windows) should to categorize itself
³should to...² should be corrected

> 4.5 User Agents
> R39. End-user Declared Proxy
> A conforming specification should recommend that widget user agents allow
end-users to explicitly input a proxy server through which all HTTP-based
request are made.
This requirement should include at the end ³, or in case of availability,
that the system wide proxy is used.²
This requirement should be a ³Must²

>R40. Automatic Updates
This requirement should be a ³Must²

>R41. Persistent Storage of Preferences
>   A conforming specification must recommend that a widget user agent implement
a means to persistently store user preferences for each instantiated widget.
The following should be added after the first sentence: ³This Storage
mechanism must allow to keep the preferences after restart of the widget or
on the restart of the user agent.

> Rationale: To allow widgets to be closed and re-instantiated without the
end-user having reset the preferences for an instantiated widget. For example,
when using a weather widget, the end-user will want to store the preferred
location for weather information, and not be asked to input that information
again every time the widget is re-instantiated.
And again at the end of this sentence: ³The same would apply if the user has
setup 2 instances of the same widget and would like to view 2 different
cities. After closing the widgets, open 2 instances of this weather widget
would automatically pick up the 2 pre-set cities.

> R41 and R42
I would switch them arround so that the notion of the multiple instance can
be used in the Preference Storage Requirement.

> R44. Runtime Security Exceptions
A conforming specification must specify runtime exceptions for when the API
attempts to perform an action it it not authorized to perform.
Correct ³it it²


Best Regards, Benoit


> 
> Benoit  Suzanne
> Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM
> t. +33 (0)145 298  198 - m. +33 (0)680 287 553
> benoit.suzanne@orange-ftgroup.com
> 
 



> 
> Benoit  Suzanne
> Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM
> t. +33 (0)145 298  198 - m. +33 (0)680 287 553
> benoit.suzanne@orange-ftgroup.com
>