Response to "Call for Review: Timed Text Working Group Charter"

Regarding the "Call for Review: Timed Text Working Group Charter"
https://www.w3.org/2002/09/wbs/33280/ttwg-charter-2022/

Our formal objection to this charter is below and we are in agreement with
the formal objections in
https://www.w3.org/2002/09/wbs/33280/ttwg-charter-2022/results

I, Tantek Çelik

W3C Advisory Committee representative for

Mozilla Foundation

 * (*) suggests changes to this Charter, and only supports the proposal if
the changes are adopted [Formal Objection]


Comments:


This charter version seriously weakens the interoperability requirements to
advance beyond Candidate Recommendation from the previous (and usual)
requirement to have two independent implementations.

https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2020%2F12%2Ftimed-text-wg-charter.html&doc2=https%3A%2F%2Fwww.w3.org%2F2022%2F02%2Fproposed-timed-text-wg-charter.html

Specifically the section “1.1 Success Criteria” removed from “1. Scope” and
turned into its own section below “3. Success Criteria” remove the
requirement for “at least two independent implementations of each feature
defined in the Technical Report.” and replaces it with the following novel
test:

When considering suitability to advance any feature beyond Candidate
Recommendation, at least two factors of verification MUST be demonstrated,
which may come from any of:

   -

   Presentation implementation
   -

   Content
   -

   Validating implementation

For example, a feature MAY be advanced beyond Candidate Recommendation if
it has been demonstrated to be implementable on the basis of a single open
source implementation that successfully processes content from an
independent source.

This is not conducive to developing interoperable specifications and is
contrary to W3C practice in other groups. If anyone were to propose that a
CSS or WebAPI feature could “advance beyond Candidate Recommendation” with
a single browser engine (or validator implementation) processing it and
single independent website publishing it, we would immediately recognize it
as unacceptable and reject it, and we should do so here as well.

Restoring the multi-implementor requirement would satisfy this objection.
For examples of modern charters with such a requirement, see:

* CSS: https://www.w3.org/2020/12/css-wg-charter.html#success-criteria

* WebApps: https://www.w3.org/2020/12/webapps-wg-charter.html#scope

In order to match modern practice, this requirement should be at the MUST
level.

Alternately, if the Team no longer believes that the Working Group can
publish standards supported by multiple interoperable implementations, or
rather, believes that only a single open source implementation is expected,
then this charter proposal should be changed to a Community Group proposal
to reflect that expectation which fits incubation and prototyping, not
standardization, and the Working Group closed until such time as there is a
change in expectations of multiple interoperable implementation support.


Tantek Çelik

Mozilla AC Representative