Re: container/member models

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.

[1]: http://www.w3.org/2012/ldp/wiki/ISSUE-37

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

Received on Sunday, 13 January 2013 17:36:53 UTC