From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Jan Synacek Newsgroups: gmane.lisp.guile.bugs Subject: bug#41320: sxml attributes of some elements are in reverse order Date: Sat, 16 May 2020 14:27:15 +0200 Message-ID: References: <20200516110207.GC30977@tuxteam.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="90294"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41320@debbugs.gnu.org To: tomas@tuxteam.de Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Sat May 16 14:28:12 2020 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jZvvI-000NO0-5C for guile-bugs@m.gmane-mx.org; Sat, 16 May 2020 14:28:12 +0200 Original-Received: from localhost ([::1]:33038 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZvvF-0004xj-MS for guile-bugs@m.gmane-mx.org; Sat, 16 May 2020 08:28:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47966) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZvv8-0004xO-Ob for bug-guile@gnu.org; Sat, 16 May 2020 08:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56658) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZvv8-0006vh-FA for bug-guile@gnu.org; Sat, 16 May 2020 08:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jZvv8-0003DM-C5 for bug-guile@gnu.org; Sat, 16 May 2020 08:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan Synacek Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sat, 16 May 2020 12:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41320 X-GNU-PR-Package: guile Original-Received: via spool by 41320-submit@debbugs.gnu.org id=B41320.158963205312320 (code B ref 41320); Sat, 16 May 2020 12:28:02 +0000 Original-Received: (at 41320) by debbugs.gnu.org; 16 May 2020 12:27:33 +0000 Original-Received: from localhost ([127.0.0.1]:39971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZvue-0003Ce-Mb for submit@debbugs.gnu.org; Sat, 16 May 2020 08:27:32 -0400 Original-Received: from us-smtp-2.mimecast.com ([207.211.31.81]:39168 helo=us-smtp-delivery-1.mimecast.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZvud-0003CW-Fo for 41320@debbugs.gnu.org; Sat, 16 May 2020 08:27:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589632050; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uBAwyQZsU5oq8onIEyciOACpW5QGeau7sk8OSl3JsV0=; b=hZyhypDTf6qjYyR+EJDcMgXhQi8cOSjrYwwdTelSg2AEdNjgFf1nVLDd9qmBBtzfRj4w1R BzwzG3pwLP0im59OJT79Ajb1sa0LaVJEGDALww2TCzFiF7+uontjecLGi6rmMMemkFduI7 rdVu8Q93g2ghJDfOOb4hU8Jr3wodmyA= Original-Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-57-lYXp2m0aMZeX0gMZsMyDIA-1; Sat, 16 May 2020 08:27:28 -0400 X-MC-Unique: lYXp2m0aMZeX0gMZsMyDIA-1 Original-Received: by mail-lf1-f72.google.com with SMTP id a17so285456lfr.9 for <41320@debbugs.gnu.org>; Sat, 16 May 2020 05:27:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uBAwyQZsU5oq8onIEyciOACpW5QGeau7sk8OSl3JsV0=; b=dtFYXdSQjPWYIfq9V5u6tMY0Dj25mtwiA61dchjdDMcOYiOyzZ7CuT/ifRuIUw5VLe 8dpTY0dGBlxdkW2IcWOTqRsyIPJhBU8gQZ5W66LnGaqTp7tXglY6rMSCKSP6bADEboE+ pabjsZGlrtzuy1CmOig8s7wUMuJblkiKcV57sroZQ79ky7JYSIjZcXgh45PP3uVHVqet /0uc07d+7zweI2HRyyKI4V6jmIok88t45G3S5WUR4YLD/eSKJaov1lIPi0CFDF2TwCtC rM9b7CyrlrHjj7wiL4X/0nmnmcskHYCLTCC+IEQnV/UtdNisitJ89CoFKsYbiu8SmOWt sNxA== X-Gm-Message-State: AOAM530n5RaF9Pve+r4b3QfrVdKDP2iFyJKTuXaoEC9hIwZre2daGdhw ZyLfb2Q2G91L57cVlt44JEsPT0Vup4DS7SiH38J2VfK0rUnuBQ1RsbjbHoRX0zJeebsng849prW cYHeRkpcp/gcg6zwBm1+mzRmagVREZa0= X-Received: by 2002:ac2:44cd:: with SMTP id d13mr5683285lfm.2.1589632047199; Sat, 16 May 2020 05:27:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHm4cChav3HT+CGUqdWtLHhwZpG7rFVzphVNJ+LbM2WLE1JL3E2zEjzqXswHn9auV7dfCJIIciPgwaRrLsB4k= X-Received: by 2002:ac2:44cd:: with SMTP id d13mr5683268lfm.2.1589632046902; Sat, 16 May 2020 05:27:26 -0700 (PDT) In-Reply-To: <20200516110207.GC30977@tuxteam.de> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.io gmane.lisp.guile.bugs:9760 Archived-At: 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