I think, broadly, that stanza contents can be re-serialized in any way that would not alter the canonicalized form, and not otherwise.
So if you want to reorder attributes, go for it. Reorder elements, not so much. There are some obvious exceptions: Servers can insert new elements just fine and - in rare cases - remove them too, but that's really because those extensions are specifically designed for it, like <delay/> or security labelling. Otherwise, I don't really understand why anyone would think reordering things inside a stanza would be a good idea by default. The fact it doesn't usually cause a problem is neither an indicator that it cannot, nor an indicator that it should, and given XML has *always* had order as a significant thing, I don't understand why "we've never explicitly said you can't" should be taken as an indicator that therefore you can. So broadly, Florian, not consensus from me. On Wed, 17 Feb 2021 at 19:22, Kevin Smith <kevin.sm...@isode.com> wrote: > On 17 Feb 2021, at 18:42, Florian Schmaus <f...@geekplace.eu> wrote: > > > > 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 order > >> You 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. > > “"" > > I think the reverse of part two is true, actually. > > I think the order of stanza children isn’t relevant (extensions can be put > in any order), but within an extension the order should be maintained > unless otherwise explicitly stated. > > /K > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
