Multiple implementations point

[cwilso]

Per @fantasai comment:

We technically don't require multiple implementations or open test suites (though it's definitely recommended and what most groups do)... I also want to try to make this more of an active point than a "we believe" point, maybe something like

We solicit multiple implementations and develop open test suites in order to ensure interoperability and fitness for purpose and facilitate the broad adoption of our standards.

(I don't actually like this sentence much, but just wanted to get an idea across as something to play with.)

[michaelchampion]

How about phrasing it (and other) points in future-tense / aspirational language? Something like "We will ensure interoperability with multiple implementations and test suites. This helps our standards be broadly adopted and credible."

[TzviyaSiegman]

we had a goal of avoiding terms like "we ensure" and "we believe" and using concrete action words. Is "we require interoperability" better?

[michaelchampion]

we had a goal of avoiding terms like "we ensure"

Who had that goal, where is it consensus on it expressed, and what is the rationale? (I do agree that "we believe" is not strong enough.).

But I'm comfortable with "we require evidence of interoperability. And even if the Process doesn't "require" multiple implementations and test suites, it seems OK in a future-looking document to say something like "we [strive for| prefer | aspire to have] solid evidence of interoperability from multiple implementations and test suites."

[fantasai]

Maybe

To facilitate broad adoption, we prove interoperability and fitness for purpose of our standards by soliciting multiple implementations and developing open test suites.

? (still don't love it though)

For reference, here's the current text:

We believe proven interoperable implementation is a requirement for broad adoption of standards. To ensure reliable interoperability, we require multiple implementations and open test suites for our standards.

[michaelchampion]

To be honest, I like the original best. The Process doesn’t “require” multiple implementations and test suites, but that can be the Vision for how the Team and Councils interpret the Process 🤷‍♂️

[cwilso]

I like the original best as well. It was intentional that we were making a stronger point about multiple implementations for "standard" status - but if we want to be softer, we could say

We believe proven interoperable implementation is a requirement for broad adoption of standards. To ensure reliable interoperability, we expect multiple implementations and open test suites for our standards.

[chaals]

@cwilso suggested

We believe proven interoperable implementation is a requirement for broad adoption of standards.

Actually, I believe a standard is a thing with broad adoption, and that a good one has proven interoperable implementation. But I also believe that there are broadly adopted standards that don't have this feature, and adoption is instead driven by other market factors.

[fantasai]

@michaelchampion Yeah, upon reflection I think I agree.

Taking @cwilso and @chaals's suggestions into account, how about

We believe proven interoperable implementation is critical for broad adoption of standards. To ensure reliable interoperability, we expect multiple implementations and open test suites for our standards.

(I feel like ‘expect’ is not the ideal verb here but I'm having trouble coming up with a better one.)

[wareid]

Maybe:

We believe proven interoperable implementation is critical for broad adoption of standards. To ensure reliable interoperability, we strive for multiple implementations and open test suites for our standards.

[chaals]

The key problem is that I do not believe that interoperability is necessary for broad adoption. It's a measure of whether the standard is a good one or not - somewhat orthogonal to the scale of adoption.

(Whereas the scale of adoption is a measure of the extent to which something is a standard in the first place).

[dwsinger]

I think we might be using interoperability in two very different meanings:

• there exist multiple independent implementations in public, it's a very multi-something world
• the spec is well enough written that independent implementations are, in fact, interoperable, and we don't have problems of a web divided into communities with different solutions to ambiguities

we want to prove the second, and we try to do it experientially by insisting that there are multiple interoperable independent implementations. But we don't need them all to be important in the market. Maybe we will end up with one vulnerable heartbleeding shared implementation, but that's a different problem

[igarashi50]

Another aspect is that we should consider interoperability in two different meanings.

• Independent implementations of all layers of technology where a W3C spec is one of them.
• Independent implementations of the layer of technology that a W3C spec defines.

For the public web, the first one is mandatory, but in other cases such as industrrial domains, the second one may be enough, assuming the inteperability of the other layers are ensured outside of W3C. I think W3C should requre inteoperability of independent implementations in one of the two meanings, depending on each W3C spec.

[cwilso]

1. to @igarashi50 's comment, I think we are just talking about implementation of the layer in the spec at hand, not the entire stack.
2. @chaals , I agree that interoperability is not a requirement for broad adoption - but I do believe it is a requirement to call something a Web standard. Otherwise, we are reopening the Pandora's box of "a single popular implementation can call their specifications standards". I think it is very important to make a strong statement here. The point of Web standards is to create interoperability.

[fantasai]

Thinking on it as I was walking home tonight, here's a different approach to the point:

We believe the purpose of standards is to enable multiple independent interoperable implementations, so we strive to prove the fitness of our specifications through open test suites and actual implementation experience.

Even in the cases where we end up with only one shipping implementation for whatever reason, we're writing the standard to enable more than one.

[chaals]

We believe the purpose of standards is to enable multiple independent interoperable implementations

I think that we say this bit already - and I would be happy to strengthen the way we say it. Anyway, that means we could start at "we strive..." for the purposes of this point.

[csarven]

Perhaps minor: re @fantasai 's #120 (comment) , consideration to change from "actual" to "adequate" since "adequate implementation experience" is already defined. Unless of course the intention with "actual" is intended to be narrower in the proposed text than what entails adequate. "Actual" is also already covered by "prove" earlier in the sentence.

[igarashi50]

1. to @igarashi50 's comment, I think we are just talking about implementation of the layer in the spec at hand, not the entire stack.

I think so, but we should clarify what interoperabiity means when we say "We will ensure interoperability with multiple implementations".

In the case of the web, a user agent supports the W3C, HTML, CSS, etc. with HTTP/DNS/IP etc. Interoperability would mean the full interoperability between a user-agent and servers on the Internet. In the otherc cases, a W3C spec that defines a data format but does not define the transport protocol, i.e. how to get the data. The data format is used with various transport protocols and a transport protocol may be defined in a industry or an orginization for the full interoperability.

We should consider that there is a W3C spec that does not require full interperability as like the web, but only require independent implementations of the layer defined by the W3C spec. I am OK if we are just talking about implementation of the layer in the spec.

[TzviyaSiegman]

Has this been satisfied in current draft @fantasai ?

[fantasai]

@TzviyaSiegman No, see #120 (comment) for the latest. I can make a PR, if that will help.

[fantasai]

@chaals I don't think we say anything about that anywhere else, currently?

@igarashi50 We're only talking about an individual spec. Each spec's purpose is interoperability of each implementation of that same spec.

[chaals]

@fantasai:

@chaals I don't think we say anything about that anywhere else, currently?

I think the last point in section 4 says it, and it's a clear theme of section 5. I don't think the "why" belongs in this section - if you think we're not clear enough about wanting interop IMHO we should edit section 5 to do so.

[cwilso]

fixed.

[cwilso]

Argh, no, wrong issue.