Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Writing about xml.lisp, Honorable Sam Steingold says:
> yep - why don't you tell me what you want exported?
I'm not sure yet, since i just started using this. Right now i think all
methods for xml-object and xml-name should be exported.
Processing a XML document means walking down the tree structure, paying
attention to the "kinds" of elements you can find: text, xml tags, comments,
or processing instructions. This is done very easily in Lisp. We need the
"predicates" such as xml-object-p, exported too.
Perhaps it would be adequate to have a "low level" interface where one would
access the objects directly, and a "high level" interface with functions
that would abstract the work somewhat like other XML toolkits (the one i
have in mind is JDOM, for Java (http://www.jdom.org )). On the other hand,
once i started understanding how each kind of class/struct fits together in
xml.lisp, it was very easy to get to the data. Maybe all that's needed is to
export the object methods and document the objects.
The only part that wasn't natural to me was getting to the name. To find
out, for example, if i'm looking at tag x (<x>stuf</x>), i had to ask
xml-object to give me the xml-name, then ask xml-name to give me the "local
name", then compare that to the string "x". I ended up putting this in a
macro so i didn't have to think about it.
I like the approach you took to define reader macros to decode the XML.
That's exactly how i would do it if i had the time and the skill. XML is
about hierarchical data structures, and that maps very well into Lisp lists.