OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis-browser message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cmis-browser] URL-Patterns and JSON-Schemas


Thanks Jens,

I'm finding this very helpful.

-Ryan

On Tue, Nov 30, 2010 at 8:05 AM, Jens Hübel <jhuebel@opentext.com> wrote:

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]