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 protected] 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 protected]]
Sent: Thursday, April 30, 2009 9:58 PM
To: [email protected]
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 protected]
Unsubscribe: [email protected]
List help: [email protected]
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/
