It’s just data

RFC: Really Simple Discoverability

I hope this isn't too late.  Perhaps not, the spec isn't listed as 1.0 yet.  In any case, I feel really bad about not reviewing RSD before, expecially given that the RFC links to not one but three of my essays.  I have three comments, which I will give in decreasing order of importance:

1) In the examples, there is an "rsd" namespace which is defined but never used.  In order to use it, one would have to prefix each element with "rsd:".  A simpler fix is to simply define this as the default namespace for the document, by dropping the ":rsd" entirely from the declaration.  As it stands, I would say that the examples don't comply with the spec.

2) rpcLink presumes, well, RPC.  With protocols like the RESTLog Interface, there is not a single URL, but rather a set of them.  Yes, there is a base URL and one could munge it into this slot, but it really doesn't fit, and furthermore calling the slot RPC unnecessary provokes the more radical RESTians out there.

3) I would prefer to see a simple URL instead of a centrally managed list of "well known names".  That's not to say that there can't be a list of known URLs.  This is for two reasons: (1) to decentralize the maintenance, and (2) to provide more value by providing a direct link to the documentation of the protocol supported.

I haven't got time to read the spec right now, but it sounds a lot like WSIL

Posted by Simon Fell at

Sam, do I understand that this:

<rsd version="0.6" xmlns:rsd="" >

should be this

<rsd version="0.6" xmlns="" >

to default the namespace? I didn't get that info from the spec at all. Crap.

2) I'll have to think about this one. Maybe the element should be changed to "pcLink" for political correctness.

3) Other folks are beginning to float some ideas for this. All are under consideration.

No, It's not too late, but moving things would have been vastly easier yesterday. :) Today, there must be zero breakage without agreement.

Posted by Daniel Berlinger at

There was some discussion of RSD and WSIL on the BloggerDev Yahoo group.

Posted by Daniel Berlinger at


1) yes. Sorry.

2) FWIW, WSIL calls this attribute 'location'.

3) Cool.

Posted by Sam Ruby at

Daniel, you can change things as far as I'm concerned. It's quite easy at this point to update the Radio implementation.

Posted by Dave Winer at

Forgive me for my denseness, but what is the benefit of WSDL vs. WSIL vs. RSD? I thought I knew more than I do.

Is one restricted to SOAP? XML-RPC?


Posted by Mark A. Hershberger at

1) Thanks Sam. I looked at the spec, and your right on. Thanks. I'll get that together.

2) I'm going to look at RESTLog's API and try and write the RSD file. It'll be easy to tell if changes are required. Besides, I really don't want to alienate anyone. WSIL uses location... tricky suggestion. :)

Thanks Dave. It's a great time to get this stuff right.

Posted by Daniel Berlinger at

Mark, the difference is that when I asked Daniel to show me what one of his files looked like:

1. He did.

2. I understood it.

Basically I don't trust formats that don't have any implementations and where I don't understand what's going on. So I went with Daniel's format. That doesn't mean that we can't use other formats in the future. But I want to get going on tools, and I hate the way we have to configure them now. So I went this way first.

Hopefully that clears things up??

Posted by Dave Winer at

Mark: in a nutshell, WSIL and RSD are mechanisms to help you find WSDLs. Both solve the "hey mister server out there, what services do you offer?". WSDL defines individual interactions "if you send this here, you can expect to get that in return".

In theory, none of the above are limited to SOAP or XML RPC.

Posted by Sam Ruby at

Daniel: my suggestion was not meant to be "tricky". Looking at prior art is always worthwhile.

Dave: Apache has an implementation of WSIL.

Meta comment: in a perfect world, there would already be an internationally recognized standard which is widely adopted and deployed. We don't live in that world. So meanwhile, I make suggestions of incremental enhancements whenever it makes sense to do so.

Posted by Sam Ruby at

Sorry Sam, I didn't mean "tricky" with any negative connotation.

I did look at the prior art, couldn't find an implementations of WSIL, and based on an article I read by Timothy Appnel decided that the two are somewhat similar but speak to different audiences. Same with UDDI/WSDL.

