TruerWords Logo

Search TruerWords

Sign Up  Log On

“The "Value" of My RSD Approach...”

From: Seth Dillingham In Response To: 2613  Sample RSD Document
Date Posted: Wednesday, November 20, 2002 12:49:10 PM Replies: 2
Enclosures: None.

Brent and Daniel are having a conversation about RSD on Daniel's site. Brent's planning to support something like RSD (hopefully RSD's final format) in NNW.

Brent's thoughts are that the document needs to be kept incredibly simple, but I don't understand why he's taking it so far. Our intent (or mine, anyway) is that these documents will be automatically produced in the handshake between server-side weblog software (Conversant, Manila, Blogger, etc.) and client-side software like Archipelago, Sid (if Steve ever gets involved), and NetNewsWire Pro.

Daniel has a space for the documentation, but it's in the head area. Brent wants it removed altogether. I would prefer to have it included as an optional element or property of the <api> element, and I've updated my sample RSD file to show that. Daniel's argument for the documentation link is a good one:

At least this way I can give them a button that will pop open the docs page for their blogging software.

That's a good enough explanation for me. If the documentation link isn't in the RSD file, then don't show the button. Simple.

I've been asked to explain the "value" of what I've proposed.

The main difference between my proposal and Daniel's is the description of the API's. Daniel's assumes that all weblog API's will use a common set of settings and has specified those in the top level of the document. Mine creates one api element for each supported api, and puts the settings for each API within child elements of the respective api element.

Also, the settings elements are all named "setting," and given a name attribute to specify what setting is being described.

The value of this approach is that an api can use any number of "settings," and they're all defined within the scope of the api's section of the RSD document. An API that is completely unrelated to the others (like Conversant's) can now provide any number of settings, all with different names, without adding to the namespace used by the XML document. This actually makes it very easy to provide a DTD for the RSD file, because all possible element names have been defined.

Yet with all that, it remains very simple.

(No, I don't expect a DTD to be needed for RSD files, but it doesn't hurt to be producing valid xml, does it?)

Now my question to Daniel and Brent is, what problem do you have with my approach? What doesn't it solve? Do you agree that our intent is to have these files produced by the weblog software, eventually?

Discussion Thread:

There are no trackbacks.

is Seth Dillingham's
personal web site.
Read'em and weep, baby.