Re: Widgets 1.0: Packaging and Configuration feedback

Hi Michael,

On Tue, May 6, 2008 at 2:46 PM, Michael Davey <md84419@googlemail.com> wrote:
>
>  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.

True. I will make a note to reflect what you said.

>  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

That could work if there was some standardized and legally recognized
way to point to a license. However, AFAIK, this is not currently the
case.

Having an RDF license is out of the question for obvious reasons as it
would require RDF parsing, unnecessary complexity, etc (and I doubt
that the validity of using this has been tested in a court of law).

In regards to using arbitrary (which is not exactly what you
suggested, but what could happen in practice), consider the following
situation: Vendor X accidently ships a widget that will damage a
user's computer after they use the widget 5 times. Realizing this,
Vendor X changes their license online to cover themselves legally but
does not inform the user. Or what if the resource is unavailable
online at install time?

In our current model, amongst other things, having a digitally signed
license in the widget gives users recourse for legal action if
anything goes wrong.  If a vendor wants to change the license, they
must reship the widget.

>  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.

I'm not sure the semantics of what we have ATM are all that different
to what you are describing.

>  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-".

We are currently working on something similar and we will publish
something soon. Vendors can extend the capabilities of the config
format (or whatever else they wish) through their own namespace.

I would like to see your list of proposed capabilities as it might be helpful.

>  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.

We are working on a similar proposal at the moment. We will publish
something in the next few weeks and would certainly like to hear your
feedback.

>  Capabilities have potential security implications but this is already
>  covered by Widgets-DigSig (specifically, the ability to digitally sign
>  the config.xml).

The digsig spec, at this point, protects the widget from being changed
during transfer over the wire (although anyone can go in an remove the
digsig, or resign it with their own digsig). There is currently no
relationship between a digsig and capabilites afforded to the widget
by the widget user agent.  This may change in the future (but would be
unfair to developers who can't afford to buy a code signing
certificate).

>  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.

If I understand what you are proposing correctly, that would violate
i18n best practices:
http://www.w3.org/TR/xml-i18n-bp/#DevMLDoc

"This is an example of bad design. It shows a single document that
contains multiple translations of the same content...Instead, use one
document for each language. ... Other languages would go in similar
separate documents."

>  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).

That would be difficult for authors because they would require a
special tool (As an author, I should just be able to select the files
that make up the widget and make a zip file; an author does not care,
nor should they care, what order the files are in). Also, your
proposal goes against our KISS design goal (see requirements document,
linked from the design goals section of the spec).

>  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.

Yeah, but, like I said, it would be a pain for authors and the
efficiency gains are tiny. Implementations are free to find clever
ways to make the config doc finding process more efficient.

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 7 May 2008 16:50:00 UTC