[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cmis-browser] URL-Patterns and JSON-Schemas
HI all,
as discussed in our last BB call I have updated the Excel sheet.
For those who have missed the call: The purpose of the Excel sheet is to collect the important design aspects on a single page. It defines the URLs, http methods, request and response types and maps those to the CMIS domain model. While the first version posted was a more general approach I tried to align this now better to the existing URL patterns and Orderly schema definitions.
Please be aware that the attached version is nothing but a working copy. Likely I won’t find much time to improve this before our next call. So it might be better to give you some time to take a look at the current state.
Given the current proposals (cmis-schema-v0.1-browserbinding.json and CMIS-677) I ran into a bunch of issues that need more discussion. Perhaps I missed something, but following the existing URL pattern with the id as URL parameter for me it is unclear at the moment:
Orderly Schema:
----------------------
Missing schema elements:
repositoryInfoList
typeHierarchy
folderHierarchy
objectList (response for getCheckedOutDocs)
query and queryResponse(?) alias names, etc.
URL Patterns:
-----------------
A couple of URLs need to be defined on root level:
query
checked-out
content-changes
The query parameter object-id is not sufficient. Other id parameters we need are:
repositoryId
typeId
versionId(?)
We also could use one parameter being more general, like “id”
More action parameters needed:
checkout
move
deleteTree (could also be a URL parameter recursive=true)
updateContent
addToFolder, removeFromFolder
More selectors needed:
parent(?)
parents
folders
renditions
relationships
properties
versions
acls
policies
allowableActions
I also believe that the current action mechanism is insufficient for content, ACLS and policies
The action-param works well for aspects that are read-only (like allowableActions, renditions). But other aspects of a document allow further actions to be applied on them: content, properties, ACL, policy.
If I have a URL to an object and action=update… how can I distinguish between updateProperties and updateContent? I see several possibilities:
separate URL for object and content
change the rule: Instead of a "selector" parameter an "action" parameter MUST be passed. (solution: allow both)
distinguish the requested action only from the JSON in the request body: If this contains properties then properties are updated If this contains content then content is updated.
Have a separate actions “updateContent”, “addAcl”, ….
Did we already have an answer for this?
I wondered what the best way is to reference the URL for each service method and came up with a grammar like approach. Not sure if we want to keep this…
Feel free to update or correct the sheet where necessary…
Jens
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]