> 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. 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. > 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 _______________________________________________
