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

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

From: timeless <timeless@gmail.com>
Date: Thu, 21 Aug 2008 07:57:45 +0300
Message-ID: <26b395e60808202157p37633516x411da06ff9b79149@mail.gmail.com>
To: "public-webapps@w3.org" <public-webapps@w3.org>

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

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?

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

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

'comment'?

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)

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

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)

> 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|?_

4-R25-Rationale:
>    NOT A RATIONALE!!

this doesn't look like something that should be published :(

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

unpairing.

R34. Icon API
>    To allow widget to

widgets (please check globally)

R36. Open Default System Web Browser
> To allow author to open a URL in the default system web browser.

authors (please check this globally)

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.

R40. Automatic Updates

what happens if i have 3 instances of a widget? do they all get upgraded?

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

change state => behavior ?

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:
4-R1-Motivation
> ... internationalization and localization, longevity.
4-R3-Motivation:
> ... Web and offline distribution, longevity.
4-R7-Motivation:
> ... current development practice or industry best-practices, ease of use, interoperability, longevity.
4-R8-Motivation:
> Internationalization and localization, current development practice or industry best-practices, ease of use, interoperability.
4-R9-Motivation:
> Internationalization and localization, current development practice or industry best-practices, ease of use, interoperability.
4-R10-Motivation:
> Device independence, Web and offline distribution, interoperability.
4-R11-Motivation:
> Web and offline distribution, device independence, current development practice or industry best-practices.
!! (currently there's an or floating near what might be the last item...)
4-R13-Motivation:
> ... internationalization and localization, longevity, accessibility.
4-R14-Motivation:
> Current development practice or industry best-practices, interoperability, accessibility.
4-R15-Motivation:
> Current development practice or industry best-practices, interoperability.
4-R16-Motivation:
> Current development practice or industry best-practices, interoperability.
4-R17-Motivation:
> Ease of use, device independence, current development practice or industry best-practices.
4-R18-Motivation:
> Ease of use, current development practice or industry best-practices, security.
4-R20-Motivation:
> ... internationalization and localization, accessibility.
4-R21-Motivation:
> Ease of use, current development practice or industry best-practices.
4-R22-Motivation:
> Security, current development practice or industry best-practices.
4-R23-Motivation:
> Ease of use, Web and offline distribution, device independence.
4-R24-Motivation:
> Ease of use, compatibility with other standards, current development practice or industry best-practices.
4-R25-Motivation:
> Ease of use, compatibility with other standards, current development practice or industry best-practices.
4-R26-Motivation:
> Ease of use, Compatibility with other standards, current development practice or industry best-practices.
!! note that 'Compatibility' is capitalized which is really un-sentence-like :(
4-R27-Motivation:
> Current development practice or industry best-practices, ease of use.
4-R28-Motivation:
> Current development practice or industry best-practices, ease of use.
4-R29-Motivation:
> Current development practice or industry best-practices, ease of use, accessibility.
4-R30-Motivation:
> Current development practice or industry best-practices, ease of use.
4-R31-Motivation:
> Compatibility with other standards, current development practice or industry best-practices, internationalization and localization
!! this doesn't even have a period.
4-R32-Motivation:
> Current development practice or industry best-practices, interoperability.
4-R33-Motivation:
> Current development practice or industry best-practices.
4-R34-Motivation:
> Current development practice or industry best-practices, accessibility.
4-R35-Motivation:
> Current development practice or industry best-practices.
4-R36-Motivation:
> Current development practice or industry best-practices.
4-R37-Motivation:
> Compatibility with other standards, current development practice or industry best-practices, ease of use, accessibility.
4-R40-Motivation:
> Security, current development practice or industry best-practices, interoperability.
4-R41-Motivation:
> Current development practice or industry best-practices, interoperability.
4-R42-Motivation:
> Current development practice or industry best-practices, Web and offline distribution, Security.
4-R43-Motivation:
> Current development practice or industry best-practices, security.
4-R44-Motivation:
> Current development practice or industry best-practices, security.
Received on Thursday, 21 August 2008 04:58:22 GMT

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