Re: Problems with xml-parse-string

[David De La Harpe Golden <david@harpegolden.net>]

On 24/09/10 02:09, Chong Yidong wrote:
> Lars Magne Ingebrigtsen<larsi@gnus.org>  writes:
>
>> Stefan Monnier<monnier@iro.umontreal.ca>  writes:
>>
>>>> As for the :foo node names, we can map them to anything else if
>>>> required.  Pick an invalid XML character -- any one will do, if this is
>>>> important.
>>>
>>> How 'bout =foo ?
>>
>> Looks good to me.
>
> If we're going to make a clean break with the old xml.el parse tree
> format, I think it makes more sense to go with sxml.  Is there any
> technical reason not to?

I'm not too convinced mapping xml element and attribute names to 
interned lisp symbols at all is particularly desirable.  Not that I 
personally use xml-... in emacs lisp much/ever, but I have used common 
lisp xml parsing in the past and seem to remember that using strings was 
overall less problematic than symbols (and it wasn't just down to case - 
common lisp only looks case insensitive), just generally easier to be 
non-lossy and non-cluttering-symbol-table-with-random-xml-crap. Read 
some transient xml message once? have some useless symbols hanging round 
forever (for small values of forever).

Yes, strings look messier for "manually keyed in" toy example sexp 
representations of xml, but I imagine the bulk of emacs lisp xml api 
usage in practice would be programmatic.

One could also accept symbols as a shortcut for lisp->xml and just use 
their symbol-names as strings, but output strings for xml->lisp.  I 
suppose you could offer the option of interning for xml->lisp output.

Over in common lisp land, the "xmls" supported (and extended a bit) by 
closure xml [1] used strings, avoiding symbols.

[1] http://common-lisp.net/project/cxml/xmls-compat.html