On 3/27/06, toydi <[EMAIL PROTECTED]> wrote:
On 3/25/06, Mark Baker <[EMAIL PROTECTED]> 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
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
