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] 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


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:


From:

Florian Müller <fmueller@opentext.com>

To:

Gregory Melahn/Raleigh/IBM@IBMUS, Derek W Carr/Watson/IBM@IBMUS

Cc:

<cmis-browser@lists.oasis-open.org>

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: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


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]