Are the rules for updating Registry Definitions appropriate?

[nigelmegitt]

Following discussion of the practicalities of including Registries in Rec track documents at https://lists.w3.org/Archives/Public/spec-prod/2023OctDec/0003.html it seems like there may be a Process bug regarding the process for updating Registry Definitions.

§6.5.2 says that registry sections are "purely documentational". What does this actually mean? I initially read it as being "informative", or alternatively "can be changed outside the normal Rec track document process" but §6.5.1 requires that every registry table has a defined change process.

It would be absurd to require a strict process for how to change a registry data table but then allow that process itself to be modifiable without its own change process; I doubt that's the intention, but it seems to be the effect at the moment.

Another observation is that §6.5.2 refers to a singular Registry Section, but practically, as per w3c/dapt#196 for example, within a Rec track report incorporating registries, it makes sense to split the components of the Registries into different sections. Large parts of the definitions section are best placed away from the registry data tables themselves, which are best placed in the sections of the specification where they're used and relevant, because they're easier to read there.

So some attention is needed to check if the Process gets the cardinality of each type of section right.

[fantasai]

The Registry Definition has to follow the same rules as changes to other normative sections of a REC. Changes to tables are subject to the rules in the Definition. The intention of the Process text there is to clarify that the Definition can't be normative on implementations and has no Patent Policy implications, but probably it's not very clearly explained.

[fantasai]

Wrt splitting the various parts of the registry for readability... I think that should be fine, and we can clarify that the Registry Section can in fact be split into multiple sections in various parts of the document. (We might want to call it something other than a Registry Section in that case, but I'm unsure what.) It's just got to hang together as one Registry Section thing, even if the relevant text is split up for editorial purposes. :)

[dwsinger]

Let's try to explain the terms here, and I think it will become clear.

1. There is text in a Rec-track document that defines the registry, its contents, management etc. That's part of the Rec and is subject to rec-track normal change management and approval. That's the Registry Definition.

2. one of the places you can put the registered material, the registry tables, is in the document that is also the Rec. That section needs to be clearly delineated as being the registry contents; from the point of view of the rec-track document it is purely informational and the rules for its revision are not the rules of rec-track documents, but the rules for that Registry. That's a registry section.

I hope I got this right. And that it makes sense.

[nigelmegitt]

probably it's not very clearly explained

I think that's exactly the issue!

[nigelmegitt]

@fantasai said:

(We might want to call it something other than a Registry Section in that case, but I'm unsure what.) It's just got to hang together as one Registry Section thing, even if the relevant text is split up for editorial purposes.

I think the concept of a single Registry Section isn't actually that helpful. Rather, it would make sense to say if the specification includes any (one or more) Registry Definitions, and if it includes any Registry Tables. Since they're separable concepts, what's the Registry Section here?

For example, consider a Rec track report that references an external document for the Registry Definitions, but inlines the Registry Tables for those definitions. (putting aside the conundrum of the two documents somehow cross-referencing each other)

Related, @dwsinger 's comment:

There is text in a Rec-track document that defines the registry, its contents, management etc. That's part of the Rec and is subject to rec-track normal change management and approval. That's the Registry Definition.

This makes sense conceptually - the problem is in getting to that result from the Process wording.

[dwsinger]

what's the Registry Section here?

I believe a (not the) Registry Section is the body of a registry, some/the tables, inlined into the document.

[nigelmegitt]

I believe a (not the) Registry Section is the body of a registry, some/the tables, inlined into the document.

It would make sense if the registry section is the table plus links to the registry definition but a strict reading right now is that it must include the registry definition, i.e. the table is only a subset of what is defined as a registry: this maybe helps identify the Process issue more clearly. §6.5.2 says:

Registries can be published either as a stand-alone technical report on the Registry Track called a registry report, or incorporated as part of a Recommendation as a registry section.

and §6.5 Registries says:

A registry has three associated components:

• the registry definition, defining how the registry tables are structured and maintained
• one or more registry tables, holding the data set represented by the registry (the registry data)
• one or more referencing specifications, which make use of the registry

The wording "associated components" is not clear: formally, I think it means that those components are not part of the registry, but that cannot be right. In particular, a registry without any registry tables would make no sense at all.

Proposal

I think what we need is, a little differently to what Process says today:

• A Registry is a Registry Table and its entries.
• A Registry Table must be "hard" linked to a Registry Definition, i.e. by "hard" I mean there's a normative provision that a specific Registry Definition applies to that Registry Table.
• A Registry Report (standalone doc) or a Registry Section (in a Rec-track document) must include one or more Registry Tables and MUST either 1) include or 2) normatively reference the Registry Definition for each Registry Table.
• The Registry Definition is subject to document-level transition requirements.
• The Registry Table's set of Registry Entries is mutable outside the document-level transition requirements by following the change process in the applicable Registry Definition.
  • I worded that carefully to avoid allowing the Registry Table's Registry Definition to be changeable outside the document-level transition requirements.

