container/member models

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.

Received on Sunday, 16 December 2012 07:15:33 UTC