Re: [cmis-browser] Binding Proposal Feedback

[Gregory Melahn <melahn@us.ibm.com>]

Hi Florian

Thank you for the comments. See <gtm>

Gregory Melahn
STSM
IBM Lotus Quickr - http://www.ibm.com/lotus/quickr
melahn@us.ibm.com
919 254 0295


Florian Müller ---07/26/2010 07:43:47 AM---Hi Gregory,

From:	Florian Müller <fmueller@opentext.com>
To:	<cmis-browser@lists.oasis-open.org>
Date:	07/26/2010 07:43 AM
Subject:	[cmis-browser] Binding Proposal Feedback

---

Hi Gregory,

Thanks for the first proposal document. I would like to start the discussion. Here are a few comments and suggestions.

- (1.2.2.1) datetime mapping: datetime values should be transmitted as numbers (milliseconds since 1970/01/01). A JavaScript Date object can be initialized with this value and there is no further parsing required.
<gtm>ok</gtm>

- (1.2.4) Paging: I'm not sure I understand this. Should cmis:pageinfo be an object beside, for example, a getChildren output? Or should it be within the getChildren output? If so, would it be on the same level as the children? Also, cmis:pageinfo should always be present. A repository might cut the result list even if maxItems is not present.
<gtm>I was proposing that the pageinfo object be an object beside the other output, .i.e. a sibling of the  getChildren output), though am open to other ideas.   On whether it must be included or not, I agree it should also say it must be present if the repository answers fewer than all the items if ,maxItems is not present</gtm>

- (1.2.8) return codes: We should define an optional? JSON structure that allows to send more meaningful information about the failure if the repository is able to. For example, an invalidArgument exception could return the name of the argument.
 <gtm>I agree it would be good to have an optional error info object as well</gtm>

- (1.3.1.1) getRepositories: I don't think we need a simple list.
<gtm>ok</gtm>

- (1.3.1.1.1) getRepositories inputs: We should have a repositoryId parameter here. See CMIS spec 3.6.2.1.
<gtm>that relates to the above question.  If we are combining the services then repository id is not a parm (similar to the service document in the REST binding where all the repository info is bundled)</gtm>

- (1.3.2.1.2) getChildren outputs: cmis:name might not be unique within a folder. We should use the object id here. Do we need a key at all? Won't be a simple array sufficient?   
<gtm>The array may be enough unless we expected a client to want to reference it by key because maybe the client was looking for a particular document or folder that it knew to expect in the output.  You are right that it must be unique though (I was actually thinking this would be path segment, not name)/gtm>



- Florian



- Florian

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php