First time caller, long time listener. Some model-driven CODECs may not enforce nor detect order.
P1’s model-based XMPP CODEC (https://github.com/processone/xmpp) does not enforce nor care about the order of the elements. ``` 2> ReportedFirst = <<"<x xmlns='jabber:x:data' type='result'><reported><field var='field-name-one' label='description' type='text-single'/></reported><item><field var='field-name-two'><value>field-value</value></field></item><item><field var='field-name-three'><value>field-value</value></field></item></x>">>. <<"<x xmlns='jabber:x:data' type='result'><reported><field var='field-name-one' label='description' type='text-single'/"...>> 3> ReportedLast = <<"<x xmlns='jabber:x:data' type='result'><item><field var='field-name-two'><value>field-value</value></field></item><item><field var='field-name-three'><value>field-value</value></field></item><reported><field var='field-name-one' label='description' type='text-single'/></reported></x>">>. <<"<x xmlns='jabber:x:data' type='result'><item><field var='field-name-two'><value>field-value</value></field></item><i"...>> 4> xmpp:decode(fxml_stream:parse_element(ReportedFirst)) == xmpp:decode(fxml_stream:parse_element(ReportedLast)). true ``` There’s no way for them to detect the invalid order in the server code, because the CODEC hands them a record/struct. They do write it in the correct order because their implementation happened to use lists to element refs instead of maps. Our model-based CODEC isn’t public. We happened to use lists for element references, but also looked at maps/dictionaries. There are tradeoffs, and a map-based DSL does provide some advantages, including automatic detection of duplicated keys. While some languages have ordered maps in their standard libraries, others do not. OCaml doesn’t. I am unsure if other folks are using a map-based DSL for a model driven CODEC. I don’t see the value in starting to enforce the order on these elements. Thanks, Drew > On Feb 10, 2021, at 4:00 PM, Dave Cridland <d...@cridland.net> wrote: > > > > On Wed, 10 Feb 2021 at 20:22, Florian Schmaus <f...@geekplace.eu> wrote: > Since you asked: Smack relies on the ordering (in case a non-default > form field type is used), since Smack needs to see the <reported/> first > to assign types to the field while parsing the following <item/>s. > > Right, so you're parsing using a SAX-style parser and if <reported/> comes > after (or in between) the <item/>s, you'd need to use a two-pass parser, is > that correct? > > This is more or less the case I suspected might exist. Most (if not all) > early XMPP libraries use that kind of approach, whereas a lot of later ones > pull stanzas out of the XMLStream as documents and then can do XPath-ish > things on them, so the order matters much less. Smack is, of course, as early > as they come (along with Strophe and Strophe.js, the former being probably > forgotten). > > So the converse question - are there any libraries which couldn't generate > XML in order? > > 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 _______________________________________________
