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
919 254 0295
Florian Müller ---08/09/2010 09:54:10 AM---Here is another idea:
From:
Florian Müller <>
To:
Gregory Melahn/Raleigh/IBM@IBMUS, Derek W Carr/Watson/IBM@IBMUS
Cc:
<>
Date:
08/09/2010 09:54 AM
Subject:
RE: [cmis-browser] Groups - CMIS Browser Binding Proposal - v0.1 (cmis-spec-v0.1-browserbinding.doc) uploaded
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:]
Sent: Sonntag, 8. August 2010 23:47
To: Derek W Carr
Cc: ; 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
919 254 0295
Derek 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 <>
Cc:
, "Ryan Mcveigh" <>
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 <>
To: "Ryan Mcveigh" <>,
<>
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:]
Sent: Mittwoch, 28. Juli 2010 23:39
To:
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: [mailto:]
Sent: Tuesday, July 27, 2010 10:02 AM
To:
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
