On 2022/01/08, Dave Cridland wrote: > On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer <jo...@wielicki.name> wrote: > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: PubSub Namespaces > > Abstract: > > This extension defines a new PubSub node attribute to specify the type > > of payload. > > > > > Oh no it doesn't! > > > > URL: https://xmpp.org/extensions/inbox/pubsub-ns.html > > > What this extension appears to be trying to do, based on the (entirely > unreferenced and unmentioned on this list) Github discussion, is to define > the pubsub node *semantics*. That's a different thing to a namespace, and > certainly different from the "type of payload".
Indeed, this is based off a PR[0] that I made a while back on 277, that got somewhat-rejected-but-not-really by one of its authors (stpeter). I got asked to go to standards but I thought that would get no interest as pubsub stuff usually does and we would redo the same discussion just the two of us. So I gave up, until this. > The canonical example given was microblogging with Atom, where you don't > just want random Atom payloads - the node might require Atom to work, but > it has additional semantics around it that can be expected. IOW, the need > is to know it's a microblog node, and not just an Atom node. So this isn't > really about payload formats, it's about node semantics, and that's a > radically different thing. And definitely not a "namespace". Yes! I think you captured very well what we wanted to say! We do want a way to express semantics. “Payload” may not be the word, then we'll change it. “Namespace” annoys people, we're also happy to change it. Suggestions welcome for a field(?) name, and also another XEP name! If that is the meaning that is generally given to (payload) “type” (a very generic word), then I understand stpeter's resentment to accept the PR. > The pubsub#type form field we already have (and rarely use) is stipulated > as being the "type of node data, usually specified by the namespace of the > payload (if any)". I think this covers what's needed here, whereas this > specification as written actually doesn't - and isn't any clearer than > pubsub#type. Suggestions on how to make the document clearer is also very welcome. As you can see edhelas and I are not particularly great at writing, especially in english. I do want to say though that some more words on pubsub#type would be great. I am definitely not the only one to be confused. > This specification is also unimplementable as written, due to the > requirement in 5.1.1 to have realtime access to the registry, but that's > really a non-issue - the specification isn't clear enough to even know what > the intent is. Once we understand the intent, we can then compare it with > pubsub#type, and decide if it'd be better to make better use of that. I guess we'll fast-forward to the time the XSF has a working registry. I'm not sure that should prevent a spec from getting in. Thanks for the feedback! [0]: https://github.com/xsf/xeps/pull/986
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
