bug#41320: sxml attributes of some elements are in reverse order

[Jan Synacek <jsynacek@redhat.com>]

On Sat, May 16, 2020 at 1:35 PM <tomas@tuxteam.de> wrote:
>
> On Sat, May 16, 2020 at 12:29:54PM +0200, Jan Synacek wrote:
> > Consider the following code snippet running on Guile-3.0.2:
>
> [...]
>
> >   <event name="KeyPress" number="2">
>
> [...]
>
> >   (event (@ (number 2) (name KeyPress))
>
> > Attributes 'number' and 'name' are in reverse compared to the original
> > xml. On the other hand, 'type' and 'name' of the 'field' element are in
> > correct order.
>
> According to the XML spec, attribute order is irrelevant [1]

Sure, but I was under the impression that XML->SXML should map 1:1. Is
it not so?

>     "Note that the order of attribute specifications in
>      a start-tag or empty-element tag is not significant."
>
> Now one could argue that we might want to be stricter in the
> XML->SXML processor, which would be fine, but OTOH there's a
> price to pay. The question is whether we want to go there --
> just imagine another XML processor in the middle changing
> attribute order. It would be spec compliant. What now?
>
> Tough question.

In the middle of the first processor reading the file? IMO there
should be a lock of some sort and such race shouldn't happen in the
first place.  Or does that mean that there is a composition of
processors? Then it shouldn't matter too, since I'm most likely the
one controlling the composition. Or am I misunderstanding something?

I don't really have a strong opinion. I simply thought that the order
in XML->SXML should be the same. Otherwise, I don't see how sxml-match
is actually useful in such a case.

Regards,
-- 
Jan Synacek
Software Engineer, Red Hat