bug#41320: sxml attributes of some elements are in reverse order
On Sat, 16 May 2020, at 14:27, Jan Synacek wrote: > 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. Attributes ordering should not matter in sxml-match, as per the manual: https://www.gnu.org/software/guile/manual/html_node/sxml_002dmatch.html
bug#41320: sxml attributes of some elements are in reverse order
On Sat, May 16, 2020 at 02:27:15PM +0200, Jan Synacek wrote: [...] > > just imagine another XML processor in the middle changing > > attribute order. It would be spec compliant. What now? [...] > In the middle of the first processor reading the file? No, I was thinking much simpler than that. For example, someone augmenting/embellishing the xcb spec (because of, for example, some change) and messing up the order for you, i.e. before your program gets a shot at it. But I see (elsethread) that your problem is solved :) Cheers -- t signature.asc Description: Digital signature
bug#41320: sxml attributes of some elements are in reverse order
On Sat, May 16, 2020 at 2:36 PM Linus Björnstam wrote: > > > On Sat, 16 May 2020, at 14:27, Jan Synacek wrote: > > > 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. > > Attributes ordering should not matter in sxml-match, as per the manual: > https://www.gnu.org/software/guile/manual/html_node/sxml_002dmatch.html I totally missed that. Thank you for pointing it out! -- Jan Synacek Software Engineer, Red Hat
bug#41320: sxml attributes of some elements are in reverse order
On Sat, May 16, 2020 at 1:35 PM 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 (@ (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
bug#41320: sxml attributes of some elements are in reverse order
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 (@ (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] "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. Cheers [1] https://www.w3.org/TR/REC-xml/#sec-starttags -- t signature.asc Description: Digital signature
bug#41320: sxml attributes of some elements are in reverse order
Consider the following code snippet running on Guile-3.0.2: (use-modules (sxml simple) (sxml xpath)) (define doc (call-with-input-file "/home/jsynacek/src/xcb-proto-1.13/src/xproto.xml" (lambda (port) (xml->sxml port (define events ((sxpath '(// event)) doc)) (display (car events)) (newline) Now, attributes of *some* elements are generated in reverse order, which makes the output pretty much undeterministic and using sxml-match unreliable. This is from the original xml: ... And the resulting sxml: (event (@ (number 2) (name KeyPress)) (field (@ (type KEYCODE) (name detail))) (field (@ (type TIMESTAMP) (name time))) (field (@ (type WINDOW) (name root))) ... 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. The xproto.xml file comes from xcb-proto [1]. [1] https://lists.freedesktop.org/archives/xcb/2018-March/011090.html
