[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with xml-parse-string

From: Chong Yidong
Subject: Re: Problems with xml-parse-string
Date: Fri, 24 Sep 2010 12:26:21 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Lars Magne Ingebrigtsen <address@hidden> writes:

> Chong Yidong <address@hidden> writes:
>>   (tag (@ (attr1 "value1")
>>           (attr2 "value2"))
>>     (nested "Text node")
>>     (empty))
>> This seems pretty regular to me.
> The main difference between sxml and xml.el output is that it has the
> weird an unnecessary "@" node for the attributes and that it wastes a
> cons in the attributes, isn't it?

The xml.el output always has an alist for attributes after each tag; if
there are no attributes, the element after the tag name is nil.  In
sxml, the `@' denotes an attribute list, which is omitted if no
attributes exist.

> Other than that it has the same problem that xml.el has, in that text
> nodes have to be special-cased, so you can't say assq or use simple
> descent without testing.

It is illogical to criticize sxml for wasting conses, while arguing for
wrapping each text node in a cons.

Anyway, it is difficult to see how real the problem is without a
concrete example.  Could you provide one?  I suspect that the real
problem, if one exists, is Elisp's relatively weak support for list
mapping and reduction; if that's the case, the correct solution is to
pull in some of the relevant functions from the CL package.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]