w3c
Glossaries: a different pattern needed?
In a WHATWG call (https://github.com/whatwg/html/issues/10496#issuecomment-2261589782) we were discussing the need for definitive definitions of terms that have some weight, but maybe aren't a full-on REC-track kind of thing. In WHATWG-space, this is generally in the WHATWG Infrastructure spec: https://infra.spec.whatwg.org/. Unfortunately, right now there are some terms defined in Infra and also in the I18n Glossary (https://www.w3.org/TR/i18n-glossary/) - the I18n Glossary should really be the definitive source, but it's just a group draft note, because it's necessary to be a living document, relatively easily updated.
This issue is to pose the question - should we have some type of path for this kind of definition glossary that is easier to update than a CR. but more normative than just a Note? (a la the way we enabled a different path for registries).
Can we re-use the registry track? What is a glossary, after all, besides a registry of terms and their definitions? :)
I am the editor of an AB Draft Glossary: https://w3c.github.io/AB-public/Glossary This may be the start of an answer to this question.
Can we re-use the registry track? What is a glossary, after all, besides a registry of terms and their definitions? :)
Possibly, especially if we allow groups other than WGs to maintain registries, as is proposed in https://github.com/w3c/process/issues/902.
I was once the editor of a W3C glossary too. Creating them is easy.
The important thing is to actually keep maintaining and using the same one.
The registry process seems good enough for this purpose.
more normative than just a Note
(setting aside that Registries are really no more normative than Notes)
I'm not convinced that Registry is the right mechanism here, because it seems from the issue description that folk want more than just a glossary, but actually to have normatively referenceable definitions, and as §6.5.2 Publishing Registries says:
A registry report or registry section is purely documentational, is not subject to the W3C Patent Policy, and must not contain any requirements on implementations. For the purposes of the Patent Policy [PATENT-POLICY], any registry section in a Recommendation track document is not a normative portion of that specification.
What I had started in https://w3c.github.io/AB-public/Glossary was largely an index of referenceable defintions, pointing to existing documents where they were already defined. That could work as a registry. As for those terms that are defined directly in the document (because they had no other definition anywhere), I think it's still be OK to reference them. What wouldn't be OK is trying to sneak into those implementable requirements and things that could potentially need patent coverage. But if you look at the few things I had put in there as a starting point, they seem pretty safe in that respect: https://w3c.github.io/AB-public/Glossary#undef
I suspect we have all we need in our publication toolchain, especially now that https://github.com/w3c/process/pull/972 has landed. The problem is still worth solving, but I don't think it's a process problem, and thing we should transfer this to the AB
What wouldn't be OK is trying to sneak into those implementable requirements and things that could potentially need patent coverage.
I doubt it would be sneaking, most of the time. The definitions mostly will provide scope for implementable requirements. Even if they don't appear on the surface to be imposing requirements, the question to ask is: if the definition changed, would any normative requirements in referencing specifications effectively be changed. This is really hard to monitor and police.
The Process CG decided to close during its 2025-10-08 meeting, as there seemed to be nothing left to do in terms of Process.
If people think a registry managed by the AB is the right way to maintain a Glossary, then we note that this is now possible.
During the discussion, another existing glossary was mentioned, that people might want to know about: https://dontcallmedom.github.io/webdex/
(marking as accepted in Process 2025, as this is when the ability for the AB/TAG to create registries was added)