Re: [cmis-comment] Comments on CMIS link relations

[Al Brown <albertcbrown@us.ibm.com>]

Thanks.

How would you suggest modelling the two links you mentioned:
- repository since in CMIS that maps to a workspace? The service link would take the client back the app service doc which may have more than one workspace. Would you prefer a) leveraging service and indicating that the app service returned should only have the relevant workspace included? b) leverage another yet to be named link relation (such as repository, library) to specify the app service workspace?
- since up is defined for a single hierarchy, do you prefer a) including a link of relation up for each parent b) using up to point to the feed of parents c) using a new link relation (e.g., parents) for that? method a has server performance implications since the parents has to be expanded and the client may not want that information at the time.

>I'm not sure. Does the document describe the specific semantics that  
>are allowed (potentially in an extensible way), or is it more focused  
>on conveying permissions?
Well, the link relation that would be registered would represent the concept and is not tied to a media type.  The media type for cmis' use case, is naturally cmis-specific.  It currently includes the actions the current user context can perform on the resource from an application perspective (delete, view, update, file into a folder, etc).

-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@us.ibm.com
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.

Mark Nottingham ---05/05/2009 08:58:41 PM---Hi Al,

From:	Mark Nottingham <mnot@mnot.net>
To:	Al Brown/Costa Mesa/IBM@IBMUS
Cc:	Atom-Syntax Syntax <atom-syntax@imc.org>, cmis-comment@lists.oasis-open.org, cmis@lists.oasis-open.org
Date:	05/05/2009 08:58 PM
Subject:	Re: [cmis-comment] Comments on CMIS link relations

---

Hi Al,

Responses inline.

On 06/05/2009, at 1:09 AM, Al Brown wrote:

> Mark,
>
> Thanks for taking the time for reviewing. You raise some interesting  
> points. I'd like to address them individually:
>
> 1. The spec has a section on IANA registration that defines the link  
> relations and general concept they represent. The spec then uses  
> those link relations and binds them (for the CMIS specification) to  
> specific media types. The links to be registered are not specific to  
> a media type but rather used to model concepts not yet in the link  
> draft you specified.
>
Ah, good.

> 2. Both up and service are not defined in that draft your provided  
> so I am not sure I understand them completely. As long as up is  
> defined to include the up 'document' in 1 hierarchy and if more than  
> 1 hierarchy then a resource describing the collection of up  
> documents then that works. The 1..n aspect is important.  Also, in  
> CMIS, repository maps to a workspace in a service a document, so  
> somehow that association needs to be kept.
>
Sorry about that; both were missed in my last draft, and will be in  
the next one. They're already in the registry;
   http://www.iana.org/assignments/link-relations/link-relations.xhtml


> 3. Agreed. For those that are specific, either URI format or a  
> general purpose link relation that fits will be chosen. On the two  
> you mentioned, we have an issue to remove stream. On allowable  
> actions, it is used to represent a document that describes the  
> actions that can be taken on resource. That concept does not seem to  
> be modeled yet. Would 'actions' be better term for this?
>
I'm not sure. Does the document describe the specific semantics that  
are allowed (potentially in an extensible way), or is it more focused  
on conveying permissions?

Cheers,


--
Mark Nottingham     http://www.mnot.net/


-- 
This publicly archived list offers a means to provide input to the
OASIS Content Management Interoperability Services (CMIS) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: cmis-comment-subscribe@lists.oasis-open.org
Unsubscribe: cmis-comment-unsubscribe@lists.oasis-open.org
List help: cmis-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/cmis-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis