I’m revisiting how to extract the meta-publishing (AtomPub Collection creation) portions of the first AtomPub Hierarchy Draft into a standalone spec independent of hierarchy considerations. I am contemplating changing the actual process of creating the Collection. I see publishing a new Collection as very akin to publishing an AtomPub Media Resource. An example of the interaction I think makes sense is below: Imagine a new media type: application/atomcoll+xml, contents of the document are an app:collection element per RFC5023.
Advertising MetaPub Capability
A Collection advertises that it supports the creation of new Collections via the RFC5023 app:accepts mechanism:```
Creating a New Collection
A client creates a new AtomPub Collection by sending an application/atomcoll+xml document to the above collection URI:```
POST /collection HTTP/1.1
Host: example.org
Content-Type: application/atomcoll+xml
Slug: My New Collection
Content-Length: nnn
the content@src attribute points to the feed representation of the newly created Collection. This server also happens to include a link@rel=“alternate” pointing to the same resource
the link@rel=“edit-media” points to the Collection’s own metadata. A client can PUT to this URI to update the Collection configuration ( e.g. to add/change app:categories element)
Note the document posted to create the collection lacks a collection@href attribute. This is prohibited by RFC5023, what’s people’s feelings on ignoring/relaxing this requirement?
An Alternative Approach
An alternative approach is to stick with posting an Atom Entry document to cause the Collection to be created, but use an Atom Entry Document media type with some kind of parameter qualification that clearly communicates that the purpose of the Entry is to cause the creation of a Collection, so the above example becomes:```
POST /collection HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry;profile=“http://purl.org/atom/metapub"
Slug: My New Collection
Content-Length: nnn
I have a preference for the first approach, the primary motivation of the POST in each case is to cause the creation of a new Collection. I feel posting an ‘AtomPub Collection Document’ (application/atomcoll+xml) makes that intent very clear. The second option seems somehow backwards to me. However my colleague Nikunj has expressed a preference for the second option, and others have also implemented a similar approach. I’d really like to hear others points of view on this.
I dislike the Atom Entry boilerplate required by the second approach.
A weakness of both approaches is that it is not clear how the client should specify the metadata that may be included in the feed representation of the collection( e.g subtitle, rights, category, logo etc.). Perhaps that points to the need for a third option, similar to the first option but sending a document with a new xml syntax that allows specification of the feed metadata and the collection metadata, something like:```
atom:titleMy Spiffy New Collection</atom:title>
<app:categories href=“http://example.org/cats/forMain.cats"/>atom:feedatom:subtitleIts got lots of metadata</atom:subtitle>
atom:logo…</atom:logo>
… etc …
</atom:feed>