>Is the assumption that the server will assign the collection-local name?
That is the APP behavior - After POST, Content-Location header is returned with the location of the [new] resource [in that collection]. The server may specify the new location as a collection-local name. Or it may not. The FileNet prototype does not use collection-local names, but rather bases the URI off of the underlying object id.
>If we wanted to use COPY/MOVE, we'd need an extension (such as
>"Destination-Collection" instead of "Destination"). On the other hand,
>we could standardize the "Allow-Rename" header
>(<http://msdn.microsoft.com/en-us/library/aa142703(EXCHG.65).aspx>),
>which apparently is already supported in some Microsoft products.
I would prefer Destination-Collection. However, how do we advertise to clients that COPY/MOVE does not support Destination but Destination-Collection header? Also, how do we map removeObjectFromFolder?
We could either add a new header (e.g., removeFrom) or a new verb. However, I do not get a warm feeling from this approach so far. I think it would be cleaner to have new verbs or have those verbs clarified in an rfc for this use case first.
-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
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.
Julian Reschke ---04/15/2009 10:14:20 AM---Al Brown wrote:
From:
Julian Reschke <>
To:
Al Brown/Costa Mesa/IBM@IBMUS
Cc:
Date:
04/15/2009 10:14 AM
Subject:
[cmis] Re: Note on CMIS utilizing COPY and MOVE verbs
Al Brown wrote:
> Julian,
>
> I saw a post on the JSR list and it prodded to me to (re)read the
> appropriate rfcs. If you look at copy
> (http://tools.ietf.org/html/rfc2518#section-8.8) or move
> (http://tools.ietf.org/html/rfc2518#section-8.9), it is articulated to
> copy (or move) a resource from location a (uri1) to location b (uri2).
The relevant RFC nowadays is RFC 4918, but, yes, that is correct.
> These locations are fully specified to be where the object will live
> after the verb. They include the location under the folder, rather than
> uri2 being the uri to the folder. Am I understanding COPY and MOVE
> correctly in WebDAV?
>
> This is a discrepancy with the CMIS model.
>
> In CMIS, we have:
> - moveObject (object, folder)
> - addObjectToFolder(object, folder)
> - removeObjectFromFolder(object, folder)
>
> In WebDAV case COPY/MOVE would want uri2 to contain the location of the
> object in the folder: e.g. http://foo/folder1/newlocation where in CMIS
> it should be http://foo/folder1.
I keep forgetting that :-).
Is the assumption that the server will assign the collection-local name?
> In CMIS, there is not a notion of path, only folder containment. All
> URI's in the rest binding are basically repository-specific how they are
> generated. The most a client can do is specify the Slug ala app.
>
> If we would like to use COPY and MOVE, wouldn't we have to redefine COPY
> and MOVE for CMIS?
If there's no way for the client to "guess" the final URI (like "new
folder name / old local name" -- which I doubt), then yes, MOVE and COPY
wouldn't work as desired.
If we wanted to use COPY/MOVE, we'd need an extension (such as
"Destination-Collection" instead of "Destination"). On the other hand,
we could standardize the "Allow-Rename" header
(<http://msdn.microsoft.com/en-us/library/aa142703(EXCHG.65).aspx>),
which apparently is already supported in some Microsoft products.
BR, Julian
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
