Re: [Widgets] - Requirements Working Draft 23 June 2008 Review
I agree with you comments, and I¹ve just added a feedback to the R27 discussion 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 [EMAIL PROTECTED] On Thu, Jul 31, 2008 at 6:00 AM, Marcos Caceres [EMAIL PROTECTED] wrote: Hi Benoit, Thank you for taking the time to prepare a detailed review. I think I was able to address all your comments, except for the one about R27. Widget State Change Events. It would be great if you could help clarify what you want me to do there. Please see below for detailed description of the changes I made. Please let me know if you are satisfied with the responses I've have given below or if you would like any further clarification. On Wed, Jul 30, 2008 at 8:52 AM, SUZANNE Benoit RD-SIRP-ISS [EMAIL PROTECTED] wrote: 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. Although I personally agree, I don't think we have reached a resolution as a working group about what features should be included in future versions of the Widgets specification. I don't want to prematurely commit us to feature which we may not end up implementing in the future. If anything, this should go into a Widgets 2.0 Requirements document. It might be good to prepare such a document once this one reaches CR. 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. I see what you are saying, but I think mentioning versioning is better served in the Web and offline distribution section. I've added the following text: A conforming specification needs to deal with cases where an end-user acquires a widget resource over HTTP or via some other non HTTP-based (offline) means, such as a local file system, Bluetooth or a Multimedia Message Service. In addition, a conforming specification needs to provide a means by which widgets can be updated when a new or different version of a widget becomes available. It must be possible to perform updates from either an online or offline source. 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 Done. R15 R16 Is there a reason why they should not be must instead of should? I've changed R15 to a must, as we have already spec'd the license element. We are still undecided about rendering dimensions (R16). R19. Iconic Representations Rationale: [...] For example, an a small graphic of a calendar may represent a calendar widget. an a should be corrected Fixed. But I propose to add the following after: And a small graphic of today's calendar page may also represent this same calendar widget I changed the text to read: For example, a small graphic of a calendar showing today's date may represent a calendar widget. This is to incorporate your suggested text and to imply that the graphic may change dynamically (in accordance with R34 - Icon API). 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. I'm not sure this is the right place for this. I think this should be in R24. Instantiated Widget API. However, I'm not sure that the proposed text covers the actual requirement. I wanted to put something like you suggested into R24: The API SHOULD also also allow authors to programmatically change the visual state of a widget, but I'm not sure what that means. Can you please provide an example or a use case? I agree that this technically, allowing a dev to change the widget state, falls under R24. But I wonder if this specific functionality should be stated. 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 mechanism whereby it's the widget engine that wakes
Re: [Widgets] - Requirements Working Draft 23 June 2008 Review
Hi Benoit, Thank you for taking the time to prepare a detailed review. I think I was able to address all your comments, except for the one about R27. Widget State Change Events. It would be great if you could help clarify what you want me to do there. Please see below for detailed description of the changes I made. Please let me know if you are satisfied with the responses I've have given below or if you would like any further clarification. On Wed, Jul 30, 2008 at 8:52 AM, SUZANNE Benoit RD-SIRP-ISS [EMAIL PROTECTED] wrote: 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. Although I personally agree, I don't think we have reached a resolution as a working group about what features should be included in future versions of the Widgets specification. I don't want to prematurely commit us to feature which we may not end up implementing in the future. If anything, this should go into a Widgets 2.0 Requirements document. It might be good to prepare such a document once this one reaches CR. 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. I see what you are saying, but I think mentioning versioning is better served in the Web and offline distribution section. I've added the following text: A conforming specification needs to deal with cases where an end-user acquires a widget resource over HTTP or via some other non HTTP-based (offline) means, such as a local file system, Bluetooth or a Multimedia Message Service. In addition, a conforming specification needs to provide a means by which widgets can be updated when a new or different version of a widget becomes available. It must be possible to perform updates from either an online or offline source. 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 Done. R15 R16 Is there a reason why they should not be must instead of should? I've changed R15 to a must, as we have already spec'd the license element. We are still undecided about rendering dimensions (R16). R19. Iconic Representations Rationale: [...] For example, an a small graphic of a calendar may represent a calendar widget. an a should be corrected Fixed. But I propose to add the following after: And a small graphic of today's calendar page may also represent this same calendar widget I changed the text to read: For example, a small graphic of a calendar showing today's date may represent a calendar widget. This is to incorporate your suggested text and to imply that the graphic may change dynamically (in accordance with R34 - Icon API). 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. I'm not sure this is the right place for this. I think this should be in R24. Instantiated Widget API. However, I'm not sure that the proposed text covers the actual requirement. I wanted to put something like you suggested into R24: The API SHOULD also also allow authors to programmatically change the visual state of a widget, but I'm not sure what that means. Can you please provide an example or a use case? 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 mechanism whereby it's the widget engine that wakes up the widget when the network is back on. What do you think? Agreed. Does the way the requirement has been rewritten in regards to events address the looping issue?: A conforming specification MUST specify a means that allows authors to check if the widget resource is connected to the network. A conforming specification MUST define the scope of the term network and MUST specify a means by which connection and disconnection events can be captured by an author through script. A conforming
[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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] image.gifimage.gifimage.gifimage.gif
