- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Wed, 17 Oct 2012 14:33:05 -0400
- To: public-ldp-wg Working Group <public-ldp-wg@w3.org>
- CC: Henry Story <henry.story@bblfish.net>, Roger Menday <roger.menday@uk.fujitsu.com>
hello all. On 2012-10-17 05:48 , "Roger Menday" <roger.menday@uk.fujitsu.com> wrote: >I prefer the function described in [5] as "providing a block of data, >such as the result of submitting a form, to a data-handling process". >Isn't form submission is a good model ? - and it would be good to read >more discussion about the LDP equivalent of forms (?) that's very much the REST model: you pass your state (a representation of your intent) to the server, which then does whatever it is doing, and as a result might change server state, including possible creating new server resources. you might then be redirected to those, and in the typical example of a [client state: book order; server state: accepted and executing book ordering process] scenario, there of course is a very big difference between what you're submitting, and what ends up being server state. interestingly, right now over at REST-discuss there is a debate around forms. the question is how much forms should be machine-readable, i.e. how much does REST force us to represent the expectations of a form-handling process so that in case of changes in those expectations, clients can adapt. in HTML, that works well because the model of what i am supposed to submit (at least syntactically) is handed over to me at runtime (when i GET a form). also, the form has rules about how to represent any form submission and send it to the client, so there is a runtime contract between the client filling out the form, and the server accepting the submission. cheers, dret.
Received on Wednesday, 17 October 2012 18:38:10 UTC