|Here's an issue we came across in reviewing the CMIS spec and I wanted to draw the atom-protocol community's attention to it and solicit feedback.|
CMIS is a fairly sophisticated AtomPub extension. A CMIS server will advertise collections that are writable using the same mechanisms we all know and use, i.e., app:accept. Some CMIS servers, though, further restrict the atom:entry documents that they will successfully process for POST requests. Others may accept any valid Atom entry. I have blogged about the consequences of such diverse behavior [1, 2] and the basic problem is that a client would not know the nice kind from the restrictive kind of CMIS server.
The basic question is whether, for standard AtomPub clients that don't understand any CMIS extensions, there is benefit to receiving better app:accept advertisements. In other words, is there some additional information about app:accept that will help clients better determine whether a request is likely to be accepted by the server. I know there is no must-understand extension mechanism for app:collection, so I don't know what would be the best alternative:
1. Use a new MIME type parameter on app:accept for the Atom entry content type
2. Use a new attribute on app:accept
3. Use an extension element in app:collection to identify CMIS requirements
Why should you care?
Of course, there are many AtomPub servers out there that wouldn't accept any arbitrary valid atom:content but CMIS is a case that is quite close to blogging and that is being standardized (publicly, if I may say so). This is an opportunity for the atom-protocol community to weigh in on the consequence of how AtomPub advertisements are used in CMIS.
As a disclaimer, I am not a member of the CMIS TC, although Oracle is.