This document is intended to help the Director and his delegate to understand all sides of the arguments related to the Formal Objections to the Proposed Charter of the Timed-Text Working Group. It is not an analysis of every argument raised.
The proposed charter got 17 reviews:
Apple, Inc. formally objected:
This draft charter critically weakens the Timed Text WG's success criteria by removing the multi-implementer requirement. Restoring the multi-implementor requirement would satisfy this objection. For examples of modern charters with such a requirement, see:
Mozilla Foundation formally objected, and send their objection to public-new-work:
This charter version seriously weakens the interoperability requirements to advance beyond Candidate Recommendation from the previous (and usual) requirement to have two independent implementations.
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 implementationFor 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.
Apple, Inc. and co-chairs of the Working Group had a call. Apple, Inc. did not agree to an alternate text by Google LLC, and proposed a change with reverting updates from the previous charter during the call and to provide an alternate text later.
Co-chairs of the Working Group have not received a proposal with an alternate text as of 10 August 2022.
The Working Group discussed on 12 May, 2022, 09 June, 2022, 23 June, 2022 and 21 July, 2022, and got a consensus that the Working Group does not concur with the proposed change.
The Working Group did not have any conversation with Mozilla Foundation, since the message was provided as an email after the review period ended.
During the development of the draft charter within the Timed-Text Working Group, co-chairs did not get any comment nor objection from participants of Apple, while four (4) participants are in the Timed Text Working Group from Apple.
The Group does not believe that the Formal Objection from Apple is supported by the W3C Process. 6.3.7. Transitioning to Candidate Recommendation has a requirement as
must document how adequate implementation experience will be demonstrated,
The adequate implementation experience is stated as
that there is adequate implementation experience the Director will consider (though not be limited to):
- are there independent interoperable implementations of the current specification?
So, the Group believes that the W3C Process requires that adequate implementation experience be demonstrated and provides a non-exhaustive list of possible means of demonstrating implementation experience which are mentioned as “will consider (though not be limited to)”. The existence of independent interoperable implementations is one such means, but not the only means and not a required means. A pointed example from WebApps WG in Apple’s Formal Objection requires two independent implementation with MUST as:
In order to advance to Proposed Recommendation, each specification must have at least two independent implementations in wide use.
The current running charter of the Timed-Text Working Group stipulates that
1.1 Success Criteria
In order to advance to Proposed Recommendation, each Recommendation-track Technical Report SHOULD have at least two independent implementations of each feature defined in the Technical Report.
and the proposal from Apple after the Formal Objection was to reinstate the same text to the proposed charter. The text introduces a requirement of two independent implementations as SHOULD but not MUST.
The Group has a consensus that the existence of multiple independent implementations is not always the most appropriate means of improving specification quality, and has one idea to revise the charter to require that:
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
The group plans to propose and use one approach for the IMSC HRM specification that one open source implementation of the specification is evaluated against test sets authored by multiple independent parties. This approach is particularly relevant in the case of a specification that defines a validator where the existence of a single open source validator is often sufficient.
Google LLC Formally Objected (resolved on 10 May 2022):
We agree with the concerns voiced by Apple, Adobe and MovieLabs that this charter removes multiple independent implementations from the success criteria. Though we believe the group's work is important, requiring the experience of multiple implementations is a critical step to ensuring the interoperability of a true standard.
Google LLC proposed an alternate text and the Working Group agreed to change the proposed charter.
The Team report at https://www.w3.org/2022/09/ttwg-charter-fo-report.html was shared on behalf of the Team by its editor Atsushi Shimono, who is a member of Timed Text Working Group (TTWG) and W3 Team, on 2022-10-04 with a call for comments, whose deadline was 1 week later, 2022-10-11. The key parties to the Formal Objections are 1. The "deciders" being TTWG itself, 2. The objectors, being Apple and Mozilla. See https://www.w3.org/Project/council.html for procedural details.
In this case the Deciders have been given 1 week to respond, but have themselves got a 10 working day (i.e. 2 weeks) review period as per the Decision Policy active at https://www.w3.org/2020/12/timed-text-wg-charter.html#decisions. Therefore the FO Council process does not allow the Deciders to reach any decisions about their response. In lieu of this, this document is the Chairs' response, which was discussed during an extraordinary meeting of TTWG on 2022-10-06.
Three categories of comment are offered below:
As a general comment on the report, it is broadly accurate.
The Procedural History section should include the background of the decision made by TTWG to which the Formal Objection has been raised, including the timeline of charter drafting discussions and the missed opportunities by Apple for earlier engagement, as well as the date when David Singer left the TTWG. Multiple opportunities existed for Apple to participate in the TTWG's Decision to update the Charter wording, none of which was taken.
The Procedural History section should include details of the attempts made to resolve the comments and objections raised in response to the AC Review. In dealing with the Formal Objections, the TTWG was guided by Philippe Le Hégaret (PLH) in the call on 2022-03-31 (minutes) that Mozilla's email could be discounted. It was the Chairs' understanding that we did not need to address that email; the Chairs omitted to take action on PLH's suggestion to contact Mozilla regardless. Had PLH's guidance been that Mozilla's email should be considered a Formal Objection, we would likely have responded differently: to present this email now as a Formal Objection is therefore a matter of importance. The inconsistency of interpretation is unhelpful, and presenting it now as a Formal Objection casts the TTWG in a more negative light than we think is reasonable.
The Analysis section states that "Group does not believe that the Formal Objection from Apple is supported by the W3C Process": this is true, but also, more specifically, the premise of both Apple's and Mozilla's objection is false, since they assert the existence of a requirement that in fact does not exist. In other words they are trying to introduce a new requirement via FO: in the Chairs' view this is a misuse of process and FO Council should therefore not entertain these objections.
The final paragraph of the Analysis section, beginning "The group plans to propose and use one approach for the IMSC HRM specification": this explanation omits important details. The TTWG strongly prefers a single approach for CR exit criteria that can be adapted for all the TTWG's Rec track specifications; the IMSC HRM is merely an example of the kind of specification where we think the new CR exit wording would allow adequate flexibility. If the report is to include IMSC HRM as an example then it also must explain the context: the HRM is already Rec track text in 3 Recs and the effort here is to refactor it and do some bug-fixes to the spec to improve the overall state of our Recs.
The Appendix should also include the WG's resolution to Adobe's requested change (Pull Request), and in doing so, that MovieLabs' request was also resolved.
The Appendix includes the proposed and accepted resolution to Google's Formal Objection, but unlike the previous parts of the document in which the specific details are included inline, they are in this case only linked. It would be helpful to include the accepted change within the Report itself.
The TTWG's overall view is that the spirit of the deleted "SHOULD" requirement is in fact being kept and indeed strengthened by the replacement wording, and that the objectors have not understood this key point. This is alluded to within the Report text but should be stated more clearly.
It would be easier to understand the timeline of events if there were one single timeline, rather than a partial timeline in the Procedural History and some additional details included as part of the Analysis text.
The report variously calls the TTWG "Timed Text Working Group", "Timed-Text Working Group" and "the Group". It would be helpful to adopt a consistent approach to avoid misunderstanding – in particular "the Group" should be explained. Adding a link to the TTWG Participants list at https://www.w3.org/groups/wg/timed-text/participants could be helpful.
The wording "has one idea to revise the charter" reads strangely and may give a misleading impression that there has been some arithmetic counting of ideas: this should say that the WG's Decision was to use the wording in the draft Charter, which is what is quoted.
Within the Analysis section the analysis of the Process and Charter wording is expressed as the Group's belief. This is true, but the Team's views are unclear. Since Atsushi, the editor and author, is a member of TTWG and was present during the discussions, and did not disagree, we understand that he shares the TTWG's views. However, possibly this is not the wider Team's view? Whose views are being expressed in this report? As a matter of governance it appears unreasonable to put a WG's team contact in the position of arguing potentially for or against the WG of which they are a member. Indeed there was one TTWG meeting during which tensions rose to an unacceptable level: the Team has since apologised for this. Consideration should be given to preventing this scenario from arising in future.
The wider context has been omitted: the lack of clarity about CR Exit Criteria has been raised as Process CG issues (e.g. [define "independent"] w3c/w3process#167, [Single implementations and interoperability: showing implementation experience with fewer implementations] w3c/w3process#522), and discussion of Independent Interoperable Implementations happened during a breakout session at TPAC 2022. To the extent that W3C member organisations attempt to create Process requirements through Charters, TTWG does not believe that this is an appropriate way to achieve that goal, and that W3C consensus should be established first.