This is my positive view of StupidXmlProject
XML seems to be wagoning along nicely, but its problems will always annoy people.
There are some CommonLisp
tools (see http://www.cliki.net/XML
for example) which provide lisp representations of XML data.
It would seem to make sense to develop these so that any language based on well formed XML can map isomorphically to and from such lists.
Then when the UnlazyXmlWeenies?
grow tired of the verbosity, they will have somewhere to go, and a well developed set of tools to use.
That said, and given the thread on ConciseXml?
, I would emphasize that I'm suggesting an isomorphism. Parse to lists, hack about with it or whatever, then write it back as standard XML 1.0. Trying to create a competing or bolt-on XML definition of WellFormed?
seems likely to cause more trouble than it's worth.
The discussion of ConciseXml?
does suggest to me that the most obvious list representations of XML may not be adequate, though. Maybe they need to handle comments, processing instructions, doctypes, <% JSP syntax %> and all its friends... in a meta-extensible way. Maybe data nodes need a type before they even start on the data?
Of course I would grab that chisel and start pounding right now, but first I have a lot to learn about Lisp. -- MatthewAstley
I, too, like this approach. It is elegant, effective, and takes advantage of the numerous strengths of both technologies. -- AnonymousDonor1
Isn't it more like using the strengths of Lisp to get around the deficiencies of XML? Or do you mean the non-technological strengths of XML? -- ad2 (?)
Yes, IMHO. The strengths that XML brings are ubiquity and trendiness; the very things that Lisp seems to lack. Plus perhaps a default state in which you can't do very much with it, hence it is "secure". It isn't going to up and bite you the way Lisp might if you let a stranger at your symbol table ... but this is just a detail, if the implementation is done carefully. -- MatthewAstley
A small digression
Of course, [LispByTheBackDoor] is from the same cloudy mind that brought you the notion of http://www.cliki.net/Cut+and+shut . -- MatthewAstley
Hey, cloudy or not, your cut-and-shut page is, in my opinion, exactly
the right way to think about getting stuff to work. It's really not very different, fundamentally, from putting native platform calls into Smalltalk or JNI into Java. Keep the unit tests, though.
Thanks! All I need is CopiousFreeTime...
You're right about the JNI analogy of course. Another one is KawaScheme, and I suppose that is closer to my intention. I don't feel the need to HitTheMetal? (or at least the OS), as with JNI, I just want an EscapeHatch for when I know a quick way to do something. -- m
[Isn't it more like using the strengths of Lisp to get around the deficiencies of XML? Or do you mean the non-technological strengths of XML?]
, Java, and all the "higher level" languages. I view it as a successful alternative to IDL and all that ridiculous
CORBA/OMG stuff. If I have to interconnect an unbounded number of independent parallel services, it works better than anything else I've come across. I don't have to recompile and rebuild existing clients to let them take advantage of new services. And so on and so forth.
I don't know if it's "trendy" or not - all I know is that I think XML lets me not
have to worry about whether I have a compatible "Object Broker" around, or whether my "Portable Object Adapter" happens to be started and listening to my client (not to mention able to listen), and I don't have recompile, redistribute, and rebuild the entire universe each time I have to make a change in the public signature of a service.
There is a specification and parser of a version of XML much more suited to lisp. Its called SXML and its specification can be found at http://okmij.org/ftp/Scheme/SXML.html . The parser is called SSAX and is at http://ssax.sourceforge.net. Note the parser is not written in ANSICommonLisp but actually in SchemeLanguage. It allows XML to be converted to and from SXML. Much more is included in the package and that can be found at the sf website. (r2q2)