Independent
This article is a stub. You can help the W3C wiki by expanding it.
The goal of this page is to collect, curate, and distill information about what does independent mean in a W3C context in general, and as it applies to the W3C Process, and the Success Criteria of (most) Working Group Charters.
This is part of the 2024 AB Priority Project: Interoperability and the Role of Independent Implementations ("3Is project").
Why this project
The Process references "independent […] implementations" twice:
…ensure that independent interoperable implementations of each feature of the specification will be realized.
…
• are there independent interoperable implementations of the current specification?
Emphasis added.
Differences in understanding of what "independent" means have been a source of conflict, including Formal Objections.
This project seeks to capture our shared understanding of what independent means to W3C in the context of implementations, and what we aspire it to mean.
Related W3C Process issue(s):
Why independent
One purpose of the requirement for independent implementations (plural) at a high level is to provide an encouragement for higher quality, broadly relevant specifications which can be implemented by additional implementers who did not participate in the creation of the specification or its test suite.
In particular:
Broad industry support
Requiring multiple independent implementations help demonstrate broad(er) industry support of the problems a specification is solving, and the spec’s approach to solving them.
As David Baron said 2020-04-07:
For some specifications, it's important to know that it has broad enough support within the industry that multiple companies are willing to invest in its success. One thing that can help verify this is if multiple companies are willing to invest in implementing it.
User choice and security
The more independent implementations there are of a specification, the more choices users have (assuming interoperable implementations) for the features defined by the spec.
The more independent these choices are, e.g. independent codebases, avoiding shared use of libraries or other common dependencies, the greater the chance that a security vulnerability found in one will not impact others, enabling users to switch when such vulnerabilities are discovered.
As David Baron said 2020-04-07:
For some specifications, the existence of multiple implementations of a specification gives the users of that specification more confidence that they would be able to switch to a different implementation if they needed to (for example, to avoid a security vulnerability in one implementation). To verify this, it may be important not only that the implementations be in different pieces of software but also that they lack common dependencies.
Sufficiently detailed specs
Interoperable independent implementations, plural, is used as one way to verify that a technical specification is written with sufficient details for spec functionality to be implemented in a way that works (interoperates) with other implementations, without (independent of) any internal knowledge of those other implementations.
If implementing a spec requires internal knowledge of another implementation, then that indicates an area (or details) that need to be better documented in the specification itself.
As David Baron said 2020-04-07:
It's important to know that the specification (perhaps supplemented by the test suite) contains enough information to produce interoperable implementations without reverse-engineering an existing implementation. To verify this, it's important that the implementations be done by different people or by non-overlapping teams (since one person is likely to make the same assumptions across multiple implementations).
Test suite quality
Experience has shown test cases may sometimes also reveal the need for more such details.
Test cases MUST be based on normative specification text, and ideally link to or provide another "follow your nose" method for discovering what particular spec text(s) is/are a test case testing.
When an implementation fails a test case because it tests functionality beyond existing normative spec text, then either:
- The test case should be rewritten or removed, OR
- The specification should document the details tested by the test case
In this way, requiring independent implementations is one such driver of improved test suite quality.
Articles
Articles and blog posts on the topic of independent (implementations) in standards:
- 2020-01-20 Jeremy Keith: Unity
I think of situations where complete unity isn’t necessarily a good thing. Take political systems, for example. If you have hundreds of different political parties, that’s not ideal. But if you only have one political party, that’s very bad indeed!
There’s a sweet spot somewhere in between where there’s a base of level of agreement and cooperation, but there’s also plenty of room for disagreement and opposition. Right now, the browser landscape is just about still in that sweet spot. It’s like a two-party system where one party has a crushing majority. Checks and balances exist, but they’re in peril.
- 2020-01-26 torgo.com: Diary of an Engine Diversity Absolutist
- 2020-05-26 bkardell.com: Web Engine Diversity and Ecosystem Health
- 2020-05-26 kryogenix.org: Browsers are not rendering engines
- ...
[Qing An] Some articles or reports I find relevant:
- 1996-10 RFC2026 The Internet Standards Process -- Revision 3
- "In general, an Internet Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet."
- "Thus, a candidate specification must be implemented and tested for correct operation and interoperability by multiple independent parties and utilized in increasingly demanding environments, before it can be adopted as an Internet Standard."
- 2009-09 RFC5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard
- "Independent implementations should be written by different people at different organizations using different code and protocol libraries. If it's necessary to relax this definition, it can be relaxed as long as there is evidence to show that success is due more to the quality of the protocol than to out-of-band understandings or common code. If there are only two implementations of an undeployed protocol, the report SHOULD identify the implementations and their "genealogy" (which libraries were used or where the codebase came from)."
Related Sessions
Related Issues
- Process 167: define "independent"
- AB-memberonly 17: Determining implementation experience with independent browser engines (Member-only link)
- ...