[microformats-discuss] STRUM, REST, and DETH

[Mark Rickerby]

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