Re: Proposal for containers

On 31 Jan 2013, at 11:14, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello henry.
> 
> On 2013-01-31 9:51 , "Henry Story" <henry.story@bblfish.net> wrote:
>> On 30 Jan 2013, at 16:23, Ashok Malhotra <ashok.malhotra@oracle.com>
>> wrote:
>>> B. To add a container to a container, POST a (child) container
>>> representation to a (parent) container.
>> Though there is an issue as to whether the type of the resource should be
>> specified or not in the HTTP Header eg:
>> Link: <<http://www.w3.org/ns/ldp#Container>;
>> rel="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"
>> ( AtomXML species these types in their content-type, which is the wrong
>> place to do that. See:
>> http://www.w3.org/2012/ldp/wiki/ISSUE-37#POSTing_a_link_to_another_resourc
>> e )
> 
> you seem to have a bit of a misunderstanding how this works in atom. atom
> only defines application/atom+xml. atompub then added the ;type= media
> type parameter, because (http://tools.ietf.org/html/rfc5023#section-12.1)
> it assumed that there cold be different processing models for both kinds
> of "atom things". the idea of the protocol still is that POSTed resources
> are self-describing, which means that when you send a <feed>, it's treated
> as a feed, when you send an <entry>, it's treated as an entry. the
> protocol even explicitly says that everything has to work as intended even
> if ;type= is never used.

I am not misunderstanding this. 
In section 9.2.1 of AtomPub the following example is given:
http://tools.ietf.org/html/rfc5023#section-9.2.1

       POST /edit/ HTTP/1.1
       Host: example.org
       User-Agent: Thingio/1.0
       Authorization: Basic ZGFmZnk6c2VjZXJldA==
       Content-Type: application/atom+xml;type=entry
       Content-Length: nnn
       Slug: First Post

The way Atom pub distinguishes the types of the content is 
by annotating the mime type. This works for something as limited
in design and scope as Atom, because the types of things it deals
with are either atom/entry or atom/feed elements. But in RDF 
where you could say the type of a text/turtle document could
be infinitely varied, you could not start defining these types of
things. Or if you did your type would have to have a URL as value.
Which is just to say that you are putting the information in the 
wrong place.

> 
> the idea of REST is that you can POST different things to the same URI,
> and then different things might happen. so it would be perfectly ok to
> POST both <entry> or <feed> to a <feed>, only that the spec doesn't want
> to have anything to do with it and says:
> 
> "This specification does not
>   specify any request semantics or server behavior in the case where
>   the POSTed media type is "application/atom+xml" but the body is
>   something other than an Atom Entry.  In particular, what happens on
>   POSTing an Atom Feed Document to a Collection using the "application/
> atom+xml" media type is undefined."
> 
> this means that if you want to support this behavior in an implementation
> (and there are implementations that do that), then you can simply accept a
> <feed> (and you might want to make this explicit by listing
> application/atom+xml;type=feed in the collection's accepted media types,
> but you don't have to) and build a hierarchical atompub service.
> 
> the important thing here is to keep in mind that POSTing can mean anything
> in HTTP/REST: it simply means that what you're doing is neither safe nor
> idempotent. what else it means depends entirely on *what* you are POSTing,
> and you can happily POST many different things to the same URI, and then
> server has to figure out what to do with these things.

I know that, that is not the problem.

> 
> cheers,
> 
> dret.
> 

Social Web Architect
http://bblfish.net/