W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2013

Re: Proposal for containers

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Thu, 31 Jan 2013 05:14:55 -0500
To: Henry Story <henry.story@bblfish.net>, "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>
CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Message-ID: <CD2FFFBE.E905%erik.wilde@emc.com>
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>
>>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>;
>( AtomXML species these types in their content-type, which is the wrong
>place to do that. See:
>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.

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.


Received on Thursday, 31 January 2013 10:15:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:44 UTC