[uf-discuss] Re: [uf-rest] Microformats for <form> ?

[Dr. Ernie Prabhakar]

Dimitri & Mark,

I agree with all you said, but it didn't seem to address toydi's  
concern (or at least the one I have):  annotating forms may well  
solve the *input* problem, but it doesn't solve the *output* problem  
-- what toydi calls "response documents."

In particular, I don't believe it is possible -- certainly not easy  
-- to create a fully generic tools that will trivially present,  
generate, and consume all possible data.  Therefore, we need to be  
able to design each such tool by inspecting the interface.  However,  
if we don't know what all the pathways are, how will we know what  
responses our tool will need to be able to handle?

Humans are *much* better at pattern recognition than computers are,  
so I don't think the argument "Well, the human-readable web works  
fine without prior knowledge of response documents" is sufficient.

-- Ernie P.

On Mar 27, 2006, at 5:07 AM, Dimitri Glazkov wrote:

> Just a quick note: although Web Forms 2.0 spec is not widely
> implemented or used, I would highly recommend looking into it for
> inspiration/reuse:
>
> http://whatwg.org/specs/web-forms/current-work/
>
> :DG<
>
> On 3/27/06, Mark Rickerby <maetl at mcs.vuw.ac.nz> wrote:
>> On 3/27/06, toydi <teohuiming.work at gmail.com> wrote:
>>> On 3/25/06, Mark Baker <distobj at acm.org> wrote:
>>>> That's because the responses are self-descriptive.
>>>>
>>>> It would be possible to do both of course - be self-descriptive  
>>>> *and*
>>>> provide some info up front - but the fact that it hasn't been done
>>>> before for forms (AFAIK) is probably a pretty good indicator  
>>>> that the
>>>> tradeoffs don't work in its favour, at least in the general  
>>>> case.  I
>>>> mean, the technique is commonly used in other scenarios where the
>>>> benefits are clearer, e.g. <img src="foo.jpg" type="image/jpeg">
>>>> permits a client to avoid unnecessary image downloads for  
>>>> formats it
>>>> doesn't recognize, albeit at the cost of the consistency since  
>>>> media
>>>> type information isn't authoritative and may therefore be  
>>>> incorrect.
>>>
>>> Ah.. I see, the secret is the self-descriptive. :-)
>>>
>>> If let say we have a payment service, when user sends a payment
>>> document, it responds a self-descriptive receipt document on  
>>> success.
>>>
>>> A form is self-descriptive enough to allow users to submit the  
>>> payment
>>> document. But since users will only know the response details on
>>> runtime, if consider the user is dump machine and it's the first  
>>> time
>>> it consume the service, it may not have the receipt document  
>>> handling
>>> processor.
>>
>>
>> An HTML form is a description of parameters to a service. But by
>> default, doesn't say much, if anything, about what the server expects
>> those parameters to be, or whether they can be omitted. A Forms
>> Microformat would need to cover the required/optional status of
>> fields, and possibly specify expected data types.
>>
>> eg:
>>
>> <form method="post" action="/service/create">
>>   <ul class="form-post">
>>     <li>
>>        <dl id="title">
>>          <dt><label class="required">Title</label></dt>
>>          <dd><input type="text" name="title" /></dd>
>>        </dl>
>>     <li>
>>     <li>
>>        <dl id="link">
>>          <dt><label class="required">Link</label></dt>
>>          <dd><input type="text" name="link" /></dd>
>>        </dl>
>>     <li>
>>     <li>
>>        <dl id="description">
>>          <dt><label class="optional">Description</label></dt>
>>          <dd><textarea name="description></textarea></dd>
>>        </dl>
>>     <li>
>>   </ul>
>>   <div class="form-action">
>>      <input type="submit" value="Create"/>
>>   </div>
>> </form>
>>
>> The key heuristic is to identify required or optional fields. My
>> preference would be something along the lines of "any field unmarked
>> as required is optional". The problem is that how do you generalize
>> this, given the vast range of uses and expectations for POST requests
>> (I suspect this is why a forms format hasn't worked out thus far).
>>
>> Data types, I would try and get away with avoiding. Just assume
>> everything is a string, and let the server do the dirty work. The  
>> goal
>> with exposing interfaces like this should be to keep the data
>> requirements as simple as possible (which also means having as few
>> required fields as possible).
>>
>> An additional issue of more importance than you might think is
>> styling. I have a suspicion (and this is from experience) that
>> designers will never concieve any two forms in exactly the same way,
>> and that for various reasons, to do with readability,
>> understandability, visual heirachy, human vision, etc, it's not  
>> always
>> possible to use the same repeating XML structure to represent
>> repeating parts of a form. Something will always require special
>> treatment and this soon becomes a fight against the restrictive  
>> visual
>> possibilities of browsers.
>>
>> The main concept as I see it, would be to specify a common
>> presentation of "required" and "optional" fields, that gives enough
>> info for both a machine readable service description and a useful
>> template for designers to work from. The question is thus how  
>> close to
>> a schema you need to push the XHTML definition of the format, to
>> balance design flexibility with the required structure. For example,
>> does this belong to the same format as the example above?
>>
>> <div class="form-post">
>>   <form method="post" action="/service/create">
>>     <div class="form-element">
>>       <label>Title</label> (<span class="required">*</span>)
>>       <input type="text" name="title"/>
>>     </div>
>>     ... etc ...
>>   </form>
>> </div>
>>
>> Where do you draw the line?
>>
>> In terms of toydi's comments about response formats and  
>> expectations -
>> you would have to assume that all responses default to text/html,
>> asking to see anything different is probably a task for HTTP, and not
>> quite within the scope of a Microformat. Unless I've misunderstood  
>> the
>> point here.
>>
>> In any case, the first step would be to research common usage and
>> gather real case studies of form markup from the web. Also to  
>> document
>> any real world problems that give a good indication of requirements
>> for human readable forms that also need to function as a service
>> description.
>>
>> Sorry if I'm being too verbose, it's really hard to be consise on  
>> this topic.
>>
>> Regards,
>> Mark
>> _______________________________________________
>> microformats-rest mailing list
>> microformats-rest at microformats.org
>> http://microformats.org/mailman/listinfo/microformats-rest
>>
> _______________________________________________
> microformats-rest mailing list
> microformats-rest at microformats.org
> http://microformats.org/mailman/listinfo/microformats-rest