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. If you have concrete examples where that is the case, please let me know. Introducing this restriction this late into the standards process for no interoperability reason and in a Final standard is not justified. kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
