W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: Comments on Widgets 1.0: Requirements - Editor's Draft 15 August 2008

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Fri, 5 Sep 2008 14:47:13 +0100
Message-ID: <b21a10670809050647sff84b2cjca6e7d3fecc8fa59@mail.gmail.com>
To: timeless@gmail.com
Cc: "public-webapps@w3.org" <public-webapps@w3.org>

Hi Josh,
Please approve the following corrections. Your comments did not
require any further clarification from my part.

Kind regards,
Marcos

On Thu, Aug 21, 2008 at 2:57 PM, timeless <timeless@gmail.com> wrote:
>
> http://dev.w3.org/2006/waf/widgets-reqs/ - Editor's Draft  15 August 2008
>
> I'm very sorry about the delay, other things came up, most of my
> comments below are really English grammar notes and aren't
> particularly important (some are spelling which are just embarrassing)

I put them in on purpose to keep you on your toes:)

> I believe my only major comment, which I didn't learn until last week
> (i.e. I wouldn't have known to comment about before the expiry period)
> is this point on 4-R12:
>
> I ran across a problem here (in 4-R12); we're internally discussing
> proxies (for mobile devices) that want to recompress data on the fly,
> they'd *love* to compress the files in a zip (thereby reducing the
> download size to the device), but in order for that to work, we'd need
> to make sure it doesn't break the signing. In general, keeping the
> radio on for larger downloads is a significant drain on device use
> time, and as such anything that can enable devices to leave it on for
> shorter periods is seen as a significant win (note this isn't asking
> that people use BZ2 or some extremely expensive to decompress
> algorithm, although I'm not actually sure if even that would be more
> expensive than the radio, but simple compression algorithms are
> definitely cheaper).

(This now refers to R11). The spec is designed in such a way that
recompressing will not break the signature.

> And yes, I'm aware that some people may download archives which have
> external pgp signatures. I don't expect mobile devices behind such
> proxies to have any interest in doing that, whereas I do expect them
> to want to access widgets. Given some of the things that the proxies
> have considered doing, I'm fairly certain they're not particularly
> worried about breaking a pgp signature (they don't seem to mind lossy
> image compression) .
>
> 3-Web and offline distribution:
>> It must be possible to perform updates from either an online or offline source.
>
> but not both?

True. Changed to "It must be possible to perform updates from online
and offline sources"

>> * Already a de facto standard on market-leading widget user agents on both desktops and mobile devices.
>
> this sounds wrong w/o "included" or "supported", but i don't know how to fix it.

Changed to "already the supported de facto standard on market-leading
widget user agents "

> 4-R7-Rationale:
>> ...variation in character encoding ...may render a widget ...inoperable ...unless a comment character encoding is used.
>
> 'comment'?

Fixed.

> 4-R12
>
>> authorities (i.e., multiple signatures).
>
> drop the comma here - only use it for lists - see (e.g. 100 years from
> date of the a specification reaching "Recommendation Status" W3C
> Process)

fixed.

> 4-R16-Copyright Notice and License Metadata
>
>> A conforming specification MUST specify the structure and semantics of fields that explicitly reference, or otherwise include, a software license agreement or notice, and declare who holds the copyright for the widget, as well as a model for how this data must be processed by a widget user agent.
>
> the English here seems wrong 'and' again seems to be in the wrong
> place .... actually the sentence is just too long and complicated. :)

Broke it up into two sentences.

> R17. Visual Rendering Dimensions
>
>> or any dimensional values implicitly computed by the widget user agent.
>
> should we make sure there's a way to let user specified styles
> override application styles?
>
> ...
>
> 4-R18-Rationale:
>> ... (e.g., '/ui/clock.svg').
>
> drop , (see earlier)

fixed

>> Alternatively, the bootstrap might be a Web page that when combined with the visual rendering dimensions requirement displays at the appropriate size.
>
> "the bootstrap" _process|file|?_

Changed to "resource might be a HTML document that when.."

> 4-R25-Rationale:
>>    NOT A RATIONALE!!
>
> this doesn't look like something that should be published :(

Sorry, that was note to myself. Removed.

> R33. Cross-Widget Communication
>> ("pairing" and "unparring").
>
> unpairing.

fixed.

> R34. Icon API
>>    To allow widget to
>
> widgets (please check globally)
>

Fixed. Checked.

> R36. Open Default System Web Browser
>> To allow author to open a URL in the default system web browser.
>
> authors (please check this globally)

Fixed. Checked.

> R38. Additional Digital Certificates
>> A conforming specification SHOULD NOT recommend that,
>> aside from including standard root certificates,
>> widget user agent allow end-users to install digital certificates
>> from other trusted sources.
>
>> Rationale:
>> To allow authors and publisher to sign widgets.
>
> the requirement and the rationale don't seem to match.

Good point. This was a "SHOULD" and got changed to a SHOULD NOT...
this is now an open issue AFAIK.

> R40. Automatic Updates
>
> what happens if i have 3 instances of a widget? do they all get upgraded?

Open issue. My preference is that, yes, they all get updated. However,
we will deal with that in the spec.

> R43. Default Security Policy
>> To make the default state of a widget as benign as possible.
>
> change state => behavior ?

Sounds good. Changed.

> This is a meta note listing most/each of the 'Motivation' items, most
> of which end in periods, most of which begin with a capital letter and
> most of which seem to almost be sentences, however they have 'and' or
> 'or' in non sentence positions. I'd suggest that these all be changed
> to if possible to try and only use one and/or per sentence, always
> before the last listed element, and to remove capitalization from non
> leading words unless it's strictly required. Oh, and periods should be
> used consistently :)
>
> 'and' before last item:
<snip>
All fixed...

Thanks again!

-- 
Marcos Caceres
http://datadriven.com.au
Received on Friday, 5 September 2008 13:47:58 GMT

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