Re: container/member models

On 13 Jan 2013, at 17:36, Steve Speicher wrote:

> The wiki page for ISSUE-37 [1] has been updated to include the
> description of the model.  We can discuss next steps in the call
> tomorrow though I tried to summarize a the beginning of the page the
> intent and some next steps.

hi Steve, 

I've just read your notes about the intention of issue 37. I thought the stuff I wrote on Friday [1], would fit quite well into issue 37 discussions (and I've been working on content for the wiki - also prompted by Ashok). 

But, if it doesn't go there, where would it go ? 

regards,
Roger

[1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0040.html


> 
> On Sun, Dec 16, 2012 at 2:14 AM, Wilde, Erik <Erik.Wilde@emc.com> wrote:
>> hello all.
>> 
>> a few more details regarding ISSUE-37 and what would be important to
>> decide on. since i have already created the model description of AtomPub
>> on the http://www.w3.org/2012/ldp/wiki/ISSUE-37 page, i'll stick with
>> that, because we have to make the exact same decisions, in this way or a
>> slightly different way, but along the same axes. excuse my XML along the
>> way, but that is how that other model works. it really makes no difference
>> at all in the end; for the protocol, we need to have a data model will
>> well-defined semantics, and an interaction model that uses this data
>> model. let's start with the interaction model:
>> 
>> AtomPub allows to POST two kinds of things: application/atom+xml <entry>
>> at "regular" atom collections, and other media types when allowed by the
>> access policy of the server and advertised in the service document. when
>> clients POST <entry> resources, this will create a regular member entry,
>> and the server simply accepts and stores (and serves upon request) the
>> POSTed entry. when clients POST non-<entry> media types accepted by the
>> server, the server accepts the media resource, and creates a media link
>> entry. so the server now has created and manages two entries.
>> 
>> for POSTing <entry> resources, there's some magic hidden in Atom's data
>> model. for the AtomPub, it simply stores whatever clients POST, and it may
>> use the Atom metadata model to provide additional services, such as
>> providing filtering and/or sorting capabilities (which are outside of
>> AtomPub itself). so from that point of view, members are fully contained
>> in the collection, and only exist in that context. however, Atom's data
>> model allows <entry><content>... for embedded content, and <entry><content
>> src=""> for linked content. so it's completely ok for clients to POST such
>> an entry with a link to an AtomPub server, and while the server is not in
>> control of the content (it may be a link to anywhere), it will happily
>> manage the entry based on its Atom metadata. however, if you delete such
>> an entry, the linked content of course will not go away. but on the
>> protocol level, everything is fine: the semantics are you can POST
>> embedded or linked, and when you DELETE, you simply DELETE whatever you
>> POSTed. for media entries this is different, but that's because AtomPub
>> assumes that for media resources, even though there are two resources as
>> well (the media link entry and the media resource), both are managed by
>> the same server, and thus the protocol can be defined so that a DELETE
>> actually deletes both. AtomPub is kind of cautious here though and only
>> says that DELETEing the media link entry SHOULD DELETE the corresponding
>> media resource as well (http://tools.ietf.org/html/rfc5023#section-9.4).
>> 
>> this embedding model is possible courtesy of Atom's <content> model, which
>> says that @src should be treated (pretty much... excuse a slight
>> generalization here) in the same way as embedded content
>> (http://tools.ietf.org/html/rfc4287#section-4.1.3.2). because of this
>> definition of the data model, servers can choose to be blind wrt embedded
>> vs. linked content, and simply serve back whatever they have been handed
>> as the entries to manage (of course they also could have internal policies
>> treating these cases differently, but that's an option and doesn't need to
>> be addressed on the protocol level at all, it could just be a
>> service-level policy where a specific server would for example say "i am
>> not accepting linked content").
>> 
>> to start all of this, clients need to find out the capabilities of a
>> server. if a client is linked by a "collection" link from somewhere to a
>> server, it will not know whether that server is an AtomPub server, or an
>> LDP server. clients should be able to find out at runtime who they're
>> talking to. when they do an OPTIONS on the "collection" resource and it is
>> an AtomPub server, they will get something like Accept: GET POST and
>> Content-Type: application/atom+xml. when they do an OPTIONS on an LDP
>> server, they will probably also get something like Accept: GET POST, but
>> the media type would need to expose the server's LDP capabilities. then
>> clients can start understanding that they either need to compose <entry>
>> resources and POST them, or LDP resources and POST them (if they support
>> both media types).
>> 
>> cheers,
>> 
>> dret.
>> 
>> 
> 
> 
> 
> -- 
> - Steve
>