[microformats-discuss] DUHPER (WAS: XHTML-REST, STRUM, DETH, etc.)

Christopher St John ckstjohn at gmail.com
Tue Oct 18 11:02:25 PDT 2005

On 10/18/05, Dr. Ernie Prabhakar <drernie at opendarwin.org> wrote:
> More importantly, in talking to people I'm finding that the most
> compelling aspect of this idea is that you can create *one*
> implementation which provides both a machine-readable REST API and a
> human-readable website.  Very DRY! (Don't Repeat Yourself).

When I think of microformats, the kind of usage scenarios that come up are
things like extracting hCards and displaying them in a browser side-bar, or
spidering for semantic content.

Those things have in common a certain built-in robustness in the face of badly
formatted data. In the case of hCards because they are displayed to the user
in a way that makes it obvious if the data is bad, and in the case of semantic
search because bad formatting just means a slightly less relevant set
of results.

On the other hand, the way state-transfer mechanisms (in the general
sense, which
includes RPC and REST) are generally used assumes that the data is properly
structured. The issue is that since the information is designed to be
used without
human intervention, small mistakes can cause bad, hard to detect
failures. I'm not
saying the mechanisms _must_ be used that way, it's just what people normally
expect. It isn't the existing usage pattern for state tranfer, RPC-ish
or REST-ian,
either one.

Very preliminary thoughts, subject to change without notice. And there's always
the possibility I'm missing some fundamental points. (the earlier
thread that expressed
a burning need to comment before fully digesting the entire wiki and
mailing list archive
said it better than I could, so "ditto")


Christopher St. John <ckstjohn at gmail.com>

More information about the microformats-discuss mailing list