Rev 06 - 24Jul2003 Latest version of the AtomAPI draft RFC is now available. Changes in this version: Added template editing interface. Moved to PUT for updating Entries. Changed all the mime-types to application/x.atom+xml. Changed 'edit-entry' to 'create-entry' in the Introspection file to more accurately reflect it's purpose.

Over a month ago I published a quite long and detailed story listing a slew of problems I had recently had with TI Tech Support. Yesterday afternoon I received a telephone call from Douglas Batts, the Director of World-Wide Technical Support for the Semiconductor Division of Texas Instruments. He called to apologize for the poor service I had received, explain some of the things I had experienced, and detail some of the changes they had made to ensure these problems wouldn't occur again.

GlueLogix is the creation of Larry Martin, one of my co-workers. From the home page: In most shops, the regular staff has its hands full building up the big pieces. That's the way it should be - your core people should be concentrating on your core technology. But when marketing pops up and says, "That's nice, but it's not a product without a USB jack," what do you do?

Even thought it was a steamy 90 degrees out today we spent some time this afternoon fishing at the local park. We had great success, with everyone catching at least two fish. This was their first time having success at this park, and it was Reilly's first fish ever. Every fish caught was photographed before being released back to the pond. Christopher was the first to land a fish. Austin was the second one to catch a fish.

A new mailing list has been created for discussing Atom. It is being graciously hosted by IMC, the Internet Mail Consortium. Special thanks to Paul Hoffman of IMC for setting up the list. From the charter: Welcome to the Web site for the atom-syntax mailing list. The atom-syntax mailing list is for developing a syntax for Atom (as compared to talking about its motivation). The AtomProject is an initiative to develop a common syntax for syndication, archiving and publishing.

Both Tim Bray and Paul Prescod are talking about SVG, which is quite timely. Just last week I was doing SVG myself. I had large chunks of data from disparate systems that I needed to visualize. The nice part about SVG being an XML vocabulary is that it is just as easy to generate programmatically as it is with a content generation tool. It didn't take me long to put together a Python script that ran over the files and plotted them out in a unified SVG file.

The fifth version of the draft EchoAPI AtomAPI RFC has been posted. No big changes in this release: Renamed everything Echo into Atom. Added version numbers in the Revision history. Changed all the mime-types to application/atom+xml. Please give feedback via the Wiki. In section 4.6, "editing user prefs", shouldn't you add an "Accept: application/atom+xml" header, so that the same URL can be made to handle both this REST API and for CGI/HTML?

The fourth version of the draft EchoAPI RFC has been posted. Rather large changes for this version based on the feedback from the wiki: Updated the RSD version used from 0.7 to 1.0. Change the method of deleting an Entry from POSTing <delete/> to using the HTTP DELETE verb. Also changed the query interface to GET instead of POST. Moved Introspection Discovery to be up under Introspection.

Just got a promised birthday present from Ziv. Thanks Ziv!

This entry by Jon Udell is rather disappointing, mostly because it sits on the false presumption that choosing and using an API to update a blog with is a binary decision. Far from it, the Blogger, LiveJournal and metaWeblogAPI have co-existed for quite some time, with clients supporting all of them. If the Pie project succeeds in producing a new API, that will not mean the immediate removal of those APIs, nor will all the current software magically break the instant the RFC is approved.

Latest version of the draft EchoAPI RFC in now available. Change log: Added a link to the Wiki near the front of the document. Added a section on finding an Entry. Retrieving an Entry now broken out into it’s own section. Changed the HTTP status code for a successful editing of an Entry to 205. Please give feedback via the Wiki.

Want an idea of what your RSS feed would look like as Echo? Tristan Louis has a converter to do just that. Here is BitWorkings feed as (not)-Echo, which by the way, validates using the recently updated Feed validator. Joe, is the content element correct in that feed ?, it appears to be double encoded, in that its both entity encoded and wrapped in a CDATA section. Posted by Simon Fell on 2003-07-11 Yes, you're right, it is double-encoded.

If you don't have the time to keep up with the Echo Wiki stop by Aaron Swartz' Echo Project News for all the latest developments.

The next revision of the draft EchoAPI RFC is now available: http://bitworking.org/rfc/draft-gregorio-02.html and if your are curious, the original XML is also available: http://bitworking.org/rfc/draft-gregorio-02.xml Changes from the last version: Entries are no longer returned from POSTs, instead they are retrieved via GET. Cleaned up figure titles, as they are rendered poorly in HTML. All content-types have been changed to application/not-echo+xml.

Part of the past weekend was spent refurbishing my grill. It's over three years old and the southern humidity has taken it's toll on the wood. So off came the rotting old wood, and on with some new, including some improvements, including a bar for hanging the tongs and more working space. I sure hope my wife doesn't see this. Every year I tell her that I don't need to clean up the rust on the grill; it adds flavor to the meat.

In a single HTTP Request/Response transaction there are a total of six places that information can be stored. If you are designing a web service, which of the six you choose depends on the context, i.e. where and how your service is going to be used. For an illustrative example, consider this elided request/response from the draft EchoAPI RFC. Here is the request: POST /reilly HTTP/1.1 Content-Type: application/not-echo+xml <?xml version="

Tim Bray, in A Web Interface for Web Publishing, outlined a quick version of a REST based Web Publishing interface using the not-Echo format. As Tim points out this is similar in spirit to what RESTLog does. To keep Forward Motion on this topic, I have posted a rough draft, in RFC format, of a similar publishing API using not-Echo. I have also created a discussion area on the wiki for this proposal.

There has been a great deal of forward motion in the Echo project today. Looks like the discussion about escaping HTML has come to a conclusion. Other areas that have settled seem to be Author and PermLinks. Things are looking very good for Echo, while at the same time I'm amazed at the resiliency of the wiki for hosting this kind of discussion. Full steam ahead.

I wonder if it would be efficient to use Bayesian methods to determine a documents encoding type? You know, for those pesky XML files that come in without an encoding type specified. It's certainly possible to match, say, known words to their byte patterns, and thus encodings. The question is why? Posted by Ziv Caspi on 2003-06-28

Quoted here for posterity: If you listen to some you'll hear hype that I control RSS. That's just ridiculous. I don't control RSS. I couldn't change it if I wanted to. [Dave Winer] If they want respect for the formats and protocols they implement, they must do RSS exactly as UserLand does. [Dave Winer] Something to reflect upon when people ask why we need a new format.