[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) uploaded
Florian, This approach works fine for me. Thanks, --------------------------------------- Derek Carr (919) 254-8592 (t/l 444) --------------------------------------- From: Gregory Melahn/Raleigh/IBM@IBMUS To: Florian Müller <fmueller@opentext.com> Cc: cmis-browser@lists.oasis-open.org, Derek W Carr/Watson/IBM@IBMUS Date: 08/09/2010 10:29 AM Subject: RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) uploaded Florian, I like the idea. It would result in less duplication and it would make it simpler for clients to cache type info. The downside would be that the client would need the extra step of looking up the relevant type info. Gregory Melahn STSM IBM Lotus Quickr - http://www.ibm.com/lotus/quickr melahn@us.ibm.com 919 254 0295 (Embedded image moved to file: pic06576.gif)Inactive hide details for Florian Müller ---08/09/2010 09:54:10 AM---Here is another idea:Florian Müller ---08/09/2010 09:54:10 AM---Here is another idea: (Embedded (Embedded image moved to file: pic32144.gif) image Florian Müller <fmueller@opentext.com> moved to file: pic12944. gif) From: (Embedded (Embedded image moved to file: pic08960.gif) image Gregory Melahn/Raleigh/IBM@IBMUS, Derek W Carr/Watson/IBM@IBMUS moved to file: pic11230. gif) To: (Embedded (Embedded image moved to file: pic29372.gif) image <cmis-browser@lists.oasis-open.org> moved to file: pic12687. gif) Cc: (Embedded (Embedded image moved to file: pic29697.gif) image 08/09/2010 09:54 AM moved to file: pic15306. gif) Date: (Embedded (Embedded image moved to file: pic05339.gif) image RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - moved to v0.1 (cmis-spec-v0.1-browserbinding.doc) uploaded file: pic19314. gif) Subject: Here is another idea: Instead of an includePropertyAttributes parameter we could introduce an includeTypeDefinitions parameter. If includeTypeDefinitions=true the type and property definitions of all returned objects are attached to the response. A getChildren call often returns a set of objects of the same type. There is no need to the repeat the data type, display name and query name over and over again. It would also would include the query name of the type. With that you have all you need to compile a query statement. - Florian From: Gregory Melahn [mailto:melahn@us.ibm.com] Sent: Sonntag, 8. August 2010 23:47 To: Derek W Carr Cc: cmis-browser@lists.oasis-open.org; Jens Hübel; Ryan Mcveigh Subject: RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) uploaded Derek, I can certainly see how a client would find the availability of certain property attributes in the response to be useful (for example it would be handy in the Firefox CMIS plugin!). But I can also see how a client would rather rely on cached information and not need to pay the cost of 5-10x times the size of the responses for things that don't change very much, So how about a request parameter, e.g. includePropertyAttributes for a client to signal the server to be more verbose, i.e. to return more information than just the property id and value. Following your example, the property bag would turn into a JSON array, each element of which is a JSON object and , for each property in the object, a key/value pair for the property id, a key/value pair for the property value and then (if verbose) a key/value pair for each property attribute that he server wants to answer if includePropertyAttributes=verbose { "properties": [ // for each property { "propertyDefinitionId":"cmis:objectId", "displayName":"Id", "value":["snx:file!1234"], "queryName":"cmis:name", "propertyType":"string" } ], } else { "properties": [ // for each property { "propertyDefinitionId":"cmis:objectId", "value":["snx:file!1234"] } ], } Gregory Melahn STSM IBM Lotus Quickr - http://www.ibm.com/lotus/quickr melahn@us.ibm.com 919 254 0295 (Embedded image moved to file: pic01050.gif)Inactive hide details for Derek W Carr---07/29/2010 09:22:56 AM---I have some concerns on the current JSON serialization formatDerek W Carr---07/29/2010 09:22:56 AM---I have some concerns on the current JSON serialization format proposed for From: Derek W Carr/Watson/IBM@IBMUS To: Jens Hübel <jhuebel@opentext.com> Cc: cmis-browser@lists.oasis-open.org, "Ryan Mcveigh" <ryan.mcveigh@oracle.com> Date: 07/29/2010 09:22 AM Subject: RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) uploaded I have some concerns on the current JSON serialization format proposed for a CMIS object as it lacks some information that we have found to be useful when building generic CMIS client explorers. The Atom representation of a property returned is like the following: <cmis:propertyString propertyDefinitionId="custom:classificationCode" displayName="Classification Code" queryName="custom:classCode"> <cmis:value>Confidential</cmis:value> </cmis:propertyString> Generic clients are able to do a lot of simple, but powerful things based on the above information without needing to make additional server requests which would be necessary in the current JSON proposal. They can deduce the type information about the property (i.e. string, integer, datetime, id, etc.) which is useful in knowing what type of field to present when rendering basic summary information. The server has the ability to return a localized label for each property value in addition to the propertyDefinitionId. This allows the client when rendering a list of results in a tabular format to provide an end-user friendly label and give a better user experience. Finally, they are able to know the queryName for a field which is needed to perform a subsequent ORDER BY or query. The challenge in the current proposal is that if a given CMIS service response contains a mixed object type response (i.e. CMIS Document, Folder, SubType A, SubType B, etc.), in order to build the same user experience that is possible today in the AtomPub binding due to the above information provided, a client would either a) have to cache the object type hierarchy locally, or b) make [n] type definition requests to the server for each type in the response. I think its important we preserve the ability of a client to inspect a response and have the above information (i.e. primitive type, display name, query name). Something like the following would be really useful for our clients, and would enable vendors to extend the response with some additional keys associated with a property value instance that may serve future benefit for that repository (i.e. mark a property as hidden, etc.). { "properties": [ // for each property on type { "displayName":"Id", "value":["snx:file!1234"], "propertyDefinitionId":"cmis:objectId", "queryName":"cmis:name", "propertyType":"string" } ], } Thoughts? --------------------------------------- Derek Carr (919) 254-8592 (t/l 444) --------------------------------------- From: Jens Hübel <jhuebel@opentext.com> To: "Ryan Mcveigh" <ryan.mcveigh@oracle.com>, <cmis-browser@lists.oasis-open.org> Date: 07/29/2010 02:49 AM Subject: RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) uploaded I agree to Ryan's comments about saving space/compression. We should focus on a simple and consistent schema and not trying to squeeze everything into the minimal number of bytes. If we have such requirements then a binary protocol would be the right choice. Instead the principle should be to follow the domain model where possible and to keep the JSON parsing and generator code compact and simple. I also would like to better understand why we use relative URI paths (section 1.2.3). In the AtomPub protocol we did not do this. What is the benefit? Is it again saving space? We then need code to preprocess every link before we can submit a request to it. Do we want this? This mechanism also implies the restriction that all targets are beneath a common root URL. This is not the case for all repositories. It may happen that the content for example is located on a different server (take an Amazon S3 like store as a simple example). Another use case is a virtual repository acting as a federator to other repositories. Jens -----Original Message----- From: Ryan Mcveigh [mailto:ryan.mcveigh@oracle.com] Sent: Mittwoch, 28. Juli 2010 23:39 To: cmis-browser@lists.oasis-open.org Subject: RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) uploaded Hi folks, I've added my own comments directly to the document and used change tracking to do so. I uploaded the updated document here: http://www.oasis-open.org/apps/org/workgroup/cmis-browser/download.php/38820/cmis-spec-v0.1-browserbinding%20-%20rm.doc I'd appreciate your feedback. Thanks, -Ryan -----Original Message----- From: melahn@us.ibm.com [mailto:melahn@us.ibm.com] Sent: Tuesday, July 27, 2010 10:02 AM To: cmis-browser@lists.oasis-open.org Subject: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) uploaded changes reflecting Florian's comments. Added responseInfo and clarification on paging. Fixed a few typos. -- Mr. Gregory Melahn The document revision named CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) has been submitted by Mr. Gregory Melahn to the CMIS Browser Binding SC document repository. This document is revision #1 of cmis-spec-v0.1-browserbinding.doc. Document Description: This is the first iteration of the proposal, including some statements about the approach, and a few examples. It is still a skeleton document. View Document Details: http://www.oasis-open.org/committees/document.php?document_id=38791 Download Document: http://www.oasis-open.org/committees/download.php/38791/cmis-spec-v0.1-browserbinding.doc Revision: This document is revision #1 of cmis-spec-v0.1-browserbinding.doc. The document details page referenced above will show the complete revision history. PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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]