[Standards] XMPP APIs and duplicate extension elements
kevin.smith at isode.com
Wed Feb 4 11:45:12 UTC 2015
On 4 Feb 2015, at 11:37, Florian Schmaus <flo at geekplace.eu> wrote:
> If I'm not mistaken, no XMPP specification forbids duplicate extension
> elements, i.e. same element name and namespace, as direct child of the
> stanza element. For example
> <message …>
> <foo xmlns="http://example.org" data='42' />
> <foo xmlns="http://example.org" data='1337' />
That’s legal, and used.
> is perfectly valid XMPP XML. This means that in order to allow retrieval
> of *all* elements, XMPP APIs need to provide a method like
> List<Element> Stanza.getExtensions(String name, String namespace)
> but a quick survey did not reveal any API that actually does this.
> I like to propose that a future RFC (or another normative spec) forbids
> duplicate extension elements. Now I know this is likely a controversial
> proposal. But please have a look my arguments first:
> - Most APIs don't support duplicate extension elements, this leads to
> the conclusion that nobody noticed that they are not supported, i.e.
> nobody is missing that feature.
I’m sure there are some client libraries with this bug, but certainly not all.
> - They make implementations more complex, in terms of LOC (at least if
> you want to support fast lookup of extension element a stanza has).
I think it costs Swiften about 20 LoC. Just provide an ‘I know there’s only one of this type, so give me it’ call as well as the ‘give me all of them’ call, and you’re pretty much done.
More information about the Standards