[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dam-cmis-profile-discuss] RE: Key Objectives For CMIS/DAM
Let me try to explain the CMIS 1.1 specification in a few sentences. The CMIS specification is divided into two parts. The first part describes the domain model (chapter 2) and the second part the bindings (chapters 3, 4, and 5). The domain model defines the six base types (document, folder, relationship, policy, item, and secondary), their metadata and their behavior (section 2.1). It also describes all CMIS operations (50+) (section 2.2). The domain model does not say how a client and a server communicate, though. The CMIS bindings chapters define how the domain model is mapped to the bytes on the wire. CMIS 1.1 defines three bindings: - The Web Services binding, based on SOAP (chapter 3) - The AtomPub binding, based on the Atom specification (chapter 4) - The Browser binding, based on JSON and form data for JavaScript applications in a web browsers (chapter 5) The bindings are equivalent and a client can choose the binding that works best in its environment. (There are only a few minor things you can't do with the AtomPub binding.) There are client libraries for many programming languages today that make the bindings (almost) transparent to a developer. A developer uses the API of the client library and eventually only needs to learn the domain model. The domain model defines a set of mandatory data structures and operations and several optional capabilities. A client can ask for the so-called "repository info" to determine which capabilities the server provides. The repository info has an extension point that would allow exposing profile information. For example, a DAM server could provide information about the DAM profile it supports and DAM specific capabilities. A DAM client would be able to determine if the server supports the feature set it needs. A CMIS server is not allowed to expose another (seventh) base type, but it can provide a hierarchy of types derived from the six CMIS base types. These types can add more properties and may have a different behavior than the parent type. For example, a DAM profile could define that a server must provide a type "dam:asset" that is derived from "cmis:document" (section 2.1.4). It would inherit the properties of "cmis:document" and add new DAM specific properties. The profile could also define that all objects that carry content must be of the type "dam:asset" or a type derived from that. A pure "cmis:document" object wouldn't exist in such a repository. The repository would still be CMIS compliant and generic CMIS clients could work with it. I don't think there is anything to simplify if you start with the mandatory CMIS capabilities and build the DAM features on top. Also the Browser binding is a very simple and lean wire protocol. Find a few examples here: [1] I hope that helps, Florian [1] http://docs.oasis-open.org/cmis/CMIS/v1.1/os/examples/browser/ On 01.11.13 10:31, "Ralph Windsor" <ralph@daydream.co.uk> wrote: >On point (1) of my message from last week, it seems to me that the >cornerstone of any simplified variant of the CMIS protocol for DAM is a >definition of the Objects to be stored (which are probably the assets in a >typical DAM system in the vast majority of cases). This should describe >the >core essential object properties which any compliant DAM systems need to >be >able to generate to allow more fully CMIS compliant tools to interpret >them. > >I lack a full grasp of the CMIS protocol, is anyone on the list able to >explain, in basic terms, how this works in CMIS and also cite any relevant >sections from the CMIS spec? > >We'll almost certainly need to extend this with compatibility mappings >between other protocols, but they can all come in later. Right now, it's >the real 'need to know' stuff we should be interested in. > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: >dam-cmis-profile-discuss-unsubscribe@lists.oasis-open.org >For additional commands, e-mail: >dam-cmis-profile-discuss-help@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]