XML does not impose any semantics based on the order of the attributes;
they're an unordered set. Quoting [1]:
> Note that the order of attribute specifications in a start-tag or empty-element tag is not significant
and [2] 2.2.5:
> An unordered set of attribute information items
Still, using a QHash-based implementation to store attributes is
annoying, because one cannot serialize the document in a stable way.
The order of attributes is going to depend on the QString hash function
(which we can change at any time) and the QHash seed (which is random
and changes at every run). In other words, saving the same DOM will
yield non deterministic outputs. That's annoying for testing,
reproducible builds, and so on.
Switching to an _ordered_ associative container for storing attributes
won't, on its own, ensure any specific ordering. That's because:
* attributes are currently kept associated using their name as the key,
ignoring an eventual namespace prefix;
* there's some convoluted logic that sometimes emits attributes in the
xmlns namespace (to qualify a prefix).
Hence, just go for the straightforward implementation and sort the
attributes before streaming them. In the main loop I could have used a
range-based for loop over the associative container used for attributes;
since it's a Qt container, it would have yielded just the values in the
map, and we are not interested into the keys. However I'm preparing for
further changes down the road, so I'm opting for key/value iteration.
I'm deliberately not offering an opt-out because:
* I don't think this is so expensive to justify an opt-out;
* I'm going to remove QHash anyways in a follow up commit.
[1] https://www.w3.org/TR/xml11/#sec-starttags
[2] https://www.w3.org/TR/xml-infoset/#infoitem.element
Task-number: QTBUG-76800
Task-number: QTBUG-25071
Change-Id: I6282ae2ccbee9c0099f138de48b94bb7c40b3680
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
9e75a4cca3