[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: app:accept and Atom entry MIME type
>May be its just me, but it would help to be more precise about what you mean by "those" media types.
The media types specified by app:accept.
#2 is where I am agreeing with Roy that there is no need for app:accept except optimization. HTTP is sufficient to handle the scenarios.
I am suggesting that CMIS does #1 (extend atom entry mime type to include CMIS profile) so that servers can advertise appropriately. Even though #2 is not required since CMIS leverages HTTP, clearly state the result codes in the POST section.
-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/19/2009 09:41:08 AM---On May 19, 2009, at 9:09 AM, Al Brown wrote: >Why would the request fail?
From: |
Nikunj Mehta <nikunj.mehta@xxxxxxxxxx> |
To: |
Al Brown/Costa Mesa/IBM@IBMUS |
Cc: |
"Roy T. Fielding" <fielding@xxxxxxxx>, atom-protocol Protocol <atom-protocol@xxxxxxx>, owner-atom-protocol@xxxxxxxxxxxx, pjkeane@xxxxxxxxx, Peter Keane <pkeane@xxxxxxxxxxxxxxx>, Ryan McVeigh <ryan.mcveigh@xxxxxxxxxx> |
Date: |
05/19/2009 09:41 AM |
Subject: |
Re: app:accept and Atom entry MIME type |
On May 19, 2009, at 9:09 AM, Al Brown wrote:
>Why would the request fail?
If the server has no intent to support non-cmis documents, then it would not advertise it supports those media types. Adding profile="" or cmisprofile=1.0 to the atom media type solves the signaling issue. If the repository does advertise it supports those media types, then it is a configuration issue of the underlying repository due to a) no default type available b) default type requires information not specified or c) some other resource not available (network between tiers, database, storage, etc)
May be its just me, but it would help to be more precise about what you mean by "those" media types.
>AFAICT, there is
>no need to do so. Just send the AtomPub/HTTP message to the server.
The server could return the following to handle the scenarios:
412 Precondition failed (httpbis[1]) (a or b)
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 (most likely c)
Per Roy's point, including app:collection and thus app:accept inside is nice (extra information so the client can be aware before the request), however, I think the signaling provided by http[bis] is sufficient and the client can just send the message to the server.
Not clear what you are suggesting here -
1. to use the app:accept with a new CMIS specific media type parameter
2. Not using app:accept any differently and rejecting requests with one of the errors you list above. Note that if you return 415, it is essentially saying that the server does not like to process entry POST requests at all, not that you need extra precision in producing a CMIS entry.
It is also possible to use 1 in conjunction with 2.
-Al
[1] http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p2-semantics-06.txt
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.
<graycol.gif>"Roy T. Fielding" ---05/18/2009 07:34:31 PM---On May 18, 2009, at 5:21 PM, Nikunj Mehta 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?
>>> 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.
>>> 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.
David Nüscheler is more than capable of representing Day in the CMIS TC.
I have my hands full with the layers underneath.
....Roy
Nikunj R Mehta | Consulting Member of Technical Staff | Phone: +1 650 506 0679 | Blog: http://o-micron.blogspot.com
Oracle Advanced Development Projects
500 Oracle Parkway #4OP662 | Redwood Shores, CA 94065
Oracle is committed to developing practices and products that help protect the environment