Reintroduce the 'at least two independent implementations' SHOULD from the previous version of the charter.

[hober]

@dwsinger, @gkatsev, @nigelmegitt, and I had a call earlier today to talk about possible ways to resolve Apple's charter FO. One possibility is a "belt-and-suspenders" approach where we have the old charter language as well as the new charter language re: implementations.

This is an inelegant first pass at this. I made no attempt to fiddle with the surrounding wording or to make the resulting frankensteinian text cohere. This PR merely reintroduces the old text as a starting point for conversation.

---

Preview | Diff

[nigelmegitt]

Discussed on TTWG call today. Group did not want to approve/accept this change immediately, but preferred to give it more consideration and also see if other alternative resolutions are suggested.

[css-meeting-bot]

The Timed Text Working Group just discussed Rechartering status update, and agreed to the following:

• SUMMARY: Group discussed on call today. Ambivalent towards PR, would like Apple to generate other alternative suggestions.

The full IRC log of that discussion

<nigel> Topic: Rechartering status update
<nigel> Nigel: We had a number of pull requests open for ages on the draft charter, with approvals.
<nigel> .. Yesterday I just merged them.
<nigel> .. The one remaining is:
<nigel> -> https://github.com//pull/81 Reintroduce the 'at least two independent implementations' SHOULD from the previous version of the charter. #81
<nigel> Nigel: I've forgotten some of the details but I think Apple said they'd think about other alternative
<nigel> .. proposals.
<nigel> Gary: Yes they said they would.
<nigel> Nigel: Now we've had chance to consider this the question to ask ourselves is if we can live with Apple's
<nigel> .. proposal or if it is so against our changes that we can't accept it.
<nigel> Cyril: At least make the terms consistent in advancing to PR or advancing beyond CR.
<nigel> Nigel: They're the same thing, just described differently.
<nigel> Cyril: If we don't meet this SHOULD then we would have to justify it?
<nigel> Nigel: Yes
<nigel> Gary: I think we would likely need to do it anyway.
<nigel> .. Apple's position is they would prefer that SHOULD be a MUST.
<nigel> Pierre: I think that leaving that second paragraph in just postpones the discussion.
<nigel> .. The root of what's happening here is that folks are trying to impose in Charters things that
<nigel> .. are not imposed in the Process.
<nigel> .. We can jump around this but we're delaying the discussion.
<nigel> Gary: That is what is happening because it's easier to do it that way, for better or worse.
<nigel> Pierre: It's usually easier to deal with these things up-front.
<nigel> .. Vivid memories of EME where this didn't help.
<nigel> .. If we don't do it now we'll have it again very soon.
<nigel> Gary: We did ask Apple to restart the Process level discussions.
<nigel> Pierre: For the record, I've been trying to have discussions with Apple about this and they have not been responsive.
<nigel> Nigel: As Gary says, the intent is to roll it into Charters first, because they consider it to be
<nigel> .. better to have experience in Charters first before changing the Process.
<nigel> Pierre: For the HRM I don't think we are likely to see a second implementation.
<nigel> Nigel: I think they would argue that in that case it ought not to be a web standard.
<nigel> Pierre: I don't understand the goal.
<nigel> Gary: Their goal is to demonstrate interop so that two independent readers of the spec generate the same
<nigel> .. outcome from their implementations.
<nigel> Pierre: I would equally claim, as suggested by Nigel a while back, that have two folks, one independently
<nigel> .. creating content and another creating an implementation, agree on the expected result, then
<nigel> .. that is an equally legitimate test.
<nigel> Cyril: You could claim that there's an implementation behind the content creation so you would claim
<nigel> .. there are two implementations.
<nigel> Pierre: Exactly. I think one creates content and one processes it is a fine test.
<nigel> .. I am concerned that using this to gauge industry interest would be a terrible tool.
<nigel> Gary: I don't think it's that.
<nigel> .. They consider that just creating content isn't good enough.
<nigel> Pierre: I see no factual basis for why this is not a good way to test the interpretation of a spec.
<nigel> Gary: One potential issue is that somebody could be writing it against the HRM as opposed to against the spec.
<nigel> .. They could be testing their content against the implementation.
<nigel> Pierre: Sure, and someone could fork an implementation, tweak it, and call it theirs!
<nigel> Nigel: This comes down to whether or not the Chairs could tell a story to exit CR to the Director
<nigel> .. based on this Charter and succeed.
<nigel> .. By the way, another option is to keep their PR wording and modify our additional wording to clarify the intent.
<nigel> .. For example it may be that we've slipped into TTWG jargon about implementation types and the AC
<nigel> .. does not generally share the same understanding of our terminology.
<nigel> Gary: Yes, it could be that changing "content" to "content creating implementation" would help.
<nigel> .. The other thing is how many times can we extend the Charter before they say No?!
<nigel> Pierre: The other option is to stay at CR forever. I don't think that's a good solution.
<nigel> Gary: Agree that's not a good solution.
<nigel> Nigel: Also agree, but note that Apple's view was that due to other changes e.g. to patent policy,
<nigel> .. being at CR permanently is a lot safer than it used to be.
<nigel> .. I quite strongly feel that staying at CR forever is a really bad message to send, particularly if it becomes
<nigel> .. a widespread practice across W3C.
<nigel> Cyril: Apologies, have to leave the call.
<nigel> Nigel: Practical choices:
<nigel> .. 1. Reject the PR
<nigel> .. 2. Ask Apple for other alternatives
<nigel> .. 3. Accept the PR
<nigel> Gary: We can ask Apple for alternatives regardless.
<nigel> Nigel: If we accept the PR they won't generate alternatives.
<nigel> Atsushi: For option 1, our extension of the current charter is until the end of June.
<nigel> .. Accepting 1 will result in FO Council, and I assume that we proceed with the current
<nigel> .. checklist. I can't believe that FO will be the result to meet with our desire.
<nigel> .. For option 3 it is simpler, we can just recharter as soon as possible.
<nigel> Gary: My thought is we ask Apple for alternatives and then before the Charter expires,
<nigel> .. we could then potentially accept the PR and recharter, and push Apple to restart the Process discussions.
<nigel> Nigel: Listening to the discussion I think my conclusion is we do want to assess other alternatives,
<nigel> .. and the lack of strong statements in favour or against means we are all sitting on the fence.
<nigel> Atsushi: We should push Process CG and Apple to consider these implementation related items within
<nigel> .. the Process.
<nigel> Nigel: I have raised issues before and it is a matter of reinvigorating discussion on those issues.
<nigel> Atsushi: I should rephrase: I would like Chairs to push issues into Process CG as soon as possible.
<nigel> .. Are they open already?
<nigel> Gary: There are several
<nigel> Nigel: Yes we do
<nigel> Atsushi: Ah, sorry for that.
<nigel> github: https://github.com//pull/81
<nigel> SUMMARY: Group discussed on call today. Ambivalent towards PR, would like Apple to generate other alternative suggestions.

[nigelmegitt]

@hober the other open PRs have now been merged - it would be helpful from a preview perspective if you could rebase this change, please.

[hober]

@hober the other open PRs have now been merged - it would be helpful from a preview perspective if you could rebase this change, please.

Done!

[palemieux]

What does "implementation" means in this context? For example, what does "implementation" refer to if a specification defines multiple conformance classes, implicitly or explicitly: document, creator, validator and renderer?

[dwsinger]

What does "implementation" means in this context? For example, what does "implementation" refer to if a specification defines multiple conformance classes, implicitly or explicitly: document, creator, validator and renderer?

I think that maybe the point is that it has the same ambiguity as previously-approved charters, and does not answer that question any more than we used to.

[palemieux]

I think that maybe the point is that it has the same ambiguity as previously-approved charters, and does not answer that question any more than we used to.

As a contributor and implementer, and because this has risen to the level of formal objection, I would like to know -- otherwise how is one expected to plan work. I expect others wish to know as well.

[cconcolato]

The first sentence of section 3 says:

In order to advance to Proposed Recommendation , each normative feature is expected to meet the requirements set out in §3.1 to demonstrate adequate implementation experience .

Your PR adds:

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.

The sentences are very similar. It seems that whatever decision is taken, only one of the 2 sentences should be kept.

[nigelmegitt]

It seems that whatever decision is taken, only one of the 2 sentences should be kept.

Indeed. One of the reasons TTWG was ambivalent about accepting this change was due to the clunkiness of the resulting language.

In terms of decision, my understanding is that this is now going through the FO Council experiment, so unless we resolve the FO some other way (which is not going to be this PR, as it stands now) then the FO Council will be making that decision.

[nigelmegitt]

No consensus to adopt this within TTWG, putting a Request changes review in to block merge pending FO Council.

[nigelmegitt]

Closing this since we now have a proposal from the FO Council at #84 .