[microformats-discuss] STRUM, REST, and DETH

Tue Oct 11 15:15:32 PDT 2005

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