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 <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ microformats-rest mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-rest
