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. If forms are the only service description exposed to users, it seems not containing enough info to let users to pre-configure their user machine to handle potential response documents. Does it mean that we need *something else* to expose more info? or do I miss some key points here? -- Teo HuiMing (toydi) teohuiming.work at gmail dot com _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss