On Wed, 17 Feb 2021 at 13:31, <drew.var...@ninefx.com> wrote: > But you reorder different elements with anything that has a spec when > forwarding, is that right? > > > Correct. We may change the order in which child elements appear for > elements in our spec. Order among child elements of the same type (el name > + namespace) is stable. Child elements of the same type will always appear > contiguously. > > OK, this sounds like a bug you may wish to fix.
There's nothing in our specifications which says that ordering is insignificant, and general principles such as the end-to-end principle very strongly suggest you shouldn't be messing with any ordering which could - to the endpoints - be significant (even if you think it isn't). There are practical examples which could be covered by your code here, like security labelling in PubSub, which (in practise, and contrary to what XEP-0314 says on the issue) adds child elements to the <item/> after the payload, and consumers assume the first element is always the payload. But also XML C14N-based signing (such as XMLDSIG, which also happens in the real world) would be broken by element reordering. You not caring about ordering on parsing is fine. You not emitting in the correct order is an interop concern as we've seen, but is broadly something we can argue about. You not caring about ordering when forwarding seems like it's broken. > We don’t have a good way to annotate/enforce that certain child element > types need to appear before other child element types. > > Attribute order, namespacing method (xmlns vs. prefix), and insignificant > white space could also change. > Aside from the latter - it's not clear to me how you tell if whitespace is truly insignificant - those are all OK, though unexpected. > > On Feb 17, 2021, at 7:27 AM, Dave Cridland <d...@cridland.net> wrote: > > > > > On Tue, 16 Feb 2021 at 15:07, Drew Varner <drew.var...@ninefx.com> wrote: > >> > So, for example, XEP-0141 page elements could be reordered? >> >> No. The spec does not know about markup mini languages like XEP-0141, >> XEP-0071, XEP-0393 and XEP-0394. Markup is validated at the client. Order >> is maintained because the spec just encodes unknown XML into a struct that >> maintains child order. It’s just a pain to bake those into the spec. >> >> > Fields in forms are assumed to be ordered as well, >> >> No. The order of XData fields in a form (“x”) is maintained. It’s a list >> of fields. The order that could change is whether the list of instructions >> comes after the list of fields. >> >> >> https://github.com/processone/xmpp/blob/master/specs/xmpp_codec.spec#L2027-L2028 > > > But you reorder different elements with anything that has a spec when > forwarding, is that right? > > Dave. > _______________________________________________ > 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 > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
