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."

Is Atompub Superfluous?

I hate to suggest this at such a late stage -- Bill and Joe just published the twelfth rev of Atompub -- but do we really need Atompub?

All we need is RFC 4287, plus maybe the service description doc in Atompub.

Atompub tells you how to identify URLs where your application can POST documents of certain types. That's not a whole lot better than some so-called "RESTful" API that tells you how to construct a URL. At design time, I'm learning more about your application than I need to know.

My proposal: Once you've located the URL of a what they call an "edit" link, you should be able to GET a form from that link, describing what you can POST there. Since we already have well defined semantics for the XML elements of Atom entries, an edit URL could return an XForm model:

<model>
  <entry xmlns="http://www.w3.org/2005/Atom">
     <link/>
     <updated/>
     <summary/>
     <content type=""/>
  </entry>
  <submission id="form1"
                 action="entries"
                 method="post"/>
</model>

1. This pattern --- getting a form, filling it out, and submitting it -- differentiates the web, REST style from RPC. In RPC, the programmer learns an API at design time; on the web, clients discover the "API" at run time.

2. We sidestep lots of arguments on the APP mailing list that are driven by different ideas about expected behavior; here, the server tells you its behavior. This server could not honor an atom:id should you submit one. So, it doesn't ask you for one.

3. Extensions understood by the server? Don't worry: if the server doesn't ask you for it, it won't honor it. Example: Atom Threading Extension. A very nice server could offer a catchall element (to be invented) where an APP client might stuff all the custom extensions it really wants preserved.

4. We can evolve the Atom syntax without argument. Old servers will never request newly defined elements so will never have to deal with them. I'm guessing this is where Mark is going with reference to semweb.

MVC Considered Harmful

Struts 2, the popular Java webapp framework, like other frameworks, advertises a Model-View-Controller architecture. MVC seems to be an item on a checklist that frameworks think they have to have. Now, MVC is a great architecture for building desktop applications, with a user interface posting messages through a controller, to query or update a model. But the skeptic would ask, Does the web really feel like a desktop application?

What is wrong with this picture?



Notice the central concept of a Struts application is the Action. Building a Struts app is constructing a bunch of Action classes. The Struts controller accepts requests and maps the URL to an Action. Ahem. The web is not built upon Uniform Action Locators, is it? An Action implies a verb, and that is the way developers model applications under Struts and other MVC webapp frameworks. In fact, Struts typically identifies Action URLs by the the extension ".do" -- the verb "to do".

Struts misses the concept of Resource. You can't really model a web application without conceiving it as a collection of resources, identified by URI. I think Django is on to this. In Django, you furnish the framework with a map of regular expressions to callback functions. The Django docs call these callback functions your "views", but of course, if done correctly, they are really your resources. (Interestingly, the Django FAQ addresses the question Is Django an MVC framework and has evolved the answer, from this to this. They can't bring themselves to acknowledge a complete break with some form of MVC).

A well architected webapp will organize around Resources and Representations. There are typically four methods on a Resource. Omitting some details, you have

Representation Resource.get()
Representation Resource.post (Representation)
Representation Resource.put (Representation)
void Resource.delete()

To handle a request, you

1. Identify the resource given its URI, and instantiate it
2. Call the method, passing the request representation if any.
3. Respond with the returned representation.


Resources are probably not much like your domain model. You'll have to map Representations to Resource instances, and Resource instances to, say, database queries. A good architecture abstracts out dispatching to methods based on types of Resources and Representations, and affords a loose coupling between your domain model and the Resource layer. These are sound principles that also will help your webapp play well with REST web architecture. But all dispatch and loose coupling is not MVC.

Google Boomerang

Blogger, the Google-owned engine behind this blog, just went final with a major new rev. But it continues to generate massively invalid XHTML, and there's nothing authors can do -- it's bugs in the new templating system. This page you're reading, for example, gets 864 validation errors as of today.

Arne Bleijs made this pithy observation:

I suddenly remember some quotes from the annual conference of the
American Association for Artificial Intelligence (AAAI), this summer in Boston. After Sir Tim Berners-Lee held a keynote speech about the Semantic Web. Peter Norvig, Director of Research at Google challenged him afterwards:

"What I get a lot is: 'Why are you against the Semantic Web?' I am not against the Semantic Web. But from Google's point of view, there are a few things you need to overcome, incompetence being the first," Norvig said. Norvig clarified that it was not Berners-Lee or his group that he was referring to as incompetent, but the general user."

"We deal with millions of Web masters who can't configure a server, can't write HTML. It's hard for them to go to the next step. "

Somehow this sounds like a Google Boomerang hitting Blogger Beta. How can it be possible that Google complains about incompetent webmasters and is not able to produce valid XHTML?