Subject: Re: Comments on CMIS link relations

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 May 2009 13:54:37 +1000

Hi David,

The best place for questions that are specific to AtomPub (as opposed  
to Atom, including the link relations) is the atom-protocol list;
   http://www.imc.org/atom-protocol/

Although there's a lot of overlap between it and atom-syntax, it  
probably wouldn't hurt to ping them and ask for feedback there too.

Cheers,

On 05/05/2009, at 5:26 AM, [email-masked] wrote:

> Hi, Mark,
>
> Thank you for your helpful comments. The CMIS TC does intend to seek
> AtomPub link relation registration in the near future. Please keep us
> informed about the new registration process.
>
> Separately, the TC can use some assistance in refining the CMIS  
> AtomPub
> binding. In the upcoming weeks, members of the CMIS TC may seek help
> from the AtomPub community on specific design questions. I hope you  
> and
> the AtomPub community can point us in the right direction.
> The CMIS draft spec is publicly accessible (as well as almost all  
> other
> TC working materials).
> http://www.oasis-open.org/committees/download.php/32171
> Any comment will be much appreciated.
>
> Regards,
> David
>
> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Thursday, April 30, 2009 9:58 PM
> To: [email-masked]
> Cc: Atom-Syntax Syntax
> 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: [email-masked]
> Unsubscribe: [email-masked]
> List help: [email-masked]
> 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
>
>

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 May 2009 13:58:32 +1000

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,