A couple updates to yesterday's news:

• The query string was broken in the example I posted, it's been fixed.
• My sample feed nearly validates, except for the lack of dates.  I tried an experiment using SSI to generate my stylesheet, but I can't figure out how to get an ISO-8601 date out of it.  Well, I can, but the validator doesn't like it if I use GMT times, so specifically, I can't get a conforming local time.  Unfortunately, SSI is the only server side scripting I have (that's accessible over the Internet) at the moment.  One of these days, I'm going to get off my butt and get a developer-friendly hosting provider. 
• One other problem with my stylesheet is that it makes a couple assumptions about the query string you gave to Amazon, so it needs a bit more logic to look at the query parameters.

As far as the debate on xml:base, as a Microsoft customer, I sympathise with Dare's situation, but the argument that "the parser I use doesn't support it" smacks a little of the argument that we shouldn't use namespaces because it makes my code ugly.

I don't fully understand the Amazon API yet, but I do like the idea of being able to run an XSL filter on the server.  I'd sort of thought that Mark Baker was doing some handwaving when he talked about pipe and filter, but the base case is pretty fun to use, at least.  Thinking about the idea of generating my own XSL server side, it seems like there's an opportunity to test a 2nd level implementation.  I wonder what holes they've opened up by doing this.  On the innocent end of the spectrum, writing inefficient stylesheets.  Looking at their RSS 0.91 stylesheet, I see a couple unnecessary uses of //, which can really kill performance on big inputs.  Maybe Amazon's output is always small enough that they don't need to worry too much about that.  Also, I wonder what the effect of things like document() and <xsl:import/> would be - you could possibly use these to get around Amazon's size limit on XSLT source.