On 2/18/21 12:16 AM, Dave Cridland wrote:
On Wed, 17 Feb 2021 at 19:22, Kevin Smith <kevin.sm...@isode.com
<mailto:kevin.sm...@isode.com>> wrote:
On 17 Feb 2021, at 18:42, Florian Schmaus <f...@geekplace.eu
<mailto:f...@geekplace.eu>> wrote:
>
> On 2/16/21 4:14 PM, Jonas Schäfer wrote:
>> I think this is the best place in the thread to reply with all
my thoughts.
>> Vote change to -0 (or +1 with additional fixes) instead of -1
inline.
>> On Sonntag, 14. Februar 2021 21:12:17 CET Florian Schmaus wrote:
>>> Eventually, this is a situation where we cannot avoid that somebody
>>> needs to change their code. We need to weigh in the effects of
the three
>>> options:
>>> A: clearly state that the order is not guaranteed
>>> B: clearly state that the order is guaranteed
>>> C: state that it should be sent in order, but recipients
must be able
>>> to process in any order
>> You are right. You were also right about what you said in reply
to my other
>> email about OrderedMap existing in Python (even being the
default since some
>> versions).
>> However, here is a specific thing I do not want to see in XMPP:
>> <foo/>
>> <bar/>
>> <bar/>
>> <foo/>
>> <bar/>
>> with the relative order of foo vs. bar elements (mind, the order
of the bar
>> elements to each other mattering is ok!) mattering.
>
>
> I am with you here, with one additional constraint: I think it is
relevant where those elements are placed in the stanza.
>
> Element ordering is something that is often overlooked in XMPP
land. My stance is that the order of extension elements *which are
direct children of a stanza* should be irrelevant (and probably can
be unstable, e.g., because it was modified by a hop). However,
extension elements are free to impose order constraints of their
sub-elements. As it was previously pointed out, we already have such
elements.
>
> I wonder if we have consensus for
>
> """
> The XML element order is irrelevant for elements that a direct
children of a stanza, and for all other elements unless explicitly
specified.
> “""
I think the reverse of part two is true, actually.
I think the order of stanza children isn’t relevant (extensions can
be put in any order),
At least we agree on something. :)
but within an extension the order should be
maintained unless otherwise explicitly stated.
/K
> I think, broadly, that stanza contents can be re-serialized in any way > that would not alter the canonicalized form, and not otherwise. > > So if you want to reorder attributes, go for it. Reorder elements, not > so much. > > There are some obvious exceptions: > > Servers can insert new elements just fine and - in rare cases - remove > them too, but that's really because those extensions are specifically > designed for it, like <delay/> or security labelling. > > Otherwise, I don't really understand why anyone would think reordering > things inside a stanza would be a good idea by default. The fact it > doesn't usually cause a problem is neither an indicator that it cannot, > nor an indicator that it should, and given XML has *always* had order as > a significant thing, I don't understand why "we've never explicitly said > you can't" should be taken as an indicator that therefore you can. > > So broadly, Florian, not consensus from me.I had my fancy XMPP client developer goggles on when I wrote this. It occurred to me that you and Kev are talking about maintaining the order when re-serializing XML. Which takes the perspective of a sever routing stanzas.
But does it really matter in which order a client emits <body/> and other first-level, i.e. directly below the stanza element, extension elements? I do not think so, and I believe we should forbid any semantic of the ordering of first-level stanza extension elements.
And the ordering within most extension elements is also irrelevant. Take <forwarded/> for example: It doesn't matter if the <delay/> comes before the forwarded <message/> or not. Hence XEP-0297 does not contain a single sentence with order requirements. → The order is implicitly irrelevant. However, certain extension elements require a particular ordering: Like the <reported/> from xep4 that triggered this discussion. Here we will (probably) explicitly specify the order requirement.
This could mean for a stanza routing entity that it is free to re-order first-level extension elements and within all elements where it knows that the order is irrelevant. If server developers see a benefit in this kind of freedom, then I do not see a reason why we should not allow it.
- Florian
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
