Registries don't meet Process requirements

[nigelmegitt]

The Codec Registry and the VideoFrame Metadata Registry don't meet the registry requirements of the Process.

For example, they aren't showing as "Registry" as the document type, and they don't link to § 6.5 The Registry Track - that latter requirement is defined in 6.5.2. Publishing Registries.

I've summarised some of the requirements for Registries in the discussion at w3c/ttwg#241 and shared my thinking about registry definitions for TTWG specifications, which may be relevant here too, since there's not really anything timed-text related about them. See also the draft boilerplate text at w3c/ttwg#243 - at the very least that does the (not yet well documented) Respec thing needed to make the document look like a Registry track document.

[dalecurtis]

@tidoust @chrisn do you have suggestions here? Editors have no idea what this means :)

[chrisn]

Thanks, yes, I'll review this when I'm back at work next week.

[tidoust]

For example, they aren't showing as "Registry" as the document type

You linked to the Editor's Draft of the registry, not to the published version, e.g. WebCodecs Codec Registry. The published version has the right "Draft Registry" type. The Editor's Draft is just a draft. There is no specific status in ReSpec and Bikeshed to identify the non-published draft of a Registry document. Editor's Draft seems good enough to me.

and they don't link to § 6.5 The Registry Track

I would argue that the sentence "This document was published by the Media Working Group as a Draft Registry using the Registry track", in the Status of This Document section, is intended to cover that requirement. That said, the link is to $6.1 Types of Technical Reports and could perhaps be updated to rather target $6.5, or the Process could perhaps be amended to be less strict about that requirement. If the former, the link cannot be updated without first updating PubRules. @deniak FYI.

[nigelmegitt]

There is no specific status in ReSpec and Bikeshed to identify the non-published draft of a Registry document.

      var respecConfig = {
        specStatus: "RY",

works.

That said, the link is to $6.1 Types of Technical Reports and could perhaps be updated to rather target $6.5, or the Process could perhaps be amended to be less strict about that requirement.

It does seem strange that Registry track documents are the only ones that are required to link to an explicit process section, but it is very clear that it wants a link to §6.5 and not §6.1.

[tidoust]

The "RY" (or "DRY") spec status is a good status for the version of a spec published under https://www.w3.org/TR/ but the version published under https://w3c.github.io/ is an Editor's Draft, and its status should reflect that. For specs on the Note track, Bikeshed has a "NOTE-ED" status (which does not exist in ReSpec as far as I can tell). Introducing new statuses in authoring tools for Editor's Drafts of a registry spec seems overkill though.

[nigelmegitt]

Introducing new statuses in authoring tools for Editor's Drafts of a registry spec seems overkill though

I disagree, I think it seems appropriate.

[chrisn]

Is there a more appropriate home for this tooling discussion? This doesn't seem to be particularly WebCodecs specific (unless there are other changes needed to these registries?)

[tidoust]

Is there a more appropriate home for this tooling discussion? This doesn't seem to be particularly WebCodecs specific (unless there are other changes needed to these registries?)

Yes, for cross authoring tools discussions, the spec-prod@w3.org mailing-list (with public archives) would be the most appropriate place.

For ReSpec: https://github.com/w3c/respec/issues. For Bikeshed: https://github.com/speced/bikeshed/issues

[padenot]

Is there anything we should do as editors here? We still have no idea what all of this means, but we're happy to tag our documents appropriately, of course.

[nigelmegitt]

@padenot yes, you need to include the required reference to Registry track . For an example, see the Respec generated SOTD text at https://ttml.w3c.himor.in/boilerplate-registry-20230316.html

[chrisn]

I have filed https://github.com/w3c/w3process/issues/725 to ask whether there's a real need to link to the Process at all, as this isn't required for other types of report.

@deniak has filed https://github.com/w3c/specberus/issues/1713 to update the link to point to 6.5 rather than 6.1 .

@tidoust already commented on whether ED is the appropriate status for the draft on w3c.github.io. But I agree that the current status seems confusing. I see @nigelmegitt has filed https://github.com/w3c/respec/issues/3594 for Respec.

So I suggest waiting on the outcome of those conversations before making changes here.

[chrisn]

I'll re-open, as I think commit https://github.com/w3c/webcodecs/commit/d74a047f7605304eba25941b7bd331058612a6ff mistakenly linked to this issue.

That said, https://www.w3.org/TR/webcodecs-codec-registry/ does have the link to the Registry Track. I'll check what's left to do to resolve this issue.

[edit] The suggestion is that the Editors Draft at https://w3c.github.io/webcodecs/codec_registry.html should also have the link.

[aboba]

@chrisn Is there anything else we need to do, or can we close this?

[chrisn]

I think this is fine as is, if new draft document types get added to the tooling we can revisit, but as @tidoust said, the actual registry on /TR has the appropriate links.