Widgets 1.0: Packaging and Configuration feedback

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