- From: Michael Davey <md84419@googlemail.com>
- Date: Tue, 6 May 2008 14:46:59 +0100
- To: public-appformats@w3.org
I have some comments on the "Widgets 1.0: Packaging and Configuration" W3C Working Draft 14 April 2008, http://www.w3.org/TR/widgets/ 1. Section 6.4 describes the attributes and children of the widgets element. Height and width attributes should be considered a hint to the client as to the initial sizing of the widget. Implementations may have better mechanisms for determining the initial height and width. Additionally, the widget code itself may need to determine its initial width and height at run-time based on external influences. 2. Section 6.8. Personally, I'm not keen on the suggested implementation of the License element. I'd prefer to see an implementation that incorporates both a URI to uniquely identify the license and a copy of the human-readable license text. Ideally, it would also programmatically describe the key rights and restrictions. Perhaps use the Creative Commons schema? http://web.resource.org/cc/ http://creativecommons.org/ns 3. Section 6.10 describes the security permissions afforded to the widget. In my view, a capabilities-based approach would be better. I advocate an <access or <capability element with an "optional" attribute and a "required" attribute. Each attribute would be a comma-seperated list of capabilities. I have a draft list of such capabilities for an embedded platform implementation that covers priviledged access to the device as well as the capabilities implied in the HTML 5 document. I perceive the need for implementors to be able to add their own capabiltiies, perhaps by prefixing the capability name with "-vendor-". The optional attribute would list capabilities that the widget would like in order to provide enhanced functionality. The required attribute would list capabilities that the widget requires in order to function correctly. If a widget requires a capability that the client is not prepared to offer or that the client is unable to provide then the widget would be in error. Capabilities have potential security implications but this is already covered by Widgets-DigSig (specifically, the ability to digitally sign the config.xml). 4. Editor's draft <http://dev.w3.org/2006/waf/widgets/> Section 8 step 7 (working draft Section 7 step 5) describes how to locate the configuration document. I have two recommendations: 4.1. Use multiple lang attributes within a single config.xml to support different languages rather than provide multiple config.xml files. 4.2. Mandate that config.xml will always be the first entry in a widget archive (this is similar to the model that Java uses for its Manifest file in Java JAR files). Being able to rely on the config.xml being the first entry in the archive and being valid for the chosen language allows implementors targetting embedded platforms to process widget files more efficiently. Regards, -- Michael Davey
Received on Wednesday, 7 May 2008 04:13:45 UTC