I wrote elsewhere that I believe that WSIL is stepping stone to WSDL/UDDI and that Apache's implementation is based on that theory. That WSIL doesn't particularly (and wasn't meant to) stand alone.

Someone else suggested that we're all headed toward WSDL. May be, but I'm a big believer in little steps and gaining collective understanding. Dave and others call that bootstrapping. That's what RSD is. A small step on the road to getting things done.

Or like you say, an incremental enhancement, that makes sense to do.

Posted by Daniel Berlinger at

As an excercise, I thought I would see how close WS-Inspection comes to RSD's functionality. This isn't meant to imply I think RSD shouldn't exist, but purely for fun.

Here's an example RSD:

<?xml version="1.0" ?>
<rsd version="0.6" xmlns:rsd="" >
<engineName>Blog CMS</engineName>
<engineLink> </engineLink>
<homePageLink> </homePageLink>
<api name="Weblog" preferred="true" rpcLink="" blogID="123abc" />

And here is the equivalent in WS-Inspection, with some RSD-like elements and attributes added:

xmlns:rsd="" >

<rsd:engineName>Blog Munging CMS</rsd:engineName>
<rsd:engineLink> </rsd:engineLink>
<rsd:homePageLink> </rsd:homePageLink>
<abstract>This is the list of services supported by the Blog Munging CMS</abstract>

<service rsd:preferred="true" rsd:blogID="123abc">
<abstract>This is the MetaWeblog</abstract>
<wsilwsdl:reference endpointPresent="yes">


Posted by Keith Ballinger at

Thanks for the clarifications. Correct me if I'm wrong, but it looks like WSIL/WSDL gives me the endpoint of the protocol as well as a description of what goes across the wire.

RSD gives me the endpoint and expects me to have prior knowlege of how to implement the protocol.

If this is the case, then it becomes clearer how RSD is a "stepping stone" to WSIL/WSDL.

Still, it looks like WSIL doesn't /have/ to use WSDL. It appears that I could specify an endpoint for the Blogger 1.0 API by doing the following:

<?xml version="1.0"?>
location="xmlrpc://" />

Posted by Mark A. Hershberger at

FYI, we released support for RSD in Manila last night.

Posted by Dave Winer


Good grief, why do folks feel the need to reinvent the wheel so often? RSD serves the same purpose as WSIL, looks like WSIL, acts like WSIL, but isn't WSIL. It doesn't add anything new. What's the point of reinventing?

Posted by James Snell at

James, my experience is that expressing one's opinion in such a manner rarely elicits the desired result.

For whatever reason, the uptake of WSIL hasn't been very rapid.

Suggesions: focus your energies on finding and fixing the root causes of this. Or on convincing the likes of Daniel and Dave of the incremental value of support WSIL as a second discovery format - focusing on pragmatic and tangible near term benefits. Or on ensuring that migration to, or convergence with, the One True Format is likely to be as painless as possible when it does occur.

A XSLT transform of RSD to WSIL would be worthy of a Bing! A WSIL validator might not be a bad idea either.

Posted by Sam Ruby at

I realize I'm a bit slow, but could someone explain to me why everyone keeps saying that RSD is a reinvention of WSIL? I've read through the WSIL spec three times now, and every time it's still a format for a directory of service description files, nothing more.
From the spec: "A WS-Inspection document provides a means for aggregating references to pre-existing service description documents which have been authored in any number of formats." That doesn't sound like "where are the endpoints for known XML-RPC formats, and how do I identify the blog that links to this RDS file to those services?" to me.

Even if you can twist WSIL around to replace RSD, the WSIL spec seems to be telling you not to:

"While bindings may be used to provide hints about referenced documents, they MUST NOT be used as the final source of service description information."


"The binding MUST limit the amount of information about the referenced description which is exposed. It is not the intention of the WS-Inspection document to replace the description document."

And since Keith "One Of The WSIL Authors" Ballinger did RSD-in-WSIL a few comment up by including pretty much all of RSD in a WSIL file, rather than expressing the RSD data in WSIL, I just wouldn't think that they are covering the same ground.

Posted by Phil Ringnalda at

Sam and Phil, your latest posts are both gems. The way I see RSD is as evangelism in the other direction, saying to the WSIL and WSDL people "this is what we need now, show us how your formats do it." If it's not too ugly, and they don't get into a lot of arguments about how to do it (a sure sign of a not-baked format) then of course we'll also support their format. However, if Daniel hadn't moved this discussion would never happen.

Posted by Dave Winer at


When I read, "they MUST NOT be used as the final source of service description information", I don't see that this conflicts with Weblog Protocol discovery. I'm not describing the metaWeblog API, after all. I'm just saying "Hey you can use it here!"

Similarly, when I read "The binding MUST limit the amount of information about the referenced description", I have the same response. The WSIL I gave earlier was extremely limited. "Here's what protocols will work here."

I'm probably just ignorable. But no one has told me I'm wrong.

Posted by Mark A. Hershberger at

2.2.3 "The value of the location attribute MUST be a valid URL, and the description MUST be retrievable from that URL"

Is xmlrpc: a valid URL scheme?

Is a service description retrievable from xmlrpc://

Posted by Phil Ringnalda at

Phil, we use xmlrpc:// in SCNS.

It's a wonderful way to call procedures across the Internet.$9889#theFunStuff

Posted by Dave Winer


Why wouldn't "xmlrpc" be a valid scheme? I do not see anything in RFC 2396 that indicates that it wouldn't be considered a valid scheme.

And, if the server.* introspection namespace is used, then, yes, the service description is retrievable from the URL.

If formallity is what you are looking for, I'd be willing to draft an RFC that specifies the xmlrpc URI scheme with the server.* namespace specified for introspection.

Posted by Mark A. Hershberger at

(I should note that Steve Jenson has indicated that he will support the server.* introspection namespace.)

Posted by Mark A. Hershberger at

(I'm full of addendum's this morning. Steve Jenson is the man behind

Posted by Mark A. Hershberger at

Holiday Weblogging Blues.

The holidays are an exceptionally hectic time for my family and me. I'm already struggling to keep up with my mailing list and weblog reading. I was rather depressed I couldn’t have been more active in the recent discussion of discovery file formats and MLTFO (More Like This From Others) amongst others. Happy Holidays!... [more]

Trackback from tima thinking outloud.


Really Simple Discoverability

XMLifying my site, take 5: Really Simple Discoverability (RSD) is "a way to help client software find the services ... [more]

Trackback from Gotzeblogged


Phil's to blame for this one. Here is my "xmlrpc" URL scheme RFC.

Posted by Mark A. Hershberger at


Dave announces UserLand's support for RSD. In an email on bloggerDev, he writes: It's a simple and rational format, it solves the problem, and it's a real problem, been around a long time. The problem is how to make the tools easier to configure,...

Excerpt from at

RSD and AtomPub — Together again for the first time…

It Pays To Advertise: Joe Cheng: Configuring an AtomPub blog needs to be equally easy. For some reason, people in the AtomPub community don’t seem to like RSD (only Six Apart puts Atom endpoints in RSD). We need another autodiscovery...

Excerpt from turnings at

Add your comment