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

[Joe Gregorio <joe.gregorio@xxxxxxxxx>]

On 7/12/05, James M Snell <jasnell@xxxxxxxxx> 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.  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>

Here is an alternative suggestion, consider this entry,
which could be POSTed to an entry collection to create a 
new collection member:

     <entry xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-09";>
       <title>Atom-Powered Robots Run Amok</title>
       <updated>2003-12-13T18:30:02Z</updated>
       <summary>Some text.</summary>
     </entry>

This has a mime-type of application/atom+xml.
Control information could be added to it ala PacePubControl:

<entry xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-09";>
    <title>Atom-Powered Robots Run Amok</title>
    <updated>2003-12-13T18:30:02Z</updated>
    <summary>Some text.</summary>
    <control xmlns="http://example.net/appns/";>
      <draft>no</draft>
    </control>
</entry>

Note that this too has a mime-type of application/atom+xml
and can also be POSTed to an entry collection. Now we 
can create an entry, or create an entry with control information.
The only step left is editing the control information in an efficient
manner. My suggestion is to use a parameter on the mime-type and
content-negotiation to do that efficiently. That is, consider this
entry:

<entry xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-09";>
    <control xmlns="http://example.net/appns/";>
      <draft>no</draft>
    </control>
</entry>

Note that it only has the control information. We could give this document
a mime-type of "application/atom+xml;form=control". 

When you want to edit an entry, but only affect the control information
you would do a GET on the entry URI and send an Accept: header
of: 

   Accept: application/atom+xml;form=control, application/atom+xml

If the server is capable, it will return an entry that only contains the control
information, if not, then the full entry with control information will
be returned.

To update the control information, just PUT the updated document
with a content-type of application/atom+xml;form=control.

The same cycle of GET and PUT of "application/atom+xml;form=control"
can also be used on the collection resource to get/set defaults for the
collection.

Advantages:

1. Let's control information be sent with an entry on creation.
2. Allows for efficient updating of control information.
3. While you can use this technique on the creation of non-entry
    collection members, it can be used afterwards to edit the
    control information on non-entry collection members.

Disadvantages:

1. Uses content-negotiation.

Caveats:

1. I'm not wedded to the name 'form=control'. Other suggestions for better 
   parameter names and values are welcome.
2. I'm not tied to the idea of using GET/PUT on the collection resource
   to get/set defaults. It does map nicely, but I haven't thought out all the 
   consequences.

   Thanks,
   -joe

-- 
Joe Gregorio        http://bitworking.org