Re: container/member models

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

Perhaps we should start there, if LDP had the exact same motivating
use cases and requirements. Have you confirmed that?  I'm for learning
from other works, don't get me wrong, I just want to understand if the
work is motivated from the same cases or where they are different so I
can better understand what motivates the AtomPub model.

> 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.

This sounds right in the abstract but what is the client trying to do
that it needs to know?  The server could be a 3rd kind of thing too,
or 20 kinds of things.  Not sure we need to do AtomPub vs. LDP
discovery (or whatever you want to call it) but to be clear on how
clients can discover what the need to know for their case in hand.
For example, if the server can accept a POST to create a resource and
which content-types are supported could be enough.

>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.
>
>

Thanks for the useful information.   I have a little more time this
week that I plan to contribute to this and updating the spec with the
composition model resolution.


- Steve Speicher

Received on Monday, 17 December 2012 14:17:44 UTC