Phil Windley found something I missed: the RESTful flavor of Amazon's new API provides its own XSLT service:
Amazon's progam supports both a SOAP/RPC model and a RESTful model . Using the RESTful model, I cobbled up the Amazon results box on the right side of this page. This is the XSL file that I used and this is the URL I called . [ Windley's Enterprise Computing Weblog ]
I had instead used the generic W3C XSLT service. In the example I gave the other day, here was the URL that yoked it to Amazon and to my transform:
P retty ugly, what with all that escaping going on. Here's a simpler URL that yields the same result using the technique Phil demonstrates:
(The lameness of the MS DHTML edit control messed these up and make them non-clickable, and the long lines screwed up formatting, hence the line breaks introduced above.)
The W3C-based service is still really interesting because it's a general-purpose way to apply any web-accessible XSLT to any web-accessible XML. But using Amazon's built-in XSLT certainly makes shorter and more readable URLs.
A minor difference between the two: W3C's service sends a Content-type: application/xml header, whereas Amazon sends Content-type: text/html. The former gives nicer results when viewed in IE.
Phil goes on to say of XSLT:
XSL needs some good tools for debugging and testing. As it happens, XSL is a programming language with few (maybe no) support and debugging tools. What's worse, its a rule based language, an unfamiliar paradigm for most people. People used to give me a bad time about Scheme and LISP. I can't believe they'll use XSL.
Understood. I felt that way too, and only gradually made my peace with XSLT. There is an excellent XSLT debugger available from ActiveState, by the way. Disclosure: I am a member of ActiveState's Technical Advisory Board. Further disclosure: I don't actually use the XSLT debugger nowadays, but it was very helpful in the early going to visualize how the XSLT engine works.
Former URL: http://weblog.infoworld.com/udell/2002/07/19.html#a345