On 09/11/2015 04:53 AM, L. David Baron wrote:
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.
This sounds good to me.
After chatting with MikeSmith and ArtB I'm not so worried about the merge
anymore.
(Apparently merge is a bit too strong word here even, it is more like taking
the specification to the
WebApps WG, but trying to not take the rest of the baggage from HTML WG.)
-Olli
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.
=====
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
