On Tuesday 2015-09-08 17:33 -0700, Tantek รelik wrote: > Follow-up on this, since we now have two days remaining to respond to these > proposed charters. > > If you still have strong opinions about the proposed Web Platform and Timed > Media Working Groups charters, please reply within 24 hours so we have the > opportunity to integrate your opinions into Mozilla's response to these > charters.
Here are the comments I have so far (Web Platform charter first, then timed media). The deadline for comments is in about 2 hours. I'll submit these tentatively, but can revise if I get feedback quickly. (Sorry for not gathering them sooner.) -David ===== We are very concerned that the merger of HTML work into the functional WebApps group might harm the ability of the work happening in WebApps to continue to make progress as well as it currently does. While a number of people within Mozilla think we should formally object to this merger because of the risk to work within WebApps, I am not making this a formal objection. However, I think the proper functioning of this group needs to be carefully monitored, and the consortium needs to be prepared to make changes quickly if problems occur. And I think it would be helpful if the HTML and WebApps mailing lists are *not* merged. A charter that is working on many documents that are primarily developed at the WHATWG should explicitly mention the WHATWG. It should explain how the relationship works, including satisfactorily explaining how W3C's work on specifications that are rapidly evolving at the WHATWG will not harm interoperability (presuming that the W3C work isn't just completely ignored). In particular, this concerns the following items of chartered work: * Quota Management API * Web Storage (2nd Edition) * DOM4 * HTML * HTML Canvas 2D Context * Web Sockets API * XHR Level 1 * Fetching resources * Streams API * URL * Web Workers and the following items in the specification maintenance section: * CORS * DOM specifications * HTML 5.0 * Progress Events * Server-sent Events * Web Storage * Web Messaging One possible approach to this problem would be to duplicate the technical work happening elsewhere on fewer or none of these specifications. However, given that I don't expect that to happen, the charter still needs to explain the relationship between the technical work happening at the WHATWG and the technical work (if any) happening at the W3C. The group should not be chartered to modularize the entire HTML specification. While specific documents that have value in being separated, active editorship, and implementation interest are worth separating, chartering a group to do full modularization of the HTML specification feels both like busywork and like chartering work that is too speculative and not properly incubated. It also seems like it will be harmful to interoperability since it proposes to modularize a specification whose primary source is maintained elsewhere, at the WHATWG. The charter should not include work on HTML Imports. We don't plan to implement it for the reasons described in https://hacks.mozilla.org/2014/12/mozilla-and-web-components/ and believe that it will no longer be needed when JavaScript modules are available. The inclusion of "Robust Anchoring API" in the charter is suspicious given that we haven't heard of it before. It should probably be in an incubation process before being a chartered work item. We also don't think the working group should be chartered to work on any items related to "Widgets"; this technology is no longer used. I'm still considering between two different endings: OPTION 1: Note that while this response is not a formal objection, many of these issues are serious concerns and we hope they will be properly considered. OPTION 2: The only part of this response that constitutes a formal objection is having a reasonable explanation of the relationship between the working group and the work happening at the WHATWG (rather than ignoring the existence of the WHATWG). However, many of the other issues issues raised are serious concerns and we hope they will be properly considered. ===== One of the major problems in reaching interoperability for media standards has been patent licensing of lower-level standards covering many lower-level media technologies. The W3C's Patent Policy only helps with technology that the W3C develops, and not technology that it references. Given that, this group's charter should explicitly prefer referencing technology that can be implemented and used without paying royalties and without negotiating contracts for things for which licenses are not available to all. Likewise, the charter should list as a success criterion that the technology produced by the working group can be implemented and used without paying royalties and without negotiating contracts for things for which licenses are not available to all. Having the media group be separate from the HTML / Web Platform working group is also worse in terms of commitments made under the patent policy, and we would prefer keeping the media work as a task force within a larger group, as it is today. ===== -- ๐ L. David Baron http://dbaron.org/ ๐ ๐ข Mozilla https://www.mozilla.org/ ๐ Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform