[microformats-discuss] STRUM, REST, and DETH

[Dr. Ernie Prabhakar]

Hi Mark,

> I guess I'm just a little confused about what you're suggesting and
> what it leads to - whether you are talking about a generic description
> layer for XHTML POST services (a way of using HTML dictionaries to
> define an allowable set of key/value pairs that can be accepted by a
> specific URI) - or whether you are looking to rebuild/replace the
> structure of form inputs with  dictionary lists. Maybe both?

A fair question.   I think what you describe may be the best direction:

> My perspective is that this kind of thing is already well supported by
> the structure of traditional HTML forms. To put it another way, an
> HTML form *is* a REST compliant service, and various automated clients
> exist (mostly testing tools) that can navigate HTML, fill out form
> fields, and submit the data.
>
> eg: http://simpletest.sourceforge.net/SimpleTest/ 
> tutorial_Browser.pkg.html

Cool! I"ve added that to from-examples.

In a sense, what I want to do is formalize a style ofHTML that makes  
it easy to build tools like that, without having to do all the  
clickthroughs etc.

I've just discovered TwistedPython, which seems like the easiest way  
to hack a demo to illustrate this principle.  Hopefully I'll have  
something this week, if no other crises come up...

-- Ernie P.



On Oct 11, 2005, at 6:26 PM, Mark Rickerby wrote:

> Hi Ernie,
>
>> 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.
>>
>
> My perspective is that this kind of thing is already well supported by
> the structure of traditional HTML forms. To put it another way, an
> HTML form *is* a REST compliant service, and various automated clients
> exist (mostly testing tools) that can navigate HTML, fill out form
> fields, and submit the data.
>
> eg: http://simpletest.sourceforge.net/SimpleTest/ 
> tutorial_Browser.pkg.html
>
>> 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.
>
> It's good practice - the principle of human readability (and standard
> visual design) dictates that each form field should be clearly
> titled/labeled.
>
>>
>> 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?
>
> AFAIK, this is used by some designers, but doesn't quite sit right -
> as the content of the label should be a readable description for the
> form field.
>
> It's also common to use definition lists for marking up forms (though
> arguably beyond the semantics of what a dl is supposed to mean)...
> Usually:
>
> <dl>
>   <dt><label /></dt>
>   <dd><input /></dt>
> </dl>
>
>> 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*.
>
> I'm still not quite sure what is gained from mixing these two aspects
> together (accepting POST data in both XHTML format and url-encoded
> key=val format)...
>
> I just wonder that the structure of inputs nested inside a form tag
> (with name attr being the key, and value attr being the value) already
> represents a dictionary, and that this is the default web (and REST?)
> standard.
>
> Perhaps an advantage of using xoxo is that you can create the kinds of
> web services that you're discussing without using form elements at
> all, and keeping the data format essentially human readable.
>
> I guess I'm just a little confused about what you're suggesting and
> what it leads to - whether you are talking about a generic description
> layer for XHTML POST services (a way of using HTML dictionaries to
> define an allowable set of key/value pairs that can be accepted by a
> specific URI) - or whether you are looking to rebuild/replace the
> structure of form inputs with  dictionary lists. Maybe both?
>
> Regards,
> Mark
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss

------------
Ernest N. Prabhakar, Ph.D. <drernie at opendarwin.org>
Ex-Physicist, Marketing Weenie, and Dilettante Hacker
Probe-Hacker blog: http://www.opendarwin.org/~drernie/