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

[Dimitri Glazkov]

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
>