On May 18, 2009, at 11:55 AM, Peter Keane wrote:
<snip> Of the choices Nikunj offered in his post, I prefer #3:3. Use an extension element in app:collection to identify CMIS requirementsIt 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
An extension element does indeed offer clients a way to discover server's behavior/expectations. However, a rudimentary AtomPub client can't do anything with the extension elements since it does not understand them.
From the discussion so far, it seems we are looking at two different but related problems:
1. How does the server advertise its alternative behavior, which does not preclude standard Atom behavior?
2. How does the server preclude certain standard expectations?1 is clearly non-mandatory and hence extension elements/attributes make sense depending on complexity of the additional information.
2 can be considered mandatory and hence some kind of must-understand mechanism is required. ASAICT, the app:accept's content is the only must-understand mechanism. Realize that 2 is there for a server to forewarn clients that they may be unable to post unless they can prepare content in a certain way. It feels like a new Media type parameter might do the job better than anything else.
Nikunj Mehta http://o-micron.blogspot.com