[microformats-discuss] STRUM, REST, and DETH
Dr. Ernie Prabhakar
drernie at opendarwin.org
Tue Oct 11 15:15:32 PDT 2005
On Oct 7, 2005, at 3:52 PM, Danny Ayers wrote:
> On 10/7/05, Dr. Ernie Prabhakar <drernie at opendarwin.org> wrote:
> What would be very helpful with grokking the idea would be examples of
> the kind of messages that go over the wire. Something like the
> descriptions MarkP uses here:
Okay, I've been noodling some more about how to clarify the concepts
behind STRUM, and particularly how it relates to REST.
I've stripped the idea down further to something I call DETH: like
REST, but more so. :-)
DETH = Dictionaries Encoding/Transmitting HTML.
I've started mocking it up on the forms-brainstorming page:
DETH is intended to be the microformat (or HTML compound, whatever)
for XHTML Basic Forms:
That is, it is a stylized convention for how to parse useful
information out of a human-readable structure. But not just any
information. The goal, in fact, is to extract REST-compliant web
services out of XHTML forms. Not only would this allow you to use a
generic web browser to invoke/test these web services, but it also
ensures that the API is (at least minimally, and possibly
The idea is that a DETH web service is described by a URI, e.g.,
"http//somesite.com/users". You can either:
a) do a GET (with no body) against that URI, or
b) do a POST containing a 'dl' dictionary or an url-encoding key-
The reply would contain at least one "class=deth" form or anchor
which could be parsed to determine which messages could be sent as
followup. And so on, and so on...
To be sure, this is not a "full" REST solution. It wouldn't support
PUT or DELETE, or any input more complicated than a dictionary. But
that's the point -- the goal is to build the simplest possible system
that does *any* useful work, so we can find out where the real
pressure points are *in practice*. Hopefully this gets us 80% of the
benefit with 20% of the effort. Actually, I think it is more like
51.2% (80x80x80) of the benefit with 0.8% (20x20x20) of the effort,
but you get the idea.
There's a few questions about the design pattern I'm unsure about.
Is the Microformat Zen here to conform as closely as possible to
existing (HTML 4) idioms, even if sometimes ambiguous, or make
'class=deth' a strong contract a la XOXO? For example:
a) Should we require labels for *all* inputs (except submit/reset)?
This seems much more descriptive and human readable, but isn't
b) Should we nest inputs inside labels? That keeps things nicely
grouped, but prevents us from using tables for layout. Is that an
important degree of freedom to preserve?
c) What are the minimum attributes that must be specified make this
This is somewhat tricky, since not all entries have 'input' (some use
'select'), and HTML inputs rarely close their end tags.
Apologies for the rambling, I'm still trying to get my -own- head
around the idea. Feedback welcome....
-- Ernie P.
P.S. Rendered (but non-working) examples are available at:
More information about the microformats-discuss