Probably everything else stays the same.

This would probably clear up the confusion...

One consequence is that it would not be possible to publish a Registry Report that only contains a Registry Definition, for the purpose of normatively referencing it from another document. Instead, a different track would need to be chosen, e.g. Rec track, to allow the normative reference to be made.

[TallTed]

I wonder whether just changing three associated components to three components might be enough to resolve the confusion described above. There may be no further changes necessary.

[nigelmegitt]

@TallTed I'm all in favour of making the smallest changes that achieve the goals; I'm struggling to see how that one change would do so fully in this case though. It doesn't clear up the confusion about which parts of a Registry are subject to which change processes for example.

[fantasai]

@nigelmegitt Drafted a PR that tries to address the confusion at #807 ; let us know what you think?

[nigelmegitt]

Sorry for the slow review here. The changes in #807 are good, but I don't think they resolve all the issues. In particular, I'm seeing:

• There is still confusion between the registry definition and the registry tables, and what constitutes a registry report or embedded registry.
• The wording in §6.5 that says that a registry has associated components is still present and leads to confusion.
• For example, I find it hard to navigate to an answer about the change control process that applies to the registry definition itself rather than the registry entries. Especially in an embedded registry, it needs to be clear that it is/is not subject to the change control process associated with the technical report in which it is embedded.

[frivoal]

The wording in §6.5 that says that a registry has associated components is still present and leads to confusion.

Fair enough. The wording in question is:

A registry has three associated components:

• the registry definition, defining how the registry tables are structured and maintained
• one or more registry tables, holding the data set represented by the registry (the registry data)
• one or more referencing specifications, which make use of the registry

In my mind, a registry consists of the first 2, and is pointless if there isn't the third thing, but the specs that make use of the registry aren't part of the registry, so I do agree that this list is unbalanced.

I wonder, do we lose something if we remove that third bullet, and rephrase the sentence announcing the list to "a registry consists of"?

[nigelmegitt]

I just re-reviewed the current draft's section §6.5 The Registry Track. I'm much happier now seeing the recent changes. In particular I found 6.5.3. Updating Registry Tables clear in defining a specific call-out explaining how registry tables can be changed, and how the technical report that contains them can be republished, and that there is no such equivalent text for registry definitions.

I wonder, do we lose something if we remove that third bullet, and rephrase the sentence announcing the list to "a registry consists of"?

@frivoal I do not think so, no. In fact, it's a good idea to move that third bullet out of the list, and rephrase to include "consists of".

Consider the scenario in which a non-W3C SDO maintains the last referencing specification for some registry. It's out of W3C's remit to prevent that SDO from removing their reference, but at the moment when they do, apparently the registry would cease to be a registry, since it only contains a registry definition and one or more registry tables, but there are no referencing specifications. That would be an absurd situation.

My current status on this is that in principle such a change (to the intro to §6.5) should resolve the issue for me.

[dwsinger]

There will always be an interval between the registry creation and its first reference, and this appears to introduce a paradox – the registry doesn't exist until it is referenced, but surely no-one can reference it until it exists.

I also contest the idea that a reference to it is needed. Maybe the code-points in it are merely implemented? I think this might be trying to say that a registry is either embedded in a Rec or referenced by a Rec., but it doesn't say this very clearly.

