On 2/10/21 5:28 PM, Jonas Schäfer wrote:
Thanks for the minutes! On Mittwoch, 10. Februar 2021 16:58:30 CET Tedd Sterr wrote:4b) PR #1032 (Data Forms Clarifications) - https://github.com/xsf/xeps/pull/1032 Jonas sees this as a massive normative change, rather than the clarification it claims to be; it introduces a precedent of requiring relative ordering of unrelated elements. Dave doesn't think that's actually a new precedent - the existing text says the 'reported' element describes the data to follow; also recently noticed that SleekXMPP/SliXMPP already assumes an order. Jonas isn't sure that imposes a strict ordering requirement, and knows of at least one implementation which doesn't guarantee the order and would become non-compliant with such a change. The author, Flow, says that form-field type-aware parsing of data forms becomes more complex if the order isn't specified, and it appears to be the norm to have 'reported' first because people copy directly from the examples. Daniel thought the lack of element ordering was the reason schemas are non-normative - Flow says that's why it's specified in the normative text and not the schema. Jonas still isn't convinced this is a clarification - Flow suggests that any change which clarifies a normative requirement that wasn't previously explicitly spelled out could be considered a normative change; sees it as a trade-off. Flow would tolerate implementations changing the order of first-level stanza extensions, but not the order of arbitrary elements while en route. Georg seeks agreement that the updated first commit is indeed a clarification - Jonas and Zash agree. Dave is happy to discuss this further on the list - Jonas will reluctantly start a thread. Jonas: -1 Daniel: [on-list] (too distracted by the bike shed and forgot to read this) Georg: [on-list] Dave: [on-list] Zash: [on-list]As of now, I’m still -1. I want to elaborate the reason a little. Note that my -1 is solely based on the ordering requirement for <reported/>, not the other commit in that PR. I am not aware of any place where we impose an ordering between elements which have *different* fully-qualified XML names (i.e. after namespace expansion) [in any Draft or significantly deployed standard]. Introducing this requirement means that implementations cannot use hash maps which map the element type (fully-qualified XML name) to a list of element representing objects anymore, because that structure does not allow storing the ordering of unrelated elements.
That reads a little bit like an exaggeration given that LinkedHashMap (Java) and OrderedDict (Python) exists.
Hence, I am sorry, but I do not follow that argument.
If you have concrete examples where that is the case, please let me know.
What is "that" here? - Florian
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
