W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: Some comments on Widgets 1.0: Packaging and Configuration

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Wed, 1 Oct 2008 16:58:52 +0100
Message-ID: <b21a10670810010858m5f2430ddh8af5b664e3acc7d6@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>

Hi Dom,
On Tue, Sep 16, 2008 at 10:20 AM, Dominique Hazael-Massieux <dom@w3.org> wrote:
> As I started looking at the testability of the "Widgets 1.0: Packaging
> and Configuration" specification, I spotted a few things that I thought
> I would mention (based on the CVS editors's draft [1]):
>
>  * the relax NG schema doesn't include a definition for the <update> and
> <requires> elements; it doesn't include the declaration of the mode
> attribute on the root element, of the img attribute on the <author>
> element, of the width, height and alt attribute on the <icon> element,
> of the files attribute on the <access> element

As you know, the schema has now been updated (but will soon be out of
date again). However, I don't want to waste David's time continuously
updating the schema until the text in the spec has stabilized.

>  * 6.10 "When the access element is absent, a widget user agent must
> deny access to networked resources and to plugins", and presumably to
> the file system as well; instead of separate boolean attributes, what
> about having these as a single token-based attribute (e.g.
> access="network plugins")

You raise a good point. We are considering dumping the <access>
element and using <feature> for everything. So, we would have
something like:

<widget ...>
 <feature id="http://www.w3.org/widgets/network" />
 <feature id="http://www.w3.org/widgets/plugins" />
</widget>

We will be debating this model over the next few weeks.

>  * some of the green notes highlight interoperability problems - this
> sounds like material for conformance requirements rather than just
> notes.

We have debated at length in the past about whether these notes should
be normative or not (I'm sorry, I can't provide you with a
reference/pointer right now), we reached a resolution that we would
leave them as notes for now. If upon building a reference
implementation (or the test suite) we find that these in fact are
going to cause interop issues, then we can easily change them.

>  * "Author requirement"s probably ought to called "Authoring
> requirements" since you're not trying to define conformance for authors
> but for what they author

You are probably right, but we are keeping this consistent with HTML5
(which currently uses "Author requirements").

>  * there seems to be well-known filenames that have special semantics
> attached in the widgets specs (at least config.xml, signature.xml, the
> locale directories); the list of reserved filenames sounds like
> something that should be explicitly documented in the packaging spec; in
> particular, it should probably be recommended not to use 2 and 3 letters
> names for directories at the root of the archive (trivia: which in the
> followings is not a language code: cat, bin, bak, iii, inc, lol, map,
> oss, run, sux, tel?)

I have added a section in the spec called "Reserved filenames" and
created a table that lists what names are reserved and for what
purpose. I also added a note warning authors about the use of 2 to 3
letter file names.

>  * "If the access element is used, a full URI must be given" - I don't
> think the notion of "full URI" is defined anywhere

Yep. I need to go through the whole spec and fix up all the URI
related stuff. This is a big job, which I am currently working on.

>  * the references section don't distinguish normative from informative
> references;

fixed. Prefixed References with the word  "Normative". Will add an
Informative References section later if one is needed.

>  * there seems to be a normative reference to HTML 5 in "Rules for
> Identifying the Content Type of a Start File", but HTML 5 is not in the
> list of references; also, having a normative dependency on HTML5 means
> the spec won't be able to go to REC until HTML5 does
>

Understood. We will look at ways of minimizing our dependencies on
HTML5. However, I personally don't see it as a problem if this spec
sits

> I'm sorry these comments are a bit randomish, but I thought I would send
> them while I looked at the spec.

No, that's great! thank you!



--
Marcos Caceres
http://datadriven.com.au



-- 
Marcos Caceres
http://datadriven.com.au
Received on Wednesday, 1 October 2008 15:59:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT