Re: [Standards] Adding namespaced content to Registry entries
On Wed, 10 Jun 2020 at 16:39, Florian Schmaus wrote: > On 6/3/20 10:50 PM, Dave Cridland wrote:> 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 > > I would like to avoid steering us in a world where we are required to > explicitly mark registry entries as extensible. Instead, registry > entries should simply assumed to be extensible. Just like we assume that > XML elements are extensible in XMPP, and for that reason also do not > explicitly declare that extensibility in your XML schemas (minus a few > exceptions). > > Can I use private extensions in registry entries? Can I use ones defined outside the XSF? Can I use a Historic extension within a Standards Track registry? Can I use an Experimental extension within a registry defined in Draft? Deprecated? Retracted? What about a versioned namespace when it becomes obsoleted by a new version? > Otherwise, we would need to perform this over and over again for every > add-on XEP that deals with elements that are part of a registry, for no > reason. Well, I think there is a reason, obviously, otherwise I wouldn't have come to the conclusion I did - just as we don't arbitrarily extend XEPs and tell people to just ignore the bits they don't understand when rendering, registries are formal documents, not protocols. > There is *no* advantage in explicit stating it: Just as on the > protocol level, either the extended additional information was > negotiated, and you are prepared for it, or you are not required to > understand it, and can simply ignore it while processing the registry > entry. Ah, but we do negotiate precisely what it allowed in a registry - it's in the registry definition. Moreover, the fact registry documents are held in Git as version-controlled XML documents is an implementation detail - the definition is actually much looser, and for example https://xmpp.org/extensions/xep-0030.html#registrar stipulates an HTML page, not an XML document (and indeed the registry entries are not defined to use any namespaces). Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding namespaced content to Registry entries
On 6/3/20 10:50 PM, Dave Cridland wrote:> 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 I would like to avoid steering us in a world where we are required to explicitly mark registry entries as extensible. Instead, registry entries should simply assumed to be extensible. Just like we assume that XML elements are extensible in XMPP, and for that reason also do not explicitly declare that extensibility in your XML schemas (minus a few exceptions). Otherwise, we would need to perform this over and over again for every add-on XEP that deals with elements that are part of a registry, for no reason. There is *no* advantage in explicit stating it: Just as on the protocol level, either the extended additional information was negotiated, and you are prepared for it, or you are not required to understand it, and can simply ignore it while processing the registry entry. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding namespaced content to Registry entries
On 6/3/20 5:25 PM, Jonas Schäfer wrote:> Hi everyone, > > Flow and I got in a discussion about whether it is OK to add foreign, > namespaced elements to Registry entries. I think registry entries should be just as extensible as the elements that are registered. This would also align nicely with the spirit of extensibility of XMPP. In this [1] particular example, it mimics how data form validation extend form fields on the wire protocol, at the registry layer. A situation where additional requirements and further information is only part of the textual specification and not of the registry entry, when it *could* be part of the entry, appears undesirable. - Florian 1: https://github.com/xsf/xeps/pull/949/files#diff-ebab582ef0efc48448fc287612a72d1dR208 signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding namespaced content to Registry entries
On Mittwoch, 3. Juni 2020 22:50:26 CEST Dave Cridland wrote: > On Wed, 3 Jun 2020 at 16:30, Jonas Schäfer 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 PR. > 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. +1. > 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, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding namespaced content to Registry entries
On Wed, 3 Jun 2020 at 16:30, Jonas Schäfer 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. 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). Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
