Re: container/member models

hello steve.

On 2012-12-17 7:17 , "Steve Speicher" <sspeiche@gmail.com> wrote:
>On Sun, Dec 16, 2012 at 2:14 AM, Wilde, Erik <Erik.Wilde@emc.com> wrote:
>>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.

AtomPub was clearly motivated by defining a protocol for how to upload
blog posts to blog hosting services. several proprietary protocols existed
at the time, and they were all very badly designed. AtomPub had the goal
to play well with Atom, and allow clients to as easily produce Atom
content as they could consume it. the media resources, for example, are
pretty much pictures you'd like to include in your blog. categories are
tags or actual categories. and so forth. you can bend AtomPub to some
other scenarios, but the motivating one were blogs.

>This sounds right in the abstract but what is the client trying to do
>that it needs to know?

uploading new things to the collection.

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

AtomPub vs. LDP is just an example. what we need is to allow any kind of
client to find a link that it follows because it wants to upload something
to a collection, and then the client can take it from there. what the
client is linked to could be something XMLish like AtomPub, something
RDFish like LDP, or something JSONish. we don't want to limit our ability
to play in scenarios where these possibilities exist.

>For example, if the server can accept a POST to create a resource and
>which content-types are supported could be enough.

maybe, and yes, in AtomPub you'd point to a collection and say it's
AtomPub-enabled and then the client can start POSTing. in this case,
AtomPub has a content-type to expose, but LDP hasn't (so far).

thanks and cheers,

dret.

Received on Wednesday, 19 December 2012 06:06:39 UTC