Floyd Fairness Fund

During the final week of the Tour de France, I published my initial doubts about the "science" accusing Floyd Landis of doping. All evidence since then reinforces my doubts.

Ultimately it all comes back to character: Do you believe the man or not? The evidence of doping that they have, alone, isn't convincing, but it would be consistent with doping. Lots of guys have gone to the mat lying. Floyd could just be one more.

I just don't think he is.

And now I know it. Because I don't think it's possible anyone, even Richard Virenque, would form a legal defense fund taking money from elderly cycling enthusiasts like me just to reclaim a ride in the pro peloton. If Floyd had doped and had created this fund... well, nobody is that low. If you doubt his word now, you are saying, Yes Hugh: He is THAT LOW.

I gave. I think it's important. It's really important that the innocent get off, if we're going to have faith in the convictions of the guilty.

Wait, *my* new publishing technique is unstoppable

[updated to correct an omission in POST description]

Bill outlines the conventional Atompub publishing pattern. I'm pitching this one:

GET Introspection URI

scan the list of workspaces for the collection you want to post the blogpost to. This list is not an Atom service document, but a microformat outline e.g. XOXO. (The Atompub WG considered and dropped using XOXO).

GET to Collection URI

read the nice atom feed

GET the "New Entry" URI from either the service doc or the feed doc.

Retrieve an XHTML microform describing how to construct a POST message

POST to the blogpost's collection URIthe action URI of the form.

push a blogpost formatted as a nice atom entryas URL-encoded form data.

GET or HEAD to blogpost URI

grab the blogpost

PUT or DELETE to blogpost URI

change or delete the blogpost

Web Service of the Future: Comment Spam

Guess what web technology, right now, most successfully uses microforms a.k.a. forms-driven web services: Comment spam. Spambots crawl the web, looking for form fields they recognize, completing them, and submitting them. There's no one universal blog comment document format. Each site tells the bot, by using typical names in form fields, how to complete the form.

Imagine you had some service you actually want agents to be able to understand: a fare search site. Farebots would query your site for fares from Austin to Bangalore leaving Thursday. They'd know how to fill out the form field because you'd annotate each one with some agreed class attribute. Doesn't this sound a lot more realistic than getting everyone to agree on a common fare search document?

Forms-driven Atom

Here's how forms-driven Atom publishing would work. Let's drop the Xforms idea, and take a page from the smart microformats people: We'll overload XHTML forms with semantics, so that blogging clients can parse them, fill them in correctly, and then POST or PUT them. Call the idea "microforms".

Want an example? Your browser, right now, can auto fill lots of form fields based on the field name. And your browser retrieves that information from its own little database. Let's just generalize that idea, and furnish client programs with the ability to understand lots more about the service it's exercising.

Where do we get the semantics for Atom? The Atom syntax document goes a long way. Henry Story has constructed an OWL ontology for Atom. This is a good starting point. We can use those property and class names in XHTML class attributes.

Remember the motivation: We want web services to spread as powerfully as the real WWW has. The Atom group believes RESTful web services will do it. But little in Atom, or any other document driven protocol, resembles the actual web we experience. In Atom, they agree on a document format that carries semantics that all servers and clients have to understand, or at least handle gracefully. That concept has no analogy on the web. When you order airline tickets, do you complete the One Universal Reservation form? No. Each airline or agency has its own form, because each business has its own differentiators.

It's the same in web publishing. Consider Moveable Type and Blogger. To create an entry for MT you fill out this form:





They have two places to enter content! One is the lead, the other is the "Read more...." section. There's no concept like that in Atom. I guess the MT guys will propose an extension. But then every other blogging service on the planet will have to handle the case where somebody submits an "mt:extendedContent" extension element. Blogger doesn't have that concept:



I marked up those screen captures with tags grabbed loosely from the Atom ontology. We can make up more. Here's a microform MT could present (modulo GUI labels and layout):

<form method="post" action="/feed/">
  <input type="text" name="title" class="atom:title"/>
  <select name="category" class="atom:label">
    <option value="Programming"/>
    <option value="Politics"/>
    <option value="Personal"/>
  </select>

  <textarea name="entry" class="atom:htmlContent"/>
  <textarea name="extended" class="atom:htmlContent"/>
  <input type="checkbox" name="draft" class="app:control" value="app:draft"/>
</form>

Later we can hash out the details of these class attributes. Maybe we do need an MT specific extension for that extended content. But only MT servers, or any service supporting extended content, ever will have to deal with clients that submit that field.

So the microforms idea is: You describe the semantics of the form elements in their class attributes. You program clients to GET forms, understand form elements, and fill them out correctly, getting the information from some kind of database, or from a live user.

If we do it well enough, we can build agents that syndicate stuff to all kinds of servers automatically.

(updated: fixed omitted class attribute in form example).

We're Writing Hardware

Using statically typed languages, we're constructing hardware, not software, says Steve. A great rant. Let me extend the analogy. Think about the bullet points they used to sell object oriented programming back in the 80s: "Hardened components", "Reusable". These qualities are the opposite of dynamic.

Wait! There's an alternative!

Common Lisp is in many ways really ideal: it's a dynamically typed language with optional type annotations (i.e. you build software, then selectively turn it into hardware), lots of great tools and documentation, all of the essential features of living software I've enumerated in this essay... However, it has stopped growing, and programmers can sense momentum like a shark senses blood.

Oh man. Don't give up on the old girl. The Lisp Renaissance is happening all around you. We have the popular book; now we just need the Django/Rails thing.

The Volkswagen Lisp

I've been working in Lisp for about six weeks now, and I am far enough along to
get this.

Quote of the day 01/08/2007

"I think smell certainly can be a terrorist mechanism, whether it harms people or not."