1 / 12

Evolution of Content Management Interoperability Standards

Learn about CMIS version 0.5 design considerations, goals, and challenges such as interoperability, simplicity, object types, identity, content stream, query language, and versioning.

eara
Download Presentation

Evolution of Content Management Interoperability Standards

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. How did we get here? (CMIS v0.5) F2F, January 2009

  2. First, many thanks to allwho helped us get here • My fellow contributors from Alfresco, EMC, IBM, Microsoft, Open Text, Oracle, and SAP • All were • Constructive • Motivated to find a common ground Thank You!

  3. Version 0.5 certainly has room for improvement. Nevertheless, there were a number of considerations that led to the current design.

  4. The Interoperability Challenge for CMIS • Many enterprises already have a large amount of content accumulated in existing repositories. • Most can not afford to move their content to a new repository and re-implement their applications. • Existing investments should be leveraged/protected. • CMIS should provide interoperability for existing content as well as new content. • Interoperation with existing content is a big challenge. • A major objective for CMIS 1.0 is to find a common design that accommodates existing repositories. • A bootstrap to get CMIS off the ground

  5. Interoperability for Existing Repositories Make CMIS easily and naturally mappable to most repositories • Layer-able on top of a repository’s native interface without behavioral change to the repository server • Without implementing replacement “server logic” on top of a repository • It should utilize a repository’s corresponding capability

  6. Was Consumer interest neglected? • Interoperability for existing content is actually for Consumer’s benefit. • Broader Consumer interests are covered by use cases. • The difference is that Consumer interests are open-ended, and we need to be selective for 1.0. • Will CMIS be forever limited by legacy technology, and by the “least capable repository”? • No. Once the standard is widely adopted, its direction and scope will be driven by market dynamics and technology trend.Repository vendors will have to keep up.

  7. Another Goal for 1.0: Keep it simple! • Successful standards often started simple • Learn from initial use and gradually evolve • Simplicity helps it get off the ground • Easier to reach agreement • Easier to understand, adopt, implement, and use • Less constraint for v2.0 (when we know better) • Intended approach: • Focus on basic, run-time functionsDefer non-essential functions • Get it out quickly

  8. Object Types • Most repositories support typed documents, folders, and relationships, with fairly typical behaviors. • Their behaviors should be exposed for ease of use. • Many repositories do not support generic objects. • Originally, the model included a single, abstract root type. The other types were its subtypes. • This abstract root type was later dropped for simplicity, leaving multiple root types. • It can be re-introduced in the future if there is a need for it. • Policy object was added at a late stage.Its use has not been flushed out.

  9. Object Identity • Object identity is assigned by repository. • Unique, permanent, location-independent • Opaque (e.g., it can be a “pathname”) • Object name is merely a property. • A repository may enforce implementation-specific constraint (such as uniqueness within a certain scope), and use it to construct “path”. • Objects may not have meaningful name in some use cases(e.g. production imaging, e-mail archiving) • Path is not supported. • Not a good way to identify an object • Problematic for multi-filing, unfiling, and move() • Potential security issues: “id” revealing existence of an object at a certain location; access a target object vs access every object on the path; etc.

  10. Content Stream • Currently only 1 content-stream per document object is supported. • An application may create an object for each content-stream and use relationship to link it to a document. • To support multiple content-streams per object explicitly, the challenge is in the handling of content-stream metadata. • Increase complexity of object representation, versioning, and query • Also need additional CRUD methods

  11. Query • Most repositories use RDBMS to handle query. • Need a schema-based query language, & flat schema • A subset of SQL standard is adopted, both syntax and semantics • Language extensions are isolated(by using separate production rules and terminals) • Reason for preserving SQL semantics and isolating extensions: • Leverage user’s SQL knowledge, avoid confusion • Safe to expand the query language to a larger subset of SQL in the future

  12. Versioning • Most repositories support linear (chronological) versioning only. • Repositories differ in the way versions are linked. • So, version semantics is encapsulated in methods (current version, latest version, all versions).Explicit version navigation is not supported. • Private Working Copy (PWC) supports on-line (server-side) construction of a new version. • For repositories that support off-line (client-side) editing, PWC is not updatable and the entire new version is supplied at check-in.

More Related