[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: app:accept and Atom entry MIME type
To summarize where I think this discussion has gone:
1. CMIS should add something like profile="" or cmisprofile=1.0 to the atom entry media type.
This allows CMIS providers to advertise support for atom entry and atom entry + cmis separately. As such the server can advertise appropriately.
2. app:accept and POST
This includes signaling that allows the server to respond to a request if it is in the wrong format, a precondition not satisfied or internal error. This is required anyway if the client for some reason does not follow the guidance provided in the atom media types. The app:accept is an optimization of the request/response pattern.
412 Precondition failed (httpbis) (type not specified, missing elements, etc)
415 Unsupported media type (httpbis) (if the request is in a format other than what is allowed; e.g., missing cmis extensions)
500 Server error (other internal issue)
Best,
-Al
Al Brown
Emerging Standards and Industry Frameworks
CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home
Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home
Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@xxxxxxxxxx
CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation.
Nikunj Mehta ---05/18/2009 10:53:31 PM---On May 18, 2009, at 7:19 PM, Roy T. Fielding wrote:

From: | 
Nikunj Mehta <nikunj.mehta@xxxxxxxxxx> |

To: | 
"Roy T. Fielding" <fielding@xxxxxxxx> |

Cc: | 
Al Brown/Costa Mesa/IBM@IBMUS, Peter Keane <pkeane@xxxxxxxxxxxxxxx>, atom-protocol Protocol <atom-protocol@xxxxxxx>, pjkeane@xxxxxxxxx, Ryan McVeigh <ryan.mcveigh@xxxxxxxxxx> |

Date: | 
05/18/2009 10:53 PM |

Subject: | 
Re: app:accept and Atom entry MIME type |
On May 18, 2009, at 7:19 PM, Roy T. Fielding wrote:
>
> On May 18, 2009, at 5:21 PM, Nikunj Mehta wrote:
>> 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].
>
> Why would the request fail?
A POST request to a collection could fail because (besides the reasons
identified in AtomPub RFC 5023):
1. a non-(atom/cmis)-entry document is posted to a folder URI
2. among other unspecified rules for what makes a valid atom/cmis
entry, in the eyes of a given CMIS server, is the presence of a
particular extended entry metadata.
>
>
>>>> 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.
>
> Yes, I know. Don't use the app:accept signaling. AFAICT, there is
> no need to do so. Just send the AtomPub/HTTP message to the server.
Wait a second. There's a reason we have app:accept. Are you indicating
that they are irrelevant? You can always check whether a certain
method can be used on a certain resource. However, the app:accept
metadata tells you in advance what is likely to happen so you can
decide whether or not to attempt an operation. Not every feed is an
AtomPub collection, even if it is coming from an AtomPub server.
>
>
>>>> I am not sure leveraging categories as the signaling mechanism
>>>> fits.
>>>
>>> I agree. Atom categories are analogous to folders in CMIS.
>>> <snip>