[microformats-discuss] STRUM, REST, and DETH

[Dr. Ernie Prabhakar]

Hi all,

On Oct 7, 2005, at 3:52 PM, Danny Ayers wrote:
> On 10/7/05, Dr. Ernie Prabhakar <drernie at opendarwin.org> wrote:
>> http://www.opendarwin.org/~drernie/C395201355/E20051006235324/ 
>> index.html
> 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:
>
> http://www.xml.com/lpt/a/2003/10/15/dive.html

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:

http://microformats.org/wiki/forms-brainstorming

DETH is intended to be the microformat (or HTML compound, whatever)  
for XHTML Basic Forms:

http://www.w3.org/TR/xhtml-modularization/ 
abstract_modules.html#s_sformsmodule

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  
significantly) self-documenting.

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- 
value list.

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  
strictly necessary.

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  
work?

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:

http://www.opendarwin.org/~drernie/deth_example.html