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

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:

  displayName="Classification Code"

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",

Derek Carr
(919) 254-8592 (t/l 444)

From:	Jens Hübel <jhuebel@opentext.com>
To:	"Ryan Mcveigh" <ryan.mcveigh@oracle.com>,
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.


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

I'd appreciate your feedback.  Thanks,


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

Download Document:

This document is revision #1 of cmis-spec-v0.1-browserbinding.doc.  The
document details page referenced above will show the complete revision

PLEASE NOTE:  If the above links do not work for you, your email
may be breaking the link into two pieces.  You may be able to copy and
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:

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