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
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
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
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.
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.
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.
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.
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.
<rsd:engineName>Blog Munging CMS</rsd:engineName> <rsd:engineLink>http://www.blogmunging.com/ </rsd:engineLink> <rsd:homePageLink>http://www.userdomain.com/ </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> <description referencedNamespace="http://schemas.xmlsoap.org/wsdl/" location="http://example.com/xml/rpc/url?WSDL"> <wsilwsdl:reference endpointPresent="yes"> <wsilwsdl:referencedService>rsd:MetaWeblog</wsilwsdl:referencedService> </wsilwsdl:reference> </description> <rsd:rpcLink>http://example.com/xml/rpc/url<rsd:rpcLink> </service>
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?
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.
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.
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.
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.
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!...
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 ...
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,...
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...