On Wed, 10 Feb 2021 at 16:29, Jonas Schäfer <jo...@wielicki.name> wrote:
> I am not aware of any place where we impose an ordering between elements > which > have *different* fully-qualified XML names (i.e. after namespace > expansion) [in > any Draft or significantly deployed standard]. Introducing this > requirement > means that implementations cannot use hash maps which map the element type > (fully-qualified XML name) to a list of element representing objects > anymore, > because that structure does not allow storing the ordering of unrelated > elements. If you have concrete examples where that is the case, please let > me > know. > As noted, SliXMPP (and SleekXMPP, upon which it is based) both have an ordering implied. I do not know the code well enough to know if this has an effect on the acceptable order, or just the emitted output. https://github.com/fritzy/SleekXMPP/blob/develop/sleekxmpp/plugins/xep_0004/stanza/form.py#L27 After checking the source a little, my guess is that SleekXMPP can consume the form elements in any order, but always generates them in a fixed order. This could have been done for aesthetic reasons - bear in mind as developers serialise XMPP's XML into text in a stylistic manner, so it's not unexpected we might have chosen to do this purely to make the generated XML look better. However, the commit log for adding the OrderedSet to this line includes this comment: "Modified stanzabase to use an ordered dict so that can guarentee the that 'items' in a form are added after reported." This is, in fact, the precise "clarification" made by the PR. My deduction from this is that such a guarantee was needed; that is, that there exist some implementations which require a strict ordering which is certainly implied in the XEP: "One and only <reported/> element, which can be understood as a "table header" describing the data to follow." The XML Schema does, of course, specify an ordering; but I accept that's because *not* specifying an ordering is actually very difficult in XML Schema from what I recall. Anyway, what we may have is: a) There exist, or existed, implementations which relied on an ordering. b) The XEP implies, but not very explicitly, an ordering. c) Many existing implementations do not require, or produce, any ordering. There's a few options. 1) We ignore the problem. 2) We note that there may exist implementations which rely on the ordering, but say receivers MUST NOT rely on ordering. 3) We note that there may exist implementations which rely on the ordering, and say sender SHOULD order. 4) A combination of both 2 and 3. The safest for interoperability is probably (4), but I am easy to please, I just need some idea of whether any implementations (still) exist which rely on the ordering. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
