- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Fri, 25 Jan 2013 10:39:41 -0500
- To: "Eric Prud'hommeaux" <eric@w3.org>
- CC: Henry Story <henry.story@bblfish.net>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
hello eric. On 2013-01-25 16:30 , "Eric Prud'hommeaux" <eric@w3.org> wrote: >I'm confused by this. I'd have thought that LDPC and LDPR were the >*interaction* model, and that we want to steer clear of the data >model. (In fact, we hamper our goal of wide utility if we make demands >of the application's internal model.) i am sure i could have done a better job at explaining this. there data model in the sense i am using this term means the resource state as managed by the server, but by this i mean the protocol machine of the server. in the end, this is managed and persisted somehow but like you say, this is of no concern to us. but we want to have a clear idea what it means for a client to GET a list of the first 10 items in a collection, and then find a link to the next 10 for paging. this is not at all represented in the protocol data model, which just talks about a collection and its entries. the "page size" then becomes part of the interaction model (something a client can specify in a request), and then needs to be translated by the server into something that produces the appropriate result as a response. for this, the interaction model ("a client has the capability to specify a positive integer as a page size when requesting collection contents") must be mapped into the data model, and it is this separation of the interaction (page size) and the data (a collection's entries, which are not paged in any way) that i was referring to. i am sorry if this caused any confusion. cheers, dret.
Received on Friday, 25 January 2013 15:40:20 UTC