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

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

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.

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.

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?

4. Agreed. The IANA registration should define general concepts. Your (and the rest of the atom-syntax) help in making sure the text is phrased in a generic way would be appreciated.

5. Julian has sent around this document before.

Looking forward to the continued discussion on this, -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 ---04/30/2009 10:01:20 PM---[ CC:ing atom-syntax FYI ]

From:	Mark Nottingham <mnot@mnot.net>
To:	cmis-comment@lists.oasis-open.org
Cc:	Atom-Syntax Syntax <atom-syntax@imc.org>
Date:	04/30/2009 10:01 PM
Subject:	[cmis-comment] Comments on CMIS link relations

---

[ CC:ing atom-syntax FYI ]

CMIS <http://www.oasis-open.org/committees/download.php/32171/Draft%2061.zip 
 > specifies a large number of new link relations for use in Atom. A  
few comments and questions follow:

1. Each one of the link relations specifies a type of document that it  
references (with "Mime/Type", although I note that the proper term is  
media type, and the values given are prose descriptions, not media  
types). Is the intent here to limit these relations to those types? If  
so, this is conflating the job of a link relation with a media type.  
Link relation types should not be specific to any single format.

2. Some of the proposed registrations seem to overlap with existing  
relation types (e.g., "parents" whereas "up" has already been  
registered; "repository" where "service" would probably do.).

3. Other proposed registrations seem to be very specific to your use  
case (e.g., "streams", "allowableactions"). These cases may be better  
served by using extension relations (i.e., URIs).

4. Of the remaining ones, it does seem like there are some useful  
things to register (e.g., "child", "latestversion"), but the language  
shouldn't be specific to your use case; they need to be generic.

5. In case you're not aware, there's a proposal circulating to revise  
the link relation registration process, as well as provide a framework  
for them; see <https://datatracker.ietf.org/drafts/draft-nottingham-http-link-header/ 
 >.

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