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

Re: [charter] Request for Comments; deadline Sept 10

From: timeless <timeless@gmail.com>
Date: Fri, 28 Aug 2015 10:09:45 -0400
Message-ID: <CACsW8eENjiTKjxX2Bpr8zgTgL4k2Jcq8nRCtbNzKgeoRjgFwsQ@mail.gmail.com>
To: Arthur Barstow <art.barstow@gmail.com>
Cc: public-webapps <public-webapps@w3.org>
Art wrote:
> The proposal to merge the WebApps WG and the HTML WG has started a formal
> review period that ends September 10:
>
>   <http://w3c.github.io/charter-html/group-charter.html>

> IRC: active participants, particularly editors, regularly use the #webapps W3C IRC channel

is this channel intentionally inherited? I like it because it's shorter, but...

> If participants from less than three distinct browser-engine projects are participating in the group, its charter should be re-examined by the W3C.

less => fewer

personally, I'd prefer for this to be a link:
> Database and Offline Application APIs
> A set of objects and interfaces for client-side database functionality.
will this link be updated:
> For more details, see the Web Platform WG Database API page.
... it's in /2008/webapps/, also, it'd be better if this link were on
the section heading above
> The following Database APIs are deliverables under this charter:
> Indexed Database API (2nd Edition)
missing period:
>  An API for a database of records holding simple values and hierarchical objects
> Quota Management API
>  An API for managing the amount of storage space (short- or long-term) available.
> Service Workers
>  A new feature for the web platform that lets a script persistently cache resources and handle all resource requests for an application -- even when the network isn't available.
> Web Background Synchronization
>  A specification describing a method that enables web applications to synchronize data when next online.
> Web Storage (2nd Edition)
>  An API for persistent data storage of key-value pair data in Web clients.

> High level User Events
it's odd that level isn't capitalized... (it isn't linked either)

> An API that enables web applications to select file objects and access their data. This replaces the File Upload specification.

Could that specification be linked? (you can include a rel to avoid
adding to its pagerank...)

> HTML
it's odd that there's no link for this...

> The Group MAY define an API that provides access to a (native) input method editor application.

an IME may not be an application, it's often just a component :)

> The Group MAY also define the mechanisms to fetch resources using the HTTP protocol and its extensions.

drop `also`

> Packaging on the Web
>  This document describes an approach for creating packages of files for use on the web.

the style of this sentence doesn't match its cousins.


> Robust Anchoring API
link to doc ?
>  APIs for linking to a document selection, even when the document has changed. This is a joint deliverable with the Web Annotation WG.

link to WG?

> Screen Orientation API
>  A view orientation and locking API e.g. to enable reading the view's orientation state, locking view orientation, notification of view orientation state changes, etc.

`,` before `e.g.`

drop `etc.`

> Specifications that define mechanisms for adding custom elements to a document which allows them to have well-defined behaviour and rendering.

behavior


I'm not a fan of capitalizing `Web` alone, this document isn't
particularly consistent, as noted by the excerpts below:

> This Group develops technologies that enhance accessibility of web content for people with disabilities,
> A new feature for the web platform that lets a script persistently cache resources
> A specification describing a method that enables web applications to synchronize data when next online.

> An API that allows Web application authors
> Each specification should contain a section detailing any known security implications for implementers, Web authors,

I'd suggest you probably want to consistently capitalize `Web
Platform` since that's the name of the group.

> The working group will maintain errata and new editions, as necessary, for the following Recommendation-status specifications:
> CORS
> DOM specifications

while I'm sympathetic to not listing all DOM specs here, a link to an
editable page listing all the specs would be appreciated.

> Web Storage (2nd edition): Recommendation expected in 2015
> Web Workers: Recommendation expected in 2015
> Web Sockets: Recommendation expected in 2015
> XHR; Recommendation expected in early 2016
> DOM Parsing and Serialization; Recommendation expected in early 2016
> Web IDL; Recommendation expected in early 2016

s/;/:/g

`the working group` isn't consistently capitalized:
> After a specification reaches Recommendation status the working group may begin work on,
> A number of specifications depend on the WebIDL specification, which is therefore a very high priority for the Working Group.



> The Web Sockets specification has an effective dependency on the protocol defined by the IETF's HyBi Working Group.
Could the spec be linked?
> Given the large number of deliverables and therefore also dependencies between this working group and accessibility groups,
> the Web Platform team contact(s) will liaise with the team contact for
> Accessible Platform Architectures and Accessible Rich Internet Applications Working Groups
could these groups be linked?
> in order to ensure early identification of specifications with potential accessibility aspects, and to ensure coordination as needed during their development.

> (This Group is expected to combine into an all-guidelines group in 2016 2Q).

I don't understand this.

> The working mode of the group is described in detail on its wiki. In general the group does not hold plenary teleconferences, but does meet face to face at the TP/AC.

google: site:w3.org "tp/ac"
> About 36 results (0.56 seconds)
> Did you mean: site:w3.org "tpac"

> The Working Group conducts its work primarily through github repositories,

GitHub is a brand, please capitalize it according to its preference.

> The Group may use mailing lists. Subscription to these lists is open to the public, subject to W3C norms of behavior.

Member/IE seem to be forced to subscribe to an ML (at their designated
email address) which may be harmful to their mailbox's health. Is it
possible to arrange for the official ML used for such mandatory joins
be an unused ML and that all communications be done on other public
lists instead of the one that people are forced to join?
(Alternatively, could someone please fix this?)

> Up-to-date information about the group (for example, details about deliverables, issues, actions, status, and participants) is available from the Web Platform Working Group home page.


please move the `.` outside the link.


Process document isn't linked here:
> As explained in the W3C Process Document (section 3.3),
> This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.

It is linked here.:
> This charter for the Web Platform Working Group has been created according to section 6.2 of the Process Document.

Also, the 6.2 link isn't a link to 6.2, it's a link to 6.
Received on Friday, 28 August 2015 14:10:14 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:34 UTC