unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* bug#41320: sxml attributes of some elements are in reverse order
@ 2020-05-16 10:29 Jan Synacek
  2020-05-16 11:02 ` tomas
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Synacek @ 2020-05-16 10:29 UTC (permalink / raw)
  To: 41320

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:

  <event name="KeyPress" number="2">
    <field type="KEYCODE" name="detail" />
    <field type="TIMESTAMP" name="time" />
    <field type="WINDOW" name="root" />
  ...

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






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#41320: sxml attributes of some elements are in reverse order
  2020-05-16 10:29 bug#41320: sxml attributes of some elements are in reverse order Jan Synacek
@ 2020-05-16 11:02 ` tomas
  2020-05-16 12:27   ` Jan Synacek
  0 siblings, 1 reply; 6+ messages in thread
From: tomas @ 2020-05-16 11:02 UTC (permalink / raw)
  To: Jan Synacek; +Cc: 41320

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

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]

    "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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#41320: sxml attributes of some elements are in reverse order
  2020-05-16 11:02 ` tomas
@ 2020-05-16 12:27   ` Jan Synacek
  2020-05-16 12:30     ` Linus Björnstam
  2020-05-16 14:21     ` tomas
  0 siblings, 2 replies; 6+ messages in thread
From: Jan Synacek @ 2020-05-16 12:27 UTC (permalink / raw)
  To: tomas; +Cc: 41320

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






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#41320: sxml attributes of some elements are in reverse order
  2020-05-16 12:27   ` Jan Synacek
@ 2020-05-16 12:30     ` Linus Björnstam
  2020-05-16 12:50       ` Jan Synacek
  2020-05-16 14:21     ` tomas
  1 sibling, 1 reply; 6+ messages in thread
From: Linus Björnstam @ 2020-05-16 12:30 UTC (permalink / raw)
  To: Jan Synacek, tomas; +Cc: 41320


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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#41320: sxml attributes of some elements are in reverse order
  2020-05-16 12:30     ` Linus Björnstam
@ 2020-05-16 12:50       ` Jan Synacek
  0 siblings, 0 replies; 6+ messages in thread
From: Jan Synacek @ 2020-05-16 12:50 UTC (permalink / raw)
  To: Linus Björnstam; +Cc: 41320

On Sat, May 16, 2020 at 2:36 PM Linus Björnstam
<linus.bjornstam@veryfast.biz> 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






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#41320: sxml attributes of some elements are in reverse order
  2020-05-16 12:27   ` Jan Synacek
  2020-05-16 12:30     ` Linus Björnstam
@ 2020-05-16 14:21     ` tomas
  1 sibling, 0 replies; 6+ messages in thread
From: tomas @ 2020-05-16 14:21 UTC (permalink / raw)
  To: Jan Synacek; +Cc: 41320

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-05-16 14:21 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-16 10:29 bug#41320: sxml attributes of some elements are in reverse order Jan Synacek
2020-05-16 11:02 ` tomas
2020-05-16 12:27   ` Jan Synacek
2020-05-16 12:30     ` Linus Björnstam
2020-05-16 12:50       ` Jan Synacek
2020-05-16 14:21     ` tomas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).