Re: container/member models

On Sun, Jan 13, 2013 at 4:24 PM, Roger Menday
<roger.menday@uk.fujitsu.com> wrote:
>
> 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 ?
>

Hi Roger,

I guess the question back would be where do you think it should go.
There is already introductory text in the spec.  If there is an issue
with that text, then it could be raised and this proposed.

Your text seemed like a different proposal than what the model is but
I can't really tell.  I can follow up on that thread with my feedback.

So given this train of thought, I think perhaps placing on a separate
comment section would make sense and Erik and editors can find the
right spot for it as WG members agree with the changes.

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



--
- Steve

Received on Monday, 14 January 2013 12:33:38 UTC