The Well-Formed Web

Timothy Appnel has taken a detailed look as the RESTLog API. First off I would like to say thanks for the careful review and taking the time to offer feedback.

Also of issue, the API and the tool are currently married.

Excellent point and one of the issues I did want to resolve. The documentation for the API needs to be seperated from the description of how I implemented the API in Python. This is important to get the API to stand on it's own and to make it easier to document other implementations of the RESTLog API. I would be real interested in seeing Perl, PHP and .Net implementations.

Another such instance is the template interfaces that assume only two templates are in use -- one for HTML and another for RSS. This of course is not the case for most other tools.

A limitation I ran into myself just today. I also have a file base.css that is used to style the pages. So I could either add a new content-type for RESTLog.cgi/template, right now it understands HTML and RSS, or I could go for a more general solution. Now I doubt that just three files is enough to handle all the templating in the future so I am going to go back and implement a more general solution. That is a GET on RESTLog.cgi/template?xml will return an XML file that contains a list of template files that can be edited. The list will contain a short description of the file and the URL where it can be edited. On the client side that will allow me to replace the "Edit RSS Template" and "Edit HTML Template" buttons with a combo-box listing all the template files available for editing, and a single "Edit Template" button.

However, the interface needs to be more specific by setting very clear constraints and guidelines particularly when it comes to RSS 2.0.

The profile RSS 2.0/XSS-extensible is what I had in mind when I specified using RSS 2.0 in the specification, with the exception of specifying the default namespace.

The <description> element was original designed to carry an excerpt of the entry. Something like <content:encoded> could be used instead, but should an element that is core be in a module?

I don't see a problem with putting a text-only excerpt in the 'description' element and the content in 'content:encoded', I have already seen this practice in MT feeds. As far as using an element not in the default namespace, I have already done that with the 'dc:date' element.

I think this effort is a good idea that has been long overdue. I'm enthusiastic to see it advance. Hopefully my comments are helpful in doing so.

They have been very helpful. Thanks.