[Standards] Adding namespaced content to Registry entries

Jonas Schäfer jonas at wielicki.name
Thu Jun 4 13:58:10 UTC 2020

On Mittwoch, 3. Juni 2020 22:50:26 CEST Dave Cridland wrote:
> On Wed, 3 Jun 2020 at 16:30, Jonas Schäfer <jonas at wielicki.name> wrote:
> > Hi everyone,
> > 
> > Flow and I got in a discussion about whether it is OK to add foreign,
> > namespaced elements to Registry entries.
> > 
> > I’m not sold to either side, I was just curiously wondering if there’s
> > precedent and if it’s considered a good, terrible or neutral idea by the
> > community.
> > 
> > The context (for better understanding) is PR#949:
> > https://github.com/xsf/xeps/pull/949
> > 
> > Please weigh in if you have a strong opinion one way or the other.
> I think this is not allowed.
> But I suspect it should be.
> If you are not of a pedantic persuasion, look away now.
> As I understand XEP-0053, there's actually no need to run registrations by
> the Council (excepting if the Registrar declines a registration; then the
> Council acts as an appeals body) - the only reason this has touched the
> Council is that it's an update to an existing Active XEP. It would be
> perfectly possible (and might even be preferable) to add items to
> XEP-0157's FORM_TYPE within a new XEP, or just by asking the Registrar
> nicely (by email). The simple fact that one can add to the registry (or
> alter existing entries) without touching the XEP that defined the registry
> both imposes restrictions and is the very point of a registry (rather than,
> say, a definitive list in a XEP).
> The Registry is defined quite clearly in XEP-0068, including the XML format
> it takes, and there is no mention of form validation there (or default
> options, by the way). Perhaps more to the point, the rendered version of it
> at https://xmpp.org/registrar/formtypes.html doesn't include any validation
> information - merely blindly adding extension elements to the registry
> would mean that the rendered versions need updating. Therefore I think the
> definition of a registry has to be considered exhaustive.
> So, in conclusion of the status quo, I don't think adding validation (or
> other elements within an arbitrary namespace) is allowed.

Excellent summary of what my unverbalised thoughts were regarding the linked 

> That said, I think there's two useful things we can do here:
> 1) Validation information is clearly useful in this case; we should add
> that to the XEP-0068 registry by an update to XEP-0068 *and* an update to
> whatever stylesheet generates the registry page.


> 2) In the longer term, we should step back and decide what we actually want
> our registry process to be. It feels as though we're too often updating
> existing XEPs to add small features which could easily enough be either a
> new XEP (maybe) or a registry submission. We should ensure that even
> private additions are easy (though ideally, we can avoid that by use of
> URI-based namespacing). I would argue we should make registries operate by
> PR or email as needed, and have the registry stipulate requirements (like
> "Open Specification required", or "FCFS", or whatever).

Well. Yeah. Our registries are broken, which is a known fact. Fixing them is 
currently blocked by "out of ideas with the current constraints". We can chat 
about this in iteam@ in more detail if you’re interested (but I think iteam 
details are off-topic for this list).

If they weren’t broken, registry submissions would be nice and yes, this PR 
would not have passed by council (though I would’ve probably sent it to 
Council anyways due to the validation thing).

We also have a bunch of other stuff which needs to be fixed/updated in 
registries, and that list only gets longer unfortunately.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200604/5389c1b8/attachment.sig>

More information about the Standards mailing list