|
From: | David De La Harpe Golden |
Subject: | Re: Problems with xml-parse-string |
Date: | Fri, 24 Sep 2010 03:46:31 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100913 Icedove/3.0.7 |
On 24/09/10 02:09, Chong Yidong wrote:
Lars Magne Ingebrigtsen<address@hidden> writes:Stefan Monnier<address@hidden> 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
[Prev in Thread] | Current Thread | [Next in Thread] |