[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Comments on CMIS link relations
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:mnot@mnot.net] Sent: Thursday, April 30, 2009 9:58 PM To: cmis-comment@lists.oasis-open.org 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: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]