It's alpha, it's got bugs in it, but if you feel so inclined, give it a spin.

If you followed either the SOAP by Example or the BDG to WSDL part III, then RSSValidator.wsdl is all you need to get started.

Why a SOAP interface?  Suppose you have a site that is not published on the internet.  Or suppose you want to test your feed before you deploy it.  Of course, you can run it locally, but even though we made it real easy, not everyone wants to install and maintain another program.  Wouldn't it be nice if you could simply send your RSS feed off some place and have the results sent back?

Well now you can.  Simply POST your feed to the RSS Validator.  Since this code is liberal in what it accepts, neither a SOAP Envelope nor a SOAP Body is required.  Since it is conservative in what it does, you will always receive either a fully compliant SOAP response or a SOAP fault back.

Either that, or there a bug.  If so, let me know.  Once the bug smashing dies down, I'll write up information on how the client and server of this interface works as parts II and III of SOAP by Example.

  7:28:34 PM   Comment 

Tim Knip:  Groove needs a SOAP-header for security reasons and as Sam Ruby points out, SOAP-headers are around for some years now. Ok, Radio is BDG-compliant - clear - but then soap.rpc.client has to be dropped for interop with Groove.

Rick Olson: I had the same issue trying to get the Muse.Net client to work. It was a little more difficult to use the lower level Radio methods to send headers, but I just wrapped it up in my own wrapper and all was good.

Unquestionably, functions like soap.rpc.client provide value, but abstractions fail.  When they do isn't it nice to know that you can drop down to a lower level interface when necessary?

  2:20:27 PM   Comment