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.
That is because it makes using a data structure like:
{
("namespace", "bar"): [element2, element3, element5],
("namespace", "foo"): [element1, element4],
}
(syntax: python; {} is a map, () is a tuple, [] is a list)
impossible; you have to extend it with ordering information between the
differently named elements (e.g. by collecting them under the same key in the
dictionary, making access to specific elements by type more complicated). I
think this would impact all but purely streaming implementations heavily, so I
suggest we avoid this.
Again, the change under discussion is **not** this. But it comes closer to
that by setting a precedent for the order of *all* <foo/> vs. *all* <bar/>
("all" instead of "individuals") mattering.
This is why I am reluctant.
With that said: I understand that for streaming processing of forms, it would
be really neat if we could say that <reported/> (being metadata) comes before
the <item/> elements.
I am **fine** with doing that, but I want it clearly understood (and, maybe
even consented on) that the other thing outlined above is something we do not
want [1].
Hence, I hereby change my vote (due to the previous misconception on my side
regarding the change breaking the implementation I outlined above) to a -0
instead of a -1.
If we agree this to be a SHOULD instead of a MUST, you can get a +1 from me
(mainly because it is less staggering for existing implementations).
In any case, a box which mentions this clarification (which it still truly
isn’t in my mind, but that might be because I don’t think in a streaming
manner despite using a SAX parser in aioxmpp) would be good to have for people
coming back at the spec and being confused.
kind regards,
Jonas
[1]: I am aware that XHTML-IM effectively requires this, however, XHTML-IM
also will generally not be processed by XMPP code but passed onward
as series of SAX events or DOM nodes or even serialised as (X)HTML
string to downstream code.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
