Paul Downey poses some interesting considerations for what a mashup consists of.  I think I’d list a pretty different set of criteria, but for now I’ll just start by comparing a mashup hosted by the WSO2 Mashup Server against his list to see how we stack up:

• Zero touch: +1.  Each mashup is accessible, documented, try-able, and so forth right out of the box.  The admin console makes them discoverable, and if you have a user account (email-validated guests are supported too) you can tag, rate, comment a mashup to build a community around them to make any touch beyond "zero" positive and reciprocal.
• Safe: +.5.  The Mashup Server supports and encourages safe interactions, but it does not prevent users from hanging themselves if they so choose.  That is, I can have an operation exposed through GET, explicitly marked as safe by the author even, that has seriously detrimental side effects.
• Cool URIs: +1.  Each mashup has neat URIs for the endpoints, for the metadata and tooling associated with it, for the admin capabilities associated with it, and even for accessing the operations over HTTP.
• Open data formats: +1.  We’re partial to XML and use Web Services under the hood, but also provide bridges to HTML, JSON, Feeds, etc.
• Eschew RIA: +1.  By default we don’t provide any rich interface.
• HTML form access: +1.  By default we do provide an HTML try-it form, and stubs to quickly build your own HTML pages.
• Accessible URIs: +1.  All endpoints are available through both http and https by default.  Mashups can be easily migrated outside local contexts so their visibility is greater.  E.g. mooshup.com.
• SOAP/WSDL: -1.  Everything we do has rich metadata and SOAP 1.1 and SOAP 1.2 bindings along with the REST/POX binding, and we also make it easy to consume web services in these formats.  However, you don’t have to know anything about these formats to write a successful mashup - they’re just valuable parts of the plumbing.  So maybe a -1 is too stingy.
• Authentication: +0.  We support username/password and Infocard to access the Mashup admin site, but there isn’t a drop-dead simple way to restrict access to the service based on these controls.  Not too hard to provision higher levels of security using WS-Security, but I’m not sure Paul would agree that’s sufficient.
• Scratch your itch: +1.  Subjective, but the whole product is designed to serve the needs of individual developers to hack up services as easy as they can hack up a simple web page.
• Fun: +2!!  As long as you’re willing to hack a bit of Javascript.

So I think the Mashup Server stacks up pretty well using Paul’s criteria, which I think can be summed up as "has a nice web interface" and "fun and easy".  But some of Paul’s criteria don’t fit with that summary and those are unsurprisingly the ones I take some issue with:

RIA: I don’t see any reason why a rich interface to a mashup is always bad.  Only when it locks up the data in a way that’s impractical to reuse.  In our model, we support the separation of content and presentation in order to lift the limits on the kinds of presentation environments the user prefers.  A single mashup can (and ideally should) support as many presentation media as are appropriate, including simple web pages, RIAs, feeds, notifications and messages, portlets, widgets, whatever.  If an RIA "scratches my itch" then what’s wrong with it?

For example, my iPod Touch comes with a YouTube app, which is an RIA for the YouTube site optimized to the screen limitations of the product.  I can also point Safari right at YouTube, but the optimized version actually is easier for simple access.  Is this bad?  It really depends on what the consumer wants.  I agree dead ending in an RIA may be inappropriate for some users of that service, but providing an RIA front end to a clean and well-documented interface that can be repurposed in other ways seems like a good user-centered feature that even Paul would support. I think he probably meant this item to mean "Does the site rely solely on so-called ‘rich user experience’ technologies in a way that precludes data from being accessed though a nice web interface?"

SOAP/WSDL: I understand why Paul would add this to the list.  Up until the Mashup Server Web Services were just too hard to consume to allow them to stand on a list with "scratch your itch" and "fun".  However I think we’ve turned the corner on that.  A Mashup Server author rarely has to even consider whether SOAP is involved in delivering a Web Service - we can take care of that for them.  Right now it’s simply an alternative to the REST interface.

As for WSDL, in the Mashup Server it strongly supports the other goals of zero touch, cool URIs, and open data formats.  I’m pretty tired of doing one-off hand coding to access REST sites or sucking up their hand-crafted and varying-quality stubs.  WSDL has a big role to play in simplifying these interactions for the developer, in a way that I think Paul would appreciate.  It’s a primary artifact in providing the "nice web interface" that we all agree is invaluable.

Anyway, thanks Paul for a provocative post!