- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Fri, 5 Sep 2008 14:47:13 +0100
- 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 UTC