- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Tue, 22 Jan 2013 12:12:04 -0500
- To: Alexandre Bertails <bertails@w3.org>
- CC: Steve Speicher <sspeiche@gmail.com>, Henry Story <henry.story@bblfish.net>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
hello alexandre. On 2013-01-22 17:53 , "Alexandre Bertails" <bertails@w3.org> wrote: >>>Why can't we do this? A Container/Collection IS a resource. So >>> therefore POST'ing the representation of it seems like the most >>> obvious way to create one. >>fyi, atompub never specified creating collections. some people engineered >> around this by exposing übercollections, other by exposing specific >> resources (not collections) that you POST a new collection to. in our >> implementation, we give workspaces identifiers and then you POST to >>them. >> all of these ways work fine, and from all i've seen, people have used >>the >> well-defined representation of a collection as something to POST, and >>then >> this creates a new collection. >I'm not sure to understand how this works but you raised my attention. >Can you give an example? all of this of course is hypothetical: when you access the LDP home document, you GET a variety of interaction affordances that allow clients to start interactions with the LDP server. some wotk bu GETting a list of managed collections on the server, and then you can GET the actual collection content in a next step, and GET an actual entry in a next step. another interaction affordance provided on the home document is a resource that accepts requests to create new collections. call it a "collection factory". the LDP protocol says that to create a new collection, you POST the representation of what you want to create to that resource. once a client does that (and the server accepts the request), a new collection is created, the HTTP response will redirect you to the URI of the new collection, and the new collection will show up in the list of available collection. should we have workspaces or something similar (some way of "grouping" collections), then we have the choice of exposing individual "collection factories" for each of those groups, or to just have one factory and require that clients specify in the creation request which group the new collection should belong to. (in the latter case, we would have the option to have collections in more than one group, which would be harder to do in the former case). is that example detailed enough? if not, let me know. cheers, dret.
Received on Tuesday, 22 January 2013 17:13:07 UTC