W3C home > Mailing lists > Public > public-ldp-wg@w3.org > October 2012

Re: Speech Acts, indexicals, REST & RDF

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>
Message-ID: <CCA41AF4.941B%erik.wilde@emc.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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:32 UTC