On May 18, 2009, at 5:06 PM, Roy T. Fielding wrote:
On May 18, 2009, at 11:26 AM, Al Brown wrote:I believe it is more about extensions to atom. How should a group that builds on top of atom using atom extensibility advertise that it can accept generic atom and/or atom+it's extensions in addition to other potential media types?Why does it need to? Why not just let the client try it.
Because the client would have no clue why the request just failed. In effect, it would not "understand" the response even though its intent was clear to the server [1]. This is at the heart of your interoperability argument on atom-protocol from a few years ago [2].
In app, this is all done by media types. Both vanilla atom + atom with extensions have the same media type which cause problems.Won't the extensions be ignored by a server that doesn't want them?
The media type parameter is for use primarily in the app:accept signaling. If a server doesn't require it or doesn't understand it, it can safely ignore it.
I am not sure leveraging categories as the signaling mechanism fits.I agree. Atom categories are analogous to folders in CMIS. It would make more sense to replace most of the CMIS extensions by using the Atom category mechanism to hold its filing relations.
Day Software is a participant in the CMIS TC and it would greatly help if you could bring such thinking to the TC. It would be one less NIH- borne concept to deal with.
....Roy
[1] http://o-micron.blogspot.com/2009/05/cmis-xiii-interoperability-in-atompub.html [2] http://www.mailinglistarchive.com/atom-protocol@xxxxxxx/msg08616.html