Hi, Art-

Thanks for the feedback.

Arthur Barstow wrote (on 2/9/10 9:34 AM):

On Feb 8, 2010, at 7:25 AM, ext Doug Schepers wrote:

We are interested in comments to refine the charter before submitting it
to the Advisory Committee and W3C management for review.

[1] http://www.w3.org/2010/webapps/charter/Overview.html

The changes from the current [Charter] look good Doug!

Thanks, happy to help.


Some additional changes I propose, using [PubStatus] as a guide for some
of the comments:

3.1 - a straight diff on the draft and [Charter] shows a relatively
significant set of changes. However, there are really just 3 additions:
Alternate Input Device Events, PostMessage + MessageChannel and Web
Notifications. Perhaps it would be useful if these three additions were
marked up such that these additions were easily identified.

Added a paragraph describing the changes, and notated each of the new deliverables.


3.1 - it would be convenient if all of the specs included pointers to
their EDs (links are missing for Clipboard, DOM, File API, Progress
Events, PostMessage/MessageChannel, Selectors L1 and L2, Web
Notifications, XBL2, XHR L1 and L2).

Done.


3.1 - CORS is included as a 1st-level bullet and a sub-bullet of "Secure
Cross-Domain Scriptiong". I would delete CORS' 1st-level bullet.

Copy/paste error... removed.


3.1 - Widgets specs: we have already started to remove the "Widgets
1.0:" prefix for the spec names and this draft charter should do the
same (e.g. change "Widgets 1.0: Updates" to "Widget Updates").

Done.


3.1 - re Widgets View Modes - there are actually two related EDs so I
would change this to "Widgets View Mode: a media feature and API related
to presentation mode".

Done.


3.3 - I think you can delete the "Notes:" line

Removed.


4.1 - besides XHR, at least one of the widget specs (TWI) has a
dependency on the HTML5 spec.

Added.


4.2 - re CSS WG, change the text to "To collaborate on the Selectors API
and widget media feature specifications"

Changed.


2., 3.1 and 4.2 all refer to the "Canvas Graphics API". What is this API
and would it make sense to consolidate this info in one or two places in
the charter?

Removed from 2. and 3.1. Probably won't happen anyway, but it has been split out as a separate HTML WG deliverable, so it's good to be prepared in case more upheaval happens.


4.2 - "Security Group?" - it's not clear what this is about. Is this the
informal security IG (public-web-security) or the XML Security WG or
something else?

TLR is working on putting together a Security Interest Group, but it won't be ready in time, so I've commented this out.


4.2 - re the MAWG, given WebApps' history with Media related spec work,
perhaps the text should be a bit more specific e.g "To integrate
consistent APIs for multimedia functionality e.g. MAWG's <a
href="http://www.w3.org/TR/mediaont-api-1.0/";>API for Media Resource
1.0</a>".

Done.


4.3. - the Web Sockets protocol is in scope for IETF's HyBi (not their
HTTP WG) and it should be explicitly identified. I think this can be
addressed by using "... keep pace with the IETF's HTTP and <a
href="http://www.ietf.org/dyn/wg/charter/hybi-charter.html";>HyBi</a>
groups' work ...".

Done.


9. Given WAF and Device API WGs closed almost two years ago, I would
delete the "Please also see ..." sentence.

Changed to a link to previous charter.


Lastly, 4 specs are listed in [PubStatus] and not included in the draft
charter. Above I propose a way to reflect our interest in what [Charter]
calls Media Object, but re the other three:

a. Element Traversal - it seems like this should be explicitly included
in the charter with a caveat that no work will be done except errata
handling if the need arises.

Added back, with notes.


b. File Upload - does the group now consider this work taken over by the
File API and File System spec or is there something here we want to
explicitly include in the draft?

Added a note in File API that it replaces File Upload.


c. Window object - given the wording in 3.1 re HTML5 "split out", I
presume it's OK for the draft to not explicitly include this spec since
this wording would permit WebApps to take it (given an Editor, etc.).

That was the previous suggestion, so I removed it. I would be happy to add it back if we had an editor who will follow through on it, but those are scarce.


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Reply via email to