PaceControlResource, PacePubControl, PacePubStatusResource... seeking consensus

[James M Snell <jasnell@xxxxxxxxx>]

The discussion about publication control was left somewhat up in the 
air.  As these are still marked as "Currently Under Discussion" we need 
to see if we can drive some consensus on these.  PaceControlResource, 
PacePubControl and PacePubStatusResource all approach the problem from 
slightly different angles.  I intend to update PaceControlResource so 
that it fits the profile of an actual proposal with actual proposed spec 
text but want to run this by the group first to see if we can come to a 
somewhat rough consensus on the concept before working to get consensus 
on actual draft language.

1. Define a new Control document.  Media type is 
application/atomcontrol+xml. 

   <atom:control>
      ...
   </atom:control>

   The content of the control document is zero or more namespace 
qualified extension elements expressing implementation specific control 
parameters (e.g. whether or not comments are enabled, etc)

   The purpose of the control document is to specify various 
application specific control parameters that affect how the application 
handles the resource.  e.g. should the app enable comments for an entry? 
should it digitally sign the entry? should it enable trackbacks? etc

2. A default control document can be applied to an entire collection by 
POST'ing the control document to the Collection URI.  A collection's 
default control document can be retrieved through a GET using content 
negotiation (e.g. Accept: application/atomcontrol+xml)

3. A control document can be applied to an individual collection member 
by POST'ing the control document to the member's URI.  The member's 
control document can be retreived through a GET using content negotiation

....Now here comes the potentially controversial part....

4. To add a new member to a collection and apply a control document to 
that member in a single operation, POST a multipart/mixed message to the 
collection URI wherein the first part of the message contains the 
contents of the resource.  The second part of the message contains the 
control document to be applied. e.g.

   POST ...
   Content-Type: multipart/mixed; boundary=abc123
   ...

   --abc123
   Content-Type: application/atom+xml
   ...

   <?xml ... ?>
   <entry>...</entry>
 
   --abc123
   Content-Type: application/atomcontrol+xml
   ...
 
   <?xml ...?>
   <control>...</control>

Now, the point of all this is that control data such as whether or not 
to enable comments within an entry really does not belong within the 
metadata of an Atom entry.  Further more, defining control data as an 
extension element within an Atom entry does not provide us with any 
mechanism for applying control data to non-Atom resources (e.g. a 
collection of PNG's).  The mechanism proposed above -- while adding a 
degree of complexity -- allows us to provide a mechanism for applying 
control data in a resource-type-independent manner.

5. So what about controlling whether a resource is a draft or not?  That 
would be handled by putting draft entries in a Draft's Collection and 
published entries in a Published Collection (sorry, I cannot recall 
exactly who brought up this possibility a couple of weeks ago).

Thoughts? Gripes? Praises? Better ideas?

- James