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 <drew.var...@ninefx.com> 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 <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
> _______________________________________________
>
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to