Mark evidence, termsOfUse, and refreshService extension points at risk

[msporny]

This PR marks the evidence, termsOfUse, and refreshService extension points at risk. It does this in two places: 1) the existing section, so implementers know the feature is going away if they can't demonstrate two interoperable implementations, and 2) the reserved properties table such that the reservation will be deleted, but the section will remain in the spec, if there are enough implementations.

---

Preview | Diff

[iherman]

To be honest, I am wondering about the combination of "at risk" and "reserved".

"At risk", in the W3C jargon, has a very specific meaning (as described in the proposed text): either the feature makes it though the CR criteria, and then it is a bona fide normative feature, or not, in which case it is taken out of the spec. It is simply gone. So far so good.

In my mental model a "reserved" property (or class) is something that the WG decides not to standardize at this point, but "reserves" the term itself for possible future use. In other words, it is taken out of the standardization process of the current WG, but we try to avoid future collision by "reserving" the term because we know there are people using them, albeit not in properly interoperable way. Again, so far so good.

But how would I describe a reserved "at risk" feature? If it makes it, ie, if there are two implementations (if this is our exit criteria) then why would not it be a clear standard feature? Ie, not reserved. If it does not make it, why not keep it as "reserved", why remove it? And, by the way, why would we even look at their implementations during the CR phase, if they are reserved? Isn't the idea that we would not use WG time with those terms any more?

As far as I am concerned:

• We may declare some terms as reserved right now. Once they are reserved, we do not deal with them any more, they are not part of a CR process, ie, "at risk" does not apply to them

• We may decide that "at risk" of a (hitherto) normative feature in our case may mean that features are added as "reserved" terms (instead of being removed altogether of the document) if there are significant deployment of the term, but they do not pass the bar we are setting for CR (eg, the implementations are not interoperable). This is bending the rules of the W3C process a bit, but we may be able to argue for this when the time comes, using the argument that fully remove those terms might create disturbance on the market place (EPUB 3.2 did face a similar situation).

  (Some terms may be at risk with the full power of the process, ie, they might be removed if their fail on CR.)

(Sorry if I come in late with this discussion.

[TallTed]

I'm generally in favor of this path forward. It would be better, to my mind, if the feature AT RISK comments mentioned that those properties would be reserved if they were removed from the spec, similarly to how the property reservation AT RISK notes mention that the property reservation would be dropped if implementations of the feature were sufficient to keep the feature in the spec. I've added specific change requests to this effect in this review.

[decentralgabe]

It seems strange to mark properties at risk if they have registered types in the specs directory though I understand the requirement to have two testable implementations. Do we have a clear way to guarantee this requirement?

For example, what's stopping someone from creating two anonymous accounts with two different implementations? What happens if one of the implementations goes away (like a company shuts down that created it)?

[TallTed]

@decentralgabe — The point of the "two independent implementations" is to ensure that a spec is comprehensible and implementable by people preferably outside the working group, and that interop between such independent implementations is achievable. These implementations need not be perpetually available; they only need to be around long enough to test the interop and build our implementation report, which is our "clear way to guarantee this requirement."

Someone creating two anonymous accounts with different implementations has never happened in my 20 years experience with W3 WGs. It's a pretty heavy lift for something with what I'd expect to be a pretty small reward. It's possible, but pretty unlikely.

[OR13]

Approving (because of exhaustion).

We should be pushing to remove sections which the working group cannot prove have demonstrated interoperability, marking things at risk, is in my opinion just making more work for the group.

It would be better to add features that have consensus and demonstrated interoperability, and remove features that cannot meet that bar.

[msporny]

Substantive, multiple reviews, changes requested and made, no objections, merging.