It will affect the stability of child node ordering when forwarding stanzas if the model “knows” those elements.
> On Feb 15, 2021, at 5:25 AM, Dave Cridland <[email protected]> wrote: > > Somewhat off-topic, but does this have any implication on the stability of > ordering of child nodes in an XML tree when forwarding stanzas, or is this > only when consuming or generating them? > > On Thu, 11 Feb 2021 at 18:11, Drew Varner <[email protected]> wrote: > 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 <[email protected]> wrote: > > > > > > > > On Wed, 10 Feb 2021 at 20:22, Florian Schmaus <[email protected]> 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: [email protected] > > _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
