Meta-Pubs Again (Again)

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:

<feed xmlns="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app">
  <link rel="self" href="http://example.org/collection"/>
  <app:collection href="http://example.org/collection">
    <title>Collection Feed</title>
    <app:accept>application/atomcoll+xml</app:accept>
    <app:accept>application/atom+xml;type=entry</app:accept>
  </app:collection>
  ...
</feed>

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

<collection xmlns="http://www.w3.org/2007/app">
  <title xmlns="http://www.w3.org/2005/Atom">My New Collection</title>
  <categories href="http://example.org/cats/forMain.cats"/>
</collection>

Server responds with:

HTTP/1.1 201 Created
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/my-new-collection.atom

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>My New Collection</title>
  <id>urn:uuid:de46e3a1-e489-41a6-88a6-21e7f0e8e2d8</id>
  <updated>2009-06-12T12:13:46Z</updated>
  <author><name>Daffy</name></author>
  <summary type="text" />
  <content type="application/atom+xml;type=feed"
     src="http://example.org/my-new-collection"/>
  <link rel="alternate" type="application/atom+xml;type=feed"
     href="http://example.org/my-new-collection"/>
  <link rel="edit-media"
     href="http://example.org/my-new-collection.atomcoll" />
  <link rel="edit"
     href="http://example.org/my-new-collection.atom" />
</entry>
  • 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:

<feed xmlns="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app">
  <link rel="self" href="http://example.org/collection"/>
  <app:collection href="http://example.org/collection">
    <title>Collection Feed</title>
    <app:accept>application/atom+xml;type=entry;profile="http://purl.org/atom/metapub"</app:accept>
    <app:accept>application/atom+xml;type=entry</app:accept>
  </app:collection>
  ...
</feed>

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

<entry xmlns="http://www.w3.org/2005/Atom">
  <title>My New Collection</title>
  <id>urn:uuid:eb53f957-b7c0-4484-bf0b-c0a6948a33f5</id>
  <updated>2009-06-12T12:13:43Z</updated>
  <author><name/></author>
  <summary/>
  <app:categories href="http://example.org/cats/forMain.cats" xmlns:app="http://www.w3.org/2007/app"/>
</entry>

HTTP/1.1 201 Created
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;profile="http://purl.org/atom/metapub";charset="utf-8"
Location: http://example.org/my-new-collection.atom

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>My New Collection</title>
  <id>urn:uuid:de46e3a1-e489-41a6-88a6-21e7f0e8e2d8</id>
  <updated>2009-06-12T12:13:46Z</updated>
  <author><name>Daffy</name></author>
  <summary type="text" />
  <content type="application/atom+xml;type=feed"
     src="http://example.org/my-new-collection"/>
  <link rel="alternate" type="application/atom+xml;type=feed"
     href="http://example.org/my-new-collection"/>
  <link rel="edit"
     href="http://example.org/my-new-collection.atom" />
  <app:categories href="http://example.org/cats/forMain.cats" xmlns:app="http://www.w3.org/2007/app"/>
</entry>

My Two Cents

  • 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:
    <collection xmlns="http://purl.org/atom/metapub" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:app="http://www.w3.org/2007/app">
     <atom:title>My Spiffy New Collection</atom:title>
     <app:categories href="http://example.org/cats/forMain.cats"/>
     <atom:feed>
      <atom:subtitle>Its got lots of metadata</atom:subtitle>
      <atom:logo>...</atom:logo>
      ... etc ...
     </atom:feed>
    </collection>

Feedback Please

I’m very keen to get people’s feedback on the above proposals before attempting to draft another I-D revision, please leave your comments here or on the atom-protocol mailing list (http://www.imc.org/atom-protocol/)

Advertisements