[frivoal]

@dwsinger I think your comment is in support of my suggestion to

remove that third bullet, and rephrase the sentence announcing the list to "a registry consists of"

but I am not 100% sure. Can you confirm?

[frivoal]

Just made #818, which I think will close the remaining concerns here.

[darobin]

For context, I landed here because I have the problem of chartering a registry definition with normative requirements that I think could have PP implications. The general form is "In order to be eligible for inclusion in table X, an entry must be defined so that it complies with Some Base Interface or Some User Agent Requirements."

I looked at #818 and I'm still confused. If I track through the notions, here's how I trip up:

1. 6.5.6 says "A registry report or embedded registry is not subject to the W3C Patent Policy, and must not define any requirements on implementations."
2. Following the definition links, I get to 6.5.2 saying "Registries can be published either as a stand-alone technical report on the Registry Track called a registry report, or incorporated as part of a Recommendation as an embedded registry." So registry == (registry report | embedded registry) in terms of how they are instantiated. OK.
3. Again, following the definition link for registry, I hop to 6.5 that says (with @frivoal's change) "A registry consists of" and lists definitions and tables.

Presumably, (1) above enumerates all the instantiations of a registry as listed in (2), so that means that registries as a whole aren't subject to the PP. But if a registry cannot be subject to the PP, that means that none of its parts can be either. I think that's true of tables, but I don't think it is of definitions. I think that definitions can (should!) be normative, and given how broad and vague patents can be, I reckon that anything that can be normative could have PP implications.

[dwsinger]

Thanks @darobin . I think we may need to do more cleaning up of writing to make this clearer. The definition of a resgistry, its rules, content, approval regime, and so on, are all in the Definition, which has to be in a Rec., widely reviewed, subject to the PP, and so on. Anything mandatory is in the definition ("all implementations MUST implement the Nonce method, in order to test interoperability", for example).

the tables at that point are simply rows of "The value XX means YY as defined in ZZ". It's the rules for ZZ that tell you what the status (including under what policy, if any) of implementing XX is. So if "AVC" means the H.264/AVC standard as published jointly by ISO and ITU, then you know you're under the joint PP of ISO and ITU.

Now you know what I think the intent is, does it make your case easier to sort out?

[darobin]

@dwsinger I understand the intent and I'm glad it aligns with what I want, thanks :) It makes more sense that way. But I think that 6.5.6 contradicts that intent since it applies (transitively) to registry _definition_s as well.

Maybe the easiest fix is for 6.5.6 to state instead: "A registry table is not subject to the W3C Patent Policy, and must not define any requirements on implementations."

[dwsinger]

Sounds like a drafting bug in 6.5.6 indeed

[css-meeting-bot]

The Revising W3C Process CG just discussed Clarify what a registry is made of, and agreed to the following:

• RESOLVED: Merge #818
• ACTION: Florian, check with Nigel if the issue can now be closed.

The full IRC log of that discussion

<fantasai> Subtopic: Clarify what a registry is made of
<fantasai> github: https://github.com//issues/800
<fantasai> -> https://github.com//pull/819
<fantasai> florian: Follow-up from a previous PR
<fantasai> ... Nigel had pointed out that there's some confusion about what a registry *is*
<fantasai> ... had various "associations" but doesn't say what it consists of
<fantasai> ... referencing specifications aren't *part* of the registry
<fantasai> ... you still have a registry without such specs, it's just useless
<fantasai> plh: Any other comments/questions on this PR?
<fantasai> RESOLVED: Merge #818
<fantasai> ACTION: Florian, check with Nigel if the issue can now be closed.

[frivoal]

@nigelmegitt we've merged #818. Is that good enough to close this issue, or are there lingering concerns?

[nigelmegitt]

@frivoal yes, it's good enough for me, for the issue I raised - you may want a separate issue for @darobin 's additional issue, or resolve it here first though?

[fantasai]

I think if @darobin or @dwsinger want to raise additional issues, they should do those separately. :) Gonna declare this one closed.