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' /> </message> 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. Most, if they are not low-level, have something like Element Stanza.getExtension(String name, String namespace) 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. - They make implementations more complex, in terms of LOC (at least if you want to support fast lookup of extension element a stanza has). - In return, forbidding duplicate extension elements would make XMPP easier to use. - I can think only of two XEPs that introduce duplicate extension elements: <delay/> (1) and *maybe* <forwarded/> Slightly related and for similar reasons, I'd like to propose that the order of stanza extension elements must not yield any semantic, i.e. the order of extension elements doesn't matter. Re 1.: Yeah, i know that xep203 is final, but I think it's still not to late to make that change and have implementations create an extra exception for xep203, which is not nice too, but still better than allowing duplicate extension elements IMHO. - Florian
signature.asc
Description: OpenPGP digital signature
