On 2/16/21 4:14 PM, Jonas Schäfer wrote:
I think this is the best place in the thread to reply with all my thoughts.Vote change to -0 (or +1 with additional fixes) instead of -1 inline. On Sonntag, 14. Februar 2021 21:12:17 CET Florian Schmaus wrote:Eventually, this is a situation where we cannot avoid that somebody needs to change their code. We need to weigh in the effects of the three options: A: clearly state that the order is not guaranteed B: clearly state that the order is guaranteed C: state that it should be sent in order, but recipients must be able to process in any orderYou are right. You were also right about what you said in reply to my other email about OrderedMap existing in Python (even being the default since some versions). However, here is a specific thing I do not want to see in XMPP: <foo/> <bar/> <bar/> <foo/> <bar/> with the relative order of foo vs. bar elements (mind, the order of the bar elements to each other mattering is ok!) mattering.
I am with you here, with one additional constraint: I think it is relevant where those elements are placed in the stanza.
Element ordering is something that is often overlooked in XMPP land. My stance is that the order of extension elements *which are direct children of a stanza* should be irrelevant (and probably can be unstable, e.g., because it was modified by a hop). However, extension elements are free to impose order constraints of their sub-elements. As it was previously pointed out, we already have such elements.
I wonder if we have consensus for """The XML element order is irrelevant for elements that a direct children of a stanza, and for all other elements unless explicitly specified.
""" - Florian
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
