On 2/11/21 7:09 PM, Drew Varner 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.
What about the reading side: How does your CODEC assign field types to fields of incoming data forms?
- Florian
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
