W3C Council Report on the Formal Objections Against the Timed Text Working Charter
Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Copyright © 2023 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
In preparation for formal proposal and adoption of a version of the W3C Process which does not rely on the Director for handling Formal Objections, W3C has been experimenting with resolving Formal Objections through a body, named “W3C Council”, combining the capabilities and perspectives of the AB, the TAG, and the Team. Operating under delegation from the Director, the AB, TAG, and Team have been following the terms of a draft version of the W3C Process.
Mozilla, Apple, and Google objected to a proposed rechartering for the Timed Text Working Group. Prior to the formation of a Council, the Working Group and Google found a mutually satisfactory solution, and Google withdrew their objection.
A Council was then formed to rule on the remaining objections. A detailed exposition of this case may be found in the Report prepared by the W3C Team.
In its early discussions about these Formal Objections,
the Council identified a potential avenue for consensus between the Objectors and the Working Group.
As indicated by the Draft Process,
The Council may further attempt to broker consensus, which, if successful, disposes the formal objection.
.
Accordingly, the Council made a suggestion.
The Working Group quickly adopted part of that suggestion,
and after further discussions with Apple,
agreed to the rest of that suggestion as well,
and Apple withdrew their objection.
Along the way, Mozilla indicated that it considered the changes envisioned by the Council's suggestion to insufficient to resolve their objection.
As not all the Formal Objections were resolved, the need for a Council decision remains. This Council Report documents the conclusions of this Council.
The Formal Objection from Mozilla to re-chartering the Timed Text Working Group requested either changes to the Requirements for advancing the maturity level of features section of the charter, or replacing the Working Group with a Community Group.
The Council resolved, by consensus, to overrule the remaining objection: with the changes which led to the withdrawal of Apple and Google’s Formal Objections integrated, the charter may proceed.
The Working Group noted that some of the objectors were part of the Working Group and had had the opportunity to raise their concerns early on, but had not done so prior to Formally Objecting. It also noted that the Formal Objection from Mozilla came after the formal end of the Advisory Committee Review Period on the Charter, and some regrettable confusion as to whether late objections were admissible.
The Council itself also observed tardiness from the Objectors when the Working Group sought to confirm with them whether some proposed changes would be sufficient to satisfy their concerns.
The Council’s view is that all Formal Objections made prior to a decision being enacted are admissible, regardless of whether the Objector failed to make their concerns known earlier, or of whether the Objection met a particular deadline such as the close of an Advisory Committee Review. Failure to comment or respond in a timely manner does not inherently make the arguments invalid. Nevertheless, raising concerns early and responding quickly to comments are important contributors to successful consensus building, and are more conductive to obtaining significant changes.
As documented in the Team Report, the Working Group felt it could be inappropriate to use Formal Objections to impose additional specification success requirements beyond what is stated in the Process. However, the Council has consensus that the Process actually does not contain any hard requirements for success criteria, but rather expresses guidance on the kinds of things to consider when making a judgment about sufficient implementation experience for a particular specification or feature. Thus, we see the Process as a baseline upon which Working Group charters build to clarify their implementation expectations in their particular context. In particular, since Charters often go beyond the guidance of the Process, it is within scope of an AC review for AC representatives to express an objection if they believe that for a particular charter there should be tighter criteria.
In this context, the Council felt that the Working Group should be commended for including in its draft charter specific criteria tailored to its deliverables. Although the criteria in question were a source of friction and Formal Objections, it is much preferable to have such discussions at chartering time than later in the process.
The W3C Process only gives high level guidance about how implementation experience for a specification will be judged. However, it is a commonly accepted best practice in W3C to expect two independent implementations of each feature, verified by tests, as a good way of confirming that the expectations laid out by the Process for advancement to Recommendation are satisfied. Deviating from this could be justified in certain contexts, but the reasons for needing this exception would need to be clear, and satisfaction of the same expectations would still need to be demonstrated, albeit through different means.
The original phrasing of the Requirements for advancing the maturity level of features section of the proposed charter, was in some ways stronger than that of the previous charter; notably, it switched from SHOULD to MUST about having two factors of verifications. However, its overall phrasing was ambiguous, giving rise to the concern shared by all 3 objectors as well by 2 other Advisory Committee Representatives who had not formally objected, but has expressed similar reservations. The Council considered this concern legitimate: the phrasing could be seen as enabling advancement on the basis of a single implementation, without providing either a reason for why relaxing the two-implementation expectation would be necessary, nor indicating alternative means to ascertain sufficient implementation experience.
After incorporation of the changes that were deemed sufficient by two of the objectors, the section now reads as follows:
Within the requirements of the Process each new normative feature will be considered as ready to advance to a higher maturity level if its implementability has been demonstrated.
When considering suitability to advance any feature beyond Candidate Recommendation, at least two independent factors of verification for each normative requirement MUST be demonstrated, which may come, as relevant for that requirement, from any of:
- Presentation implementation
- Content-producing implementation
- Validating implementation
For example, a feature may be advanced beyond Candidate Recommendation if it has been demonstrated to be implementable on the basis of an open source implementation that successfully processes content from an independent implementation.
The Council believes that the above phrasing could be further improved to make it even clearer, but deems it adequate to support the typical practice mentioned earlier of requiring two independent implementations for advancement. Importantly, while verification can come from any of the three factors listed, they are required to be relevant for the feature being tested. Here are some examples. A specification can contain normative requirements on validators; for those requirements, two validating implementations would be acceptable factors of verifications. The specification can contain normative requirements on content creation; for those requirements, two independent content-producing implementations would be acceptable factors of verifications. A specification can also contain requirements on presentations; for those requirements, two presentation implementations would be required. A validating implementation and a presenting implementation (which first needs to parse the content before displaying it) could be considered as two factors of verification for parsing requirements, but would not be sufficient for normative requirements pertaining to presentation. Based on the criteria expressed in this section of the Charter, a specification which included both parsing and presentation requirements would not be able to advance beyond Candidate Recommendation if there existed, for example, only one validating implementation and only one presentation implementation, because there wouldn't be two relevant factors of verification for each feature.
Mozilla, despite agreeing that conditions along the lines of those outlined in the above paragraph would be appropriate, disagreed that the text adopted in the charter was sufficient to show that the Working Group did intend to fulfill these criteria or to hold it to them.
The Council disagrees, and notes that even if the Working Group were to attempt a transition on questionable grounds, both the Team during the Transition Request and the Advisory Committee during the Advisory Committee Review would be able to insist on upholding the expectations. Recognizing the importance of timeliness, the Council does not believe it would be appropriate to spend additional time in pursuit of better phrasing, and judges that the level of mutual understanding achieved is adequate.
Further, in its Formal Objection, Mozilla argues that:
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.
Similarly to its previous ruling in the 2022 Devices and Sensors Council Report, the Council judges that demanding, at charter time, the presence or imminent presence of two implementations goes beyond the general expectations of the community.
In conclusion, the Council judges that the part of Mozilla's Objection which coincided with the concerns of others has been sufficiently addressed, and overrules the remainder.
Some additional Member-only remarks were made in connection with the Objections. These do not change the Council's conclusion. To respect confidentiality, they cannot be discussed in this report, but are covered in a Supplemental Member-only Council Report.
IMSC-HRM is fairly distinct from the other deliverables of the Working Group, in that it does not define a distinct format or profile of a file format, but a model for evaluating and validating a property (presentation complexity) of a preexisting format (documents that conform to any of the TTML Profiles for Internet Media Subtitles and Captions).
It seems to the Council that this specification would lend itself well to being implemented in terms of validators (either standalone or as a feature of another piece of software) processing document instances according to the model, where interoperability would be demonstrated by having multiple independent validators produce the same specification-compliant diagnostic when presented with the same content.
The Council understands that the Working Group intends to present a significant body of content, produced by various implementations, that is successfully validated by the model. This—or even preferably, evidence of content that would fail the criteria being modified to pass it—would support claims of market relevance, and is very much welcome.
To the extent that the specification makes normative requirements on content-producing implementations, it makes sense to use such implementations as verification factors for those requirements. If the specification does not specifically make requirements of validators, and it can be shown that the content-producing implementations actually implement the model, they would also be a relevant verification factor.
It would be hard, however, to claim that content that satisfies the criteria, on its own, demonstrates interoperable implementation of the model, as such content could well be created fortuitously by someone entirely unaware of IMSC-HRM, or by trial and error, without reference to the specification or understanding of the model, by adjusting content (or the software producing it) until the right response is received from a pre-existing validator.
The Council invites the Working Group, as it matures this specification and associated test suites, to be cognisant of the difference between validating content, showing market relevance, and demonstrating interoperability.
Information on participation, as required by the draft Process on Councils.
The following individuals were potential Council members, due to either being participants in the TAG or the AB, or to being the W3C CEO:
None of the them renounced their seat on the Council; none of them were dismissed. Therefore, all were qualified to serve. Note, however, that Jeff Jaffe’s tenure as the W3C CEO ended while this Council was ongoing.
Amy Guy was chair from 2022-11-03 to 2023-03-02, and Florian Rivoal was chair thereafter.
Of those qualified to serve, the following participated in the final decision:
This section is not part of the formal Council Report. It is provided for informative purposes only.
The handling of these Formal Objections was an unfortunately lengthy process. This appendix offers some insights about what took so long, and about the various steps taken to ensure faster response time in subsequent Councils.
The timeline below summarizes key dates.
The draft Process requires a maximum of 90 days between step 1 (closure of the AC Review) and step 5 (Council formation being initiated), but 215 days elapsed. Some of it was used, as is appropriate, for (attempts at) discussion between the Working Group, the Objectors, and the Team, but that is nevertheless too long. The following measures were taken to prevent that from reoccurring:
The draft Process expects a maximum of 45 days between step 5 (Council formation being initiated), and step 8 (Council being convened), which was respected, as 37 days elapsed.
The draft Process expects a maximum of 45 days between step 8 (Council being convened) and step 19 (Council publishing its conclusions) requiring the Chair to inform to the Advisory Committee about the delay otherwise. However, 144 days elapsed. (The AC was updated on the delay on 2023-01-25 and 2023-03-02.) Some of this time was well used, but some periods stretched for longer than they should. The following measures were taken to prevent that from reoccurring: