Survey about group registries

[tidoust]

The Media Working Group maintains the MSE Byte Stream Format Registry, the EME Initialization Data Format Registry and the EME Stream Format Registry. These registries have been published as Working Group Notes. In practice, W3C has no standard way to maintain registries.

The W3C Process Community Group and the Advisory Board are currently drafting a process for registries (see a list of related issues) and W3C is conducting a survey across groups on the topic.

This survey asks follow up questions to the TPAC 2020 Process 2021 presentation. Main questions for the group are the following:

Do we need a Candidate Recommendation phase?

Would your group find value in signalling to the community in a Candidate Recommendation (CR) phase for the Registry Definition to ask “we think we're done, please check, before we ask for a Proposed Recommendation (PR) transition” even though pure registries do not have a “call for implementations”, or should we give registries a process that skips CR? (See Do we need both CR and PR?)

• Registries should have a CR phase to experimentally validate the Working Draft before requesting AC approval.
• Registries do not need a CR phase to experimentally validate the Working Draft before requesting AC approval.
• No opinion

Separate track?

The normal practice is for registries to be distinct, and different from, the specifications that define, embed, or use them. They are maintained differently, they have different approval status, and therefore are published separately. Does your group think we should define registries as being on the W3C Recommendation Track, or should they have their own separate W3C Registry Track (which clearly detaches them from the W3C Patent Policy)? (See Separate track?)

• Separate track is better
• Re-using Recommendation Track as-is is better
• No opinion

Registry definitions and tables

Does your group think your registries benefit from the ability to publish definitions and tables separately? (Not just separate files within the same publication on /TR, but under completely separate /TR shortnames?) (See Must be together? and May be separate?)

• Yes, we need this
• We'd use it if it was available but can live without
• We would not use this
• We think it's harmful

Further comments are welcome as well.

I'd be interested to get the perspective of the group. Any feedback?

Deadline for the survey is 10 February 2021.

[mounirlamouri]

@tidoust is it customary for the folks running the group to answer these on behalf of the group or should we run a quick survey only accessible to members?

Alternatively, our next meeting is the 9th of February so we can put that as an agenda item.

[tidoust]

@tidoust is it customary for the folks running the group to answer these on behalf of the group or should we run a quick survey only accessible to members?

I don't think there is anything customary for such surveys. It makes sense to have a discussion in the Media WG because the group maintains a bunch of registries and publication as an "informal" WG Note feels non ideal.

Holding the discussion during next call should be enough to assess choices or raise questions and comments. If people feel strongly about the topic, I encourage them to chime in here by then! (or ping you or me)

[tidoust]

Discussed during February 2021 call. I filled out the survey on behalf of the group accordinly.

[chcunningham]

@tidoust FYI, the legal / patent experts @ Google are still reviewing this question. Particularly as phrased during the call: "How should patent policy apply to registries?". Waiting for their conclusions. Let me know if you're working under any deadlines to get this answered.

[tidoust]

@chcunningham That is too late for the group survey that initiated this issue, but certainly not too late to inform the discussion on possible process changes to accommodate registries. I encourage you/them to engage with the W3C Process CG directly once conclusions are known: https://github.com/w3c/w3process/issues?q=is%3Aissue+is%3Aopen+registries