Re: app:accept and Atom entry MIME type

[Peter Keane <pkeane@xxxxxxxxxxxxxxx>]

On Mon, May 18, 2009 at 1:26 PM, Hadrien Gardeur
<hadrien.gardeur@xxxxxxxxxxxxx> wrote:
> 2009/5/18 Peter Keane <pkeane@xxxxxxxxxxxxxxx>
>>
>> Here is an excerpt from RFC 5023
>>
>> This is the basis of my suggestion of using atom:category to specify
>> that an atom:entry is of a particular "kind" or exhibits particular
>> properties.  And filtering on such is already built into the AtomPub
>> spec:
>>
>> ---------------
>>
>> 8.3.6 The "app:categories" Element
>>
>> The "app:categories" element provides a list of the categories that
>> can be applied to the members of a Collection. See Section 7.2.1 for
>> the detailed definition of app:categories.
>>
>> The server MAY reject attempts to create or store members whose
>> categories are not present in its categories list. A Collection that
>> indicates the category set is open SHOULD NOT reject otherwise
>> acceptable members whose categories are not in its categories list.
>> The absence of an app:categories element means that the category
>> handling of the Collection is unspecified. A "fixed" category list
>> that contains zero categories indicates the Collection does not accept
>> category data.
>
> 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.

Hi Hadrien-

I certainly understand that -- using atom:category fro the sort of
functionality I suggested would, I think, require some standardization
of category@scheme and I know some folks see that as a hack.  Perhaps
for lightweight, ad-hoc extension?  Anyway...

Of the choices Nikunj offered in his post, I prefer #3:

3. Use an extension element in app:collection to identify CMIS requirements

It seems that a server implementation might very well want to offer
different collections for different functionality.  In fact, what
constitutes a workspace and what constitutes a collection are left
wide open in the spec. They both offer an organizing mechanism that I
find preferable to custom attributes on app:accept or messing w/ MIME
type parameters (I do prefer new attribute on app:accept than MIME
type param).

I just noticed: The Atom Multipart ID
(http://code.google.com/p/atompub-mulitpart-spec/source/browse/trunk/draft-gregorio-atompub-multipart-04.txt)
does propose an extension attribute on app:accept.  Not sure if that's
an indication that it's a good way to do things or a sign that we
ought to be careful of proliferation :-).

--peter