Re: [Standards] XML Element Ordering

[Kevin Smith]

On 23 Feb 2021, at 09:30, Dave Cridland  wrote:
> 
> 
> 
> On Mon, 22 Feb 2021 at 19:02, Florian Schmaus  > wrote:
> On 2/18/21 12:16 AM, Dave Cridland wrote:
> > On Wed, 17 Feb 2021 at 19:22, Kevin Smith  >  
> > >> wrote:
> > 
> > On 17 Feb 2021, at 18:42, Florian Schmaus  > 
> > >> 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:
> >  >> 
> >  >> 
> >  >> 
> >  >> 
> >  >> 
> >  >> 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  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.
> 
> 
> Ah! Yes, serialization order should remain stable in routing.
>  
> But does it really matter in which order a client emits  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.
> 
> 
> But ordering of stanza immediate child elements by the client (and additions 
> by servers, actually) can be in any order.
>  
> And the ordering within most extension elements is also irrelevant. Take 
>  for example: It doesn't matter if the  comes before 
> the forwarded  or not. Hence XEP-0297 does not contain a 
> single sentence with order requirements. → 

Re: [Standards] XML Element Ordering

[Dave Cridland]

On Mon, 22 Feb 2021 at 19:02, Florian Schmaus  wrote:

> On 2/18/21 12:16 AM, Dave Cridland wrote:
> > On Wed, 17 Feb 2021 at 19:22, Kevin Smith  > > wrote:
> >
> > On 17 Feb 2021, at 18:42, Florian Schmaus  > > 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:
> >  >> 
> >  >> 
> >  >> 
> >  >> 
> >  >> 
> >  >> 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  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.
>
>
Ah! Yes, serialization order should remain stable in routing.


> But does it really matter in which order a client emits  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.
>
>
But ordering of stanza immediate child elements by the client (and
additions by servers, actually) can be in any order.


> And the ordering within most extension elements is also irrelevant. Take
>  for example: It doesn't matter if the  comes before
> the forwarded  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  from xep4 that triggered this discussion.
> Here we will (probably) explicitly specify the order requirement.
>
>
I think 

Re: [Standards] XML Element Ordering

[Florian Schmaus]

On 2/18/21 12:16 AM, Dave Cridland wrote:
On Wed, 17 Feb 2021 at 19:22, Kevin Smith > wrote:


On 17 Feb 2021, at 18:42, Florian Schmaus 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:
 >> 
 >> 
 >> 
 >> 
 >> 
 >> 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  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  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 
 for example: It doesn't matter if the  comes before 
the forwarded  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  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
___

Re: [Standards] XML Element Ordering

[Dave Cridland]

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  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.

On Wed, 17 Feb 2021 at 19:22, Kevin Smith  wrote:

> On 17 Feb 2021, at 18:42, Florian Schmaus  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:
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 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), but within an extension the order should be maintained
> unless otherwise explicitly stated.
>
> /K
> ___
> 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
___

Re: [Standards] XML Element Ordering

[Kevin Smith]

On 17 Feb 2021, at 18:42, Florian Schmaus  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:
>> 
>> 
>> 
>> 
>> 
>> 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), but within an extension the order should be maintained unless 
otherwise explicitly stated.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___