Re: app:accept and Atom entry MIME type

[Peter Keane <pkeane@xxxxxxxxxxxxxxx>]

On Mon, May 18, 2009 at 3:36 PM, Nikunj Mehta <nikunj.mehta@xxxxxxxxxx> wrote:
> On May 18, 2009, at 11:26 AM, Hadrien Gardeur wrote:
>
> 2009/5/18 Peter Keane <pkeane@xxxxxxxxxxxxxxx>
>>
>> <snip>
>> ---------------
>>
>> 8.3.6 The "app:categories" Element
>>
>> <snip>
>
> Categories can be useful but in the case specified by Nikunj in the
> hierarchy I-D, we really need another mechanism to describe the behavior
> (master/children).
> For example in my case (Feedbooks), categories are useful to describe the
> nature of each entry (part/chapter/section), but the rel values/h:role as
> described in the hierarchy I-D fulfill a different purpose (describe the
> behavior) and I don't want to mix both of them together.
>
> The app:accept attribute or for that matter any other app:collection
> extension element works well when the server does something over and above
> the expectations of a rudimentary AtomPub server. In that sense, the h:role
> attribute works for hierarchy type of operations.
> For the server to signal that it will not accept a certain kind of Atom
> entry, the best approach would be a custom Atom Format parameter (see §12 of
> RFC 5023). The good thing about this approach is that:
> 1. There is no need for a new AtomPub or Atom standard
> 2. The intent is communicated as a must-understand requirement

Hi Nikunj-

Those are definitely compelling points.  I have a few questions:  what
parameter would you use (since 'type' is taken)?  Also, what is
expected of the atom:entry posted?  Anything?  Seems like what you are
communicating is: "if you post and atom:entry w/ this parameter in the
mime type (e.g., role=master), the server will insert an
app:collection element in the entry or a link@rel=service in the
entry." Is that more or less correct?

--peter