Matthias Felleisen announced that the latest CVS for DrScheme allows you to write Python in DrScheme. Nifty. I've noticed that DrScheme has a Java view as well - with Python support, it supports all the languages that I write in Eclipse except Ruby.

Les Orchard recounts Sam Ruby's quick primer on SOAP. It's pretty aggravating that SOAP toolkits never take Sam's approach. A number of approaches that I see that I don't like:

• Hiding the transport under some sort of "service" object. SOAP4R did this, last time I looked. It makes it a pain to configure the transport - I couldn't figure out how to put HTTP credentials. Why not just have the client create the transport and have the SOAP envelope serialize itself?
• Hiding the raw XML. SOAP should require nothing more than an XML parser (and a transport library, usually HTTP). That even beats XML-RPC, where you have to have a library that knows the serialization rules.
• Not supporting Document/Literal. Doc/Literal is so much easier than RPC/Encoded, yet everyone does RPC/Encoded. Allegro recently released a Lisp SOAP client, but it doesn't do Doc/Literal (yet). If I were writing a SOAP library, I'd forget about RPC/Encoded.

Interestingly, we have a customer who's essentially doing Sam's approach. His implementation language is MUMPS. To each their own.

lemonodor pointed at drafts of Peter Siebel's new book Lisp book, to be published by Apress. The other day, I added an RSS feed in NewsGator, hoping that I'll get a notification when Peter's book gets published. You could get the same thing in Atom format, as well. I also created a feed to let me know when new Lisp books are released (RSS 0.91).

Martin Fowler is moving away from XSLT. I agree completely with all of his criticisms. For a great example, look at the abomination I had to go through to get ISO-8601 dates into an Atom feed. The assumption is that the release date for a book can serve as both the issued and modified time. I do have decent date information coming from Amazon, but it's in a format like "3 October, 2003", and the day of the month is omitted for unreleased items. It's not too hard to parse this: if the first characters are numeric, they're the day, otherwise default to some number (either the 1st or last of the month, I'm not worried about accuracy). Alternately, you can split the string on spaces: if you get 3 fields, the first is the day. The second part is a simple table lookup: associate numeric strings to month names. The year is pretty easy, it's the part following the comma in the string; for the rest, just make up a time (book release dates aren't accurate past a day anyway). Anyway, all of this is hard in XSLT; in Python or Ruby string handling is easy and dictionary lookup is easy. The advantage of XSLT is the same as Java's in the sphere of general programming languages: it runs almost everywhere. XSLT's disadvantage is that it's a transformation language, and a transformation on XML Elements and Attributes, principally; XSLT falls apart when your transformation needs to work on text nodes. There are XSLT extensions that would improve some of this, but I'm dependent on Amazon in this case for my processor, and in any case, the use of extensions defeats the platform independence XSLT should give you. If you're going to do that, you might as well use a general purpose language.

That said, Martin's approach looks great. He borrows XSLT's rules based approach to handling nodes, but retains the processing power of Ruby. I believe that XSLT's real power is in the XPath matching and querying coupled with the rules based approach. It's just a matter of coming up with the framework; you could have the same in Ruby as well. I've been working with SXML lately, and it's based on the same theory: once you create a framework for pattern matching and querying, you have XSLT, but without the limitations.