Re: PaceControlResource, PacePubControl, PacePubStatusResource... seeking consensus

["Thomas Broyer" <t.broyer@xxxxxxxxxxx>]

James M Snell wrote:
>
> 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.

...and they all try to solve distinct issues in one shot...

> 1. Define a new Control document.  Media type is
> application/atomcontrol+xml. [...]
>
> 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

Why not... I have to think a bit more about it but 1. and 3. seem OK for
me... I still don't know about 2.

> ....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. [...]

Hmm, not sure about that one...

Would it really be a problem to make two separate requests?
 1. POST the Member Resource to the Collection Resource
 2. POST/PUT the Control Document to the Member Resource created above


> 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).

Could we please divide up the debate between *how* to apply "control
properties" and *which* ones should be in the protocol core?

In [1] I tried to define 5 topics, where "resource state" can be any
"control property", and "entry property" is something like categories.
These topics should imo really be discussed separately...

[1] http://www.imc.org/atom-protocol/mail-archive/msg00856.html

-- 
Thomas Broyer