Adobe did have a solution:
Adobe Bridge acts as a medium between Alfresco & Adobe InDesign. Adobe Drive 3 allows a connection to a CMIS repository and the ability to mount it as a drive on your machine. This functionality enables you to browse Alfresco as if it were a folder structure on your machine. It also has a powerful search interface which can search content and has a display preview via Adobe Drive and Adobe Bridge. You can perform your own customizable CMIS calls to search for assets and then use the rendition service to display the same within the document library of Alfresco Share Interface.
And Simflofy claims the following:
In general, here is the mapping between the AtomPub link relations used by CMIS and other specifications:
Appendix A. Relationship to Java Content Repository (JCR) and WebDAV
The link relations defined in Section 3 correspond to various
properties used in WebDAV Versioning [RFC3253] and JCR [JSR-283]:
version-history
WebDAV: the resource identified by the DAV:version-history
property ([RFC3253], Sections 5.2.1 and 5.3.1).
JCR: the node identified by jcr:versionHistory property
([JSR-283], Section 3.13.2.4) for versionable nodes, the parent
folder for version nodes.
latest-version
WebDAV: for version-controlled resources, DAV:checked-in
([RFC3253], Section 3.2.1) or DAV:checked-out ([RFC3253], Section
3.3.1), depending on checkin state. For version resources, a
successor version that itself does not have any successors.
JCR: the version node identified by the jcr:baseVersion property
([JSR-283], Section 3.13.2.5) for versionable nodes; for version
nodes, a successor version that itself does not have any
successors.
working-copy
WebDAV: for version-controlled resources that are checked-out in
place: the resource itself. For version resources: each resource
identified by a member of the DAV:checkout-set property (see
[RFC3253], Section 3.4.3).
JCR: for checked-out versionable nodes: the node itself.
working-copy-of
WebDAV: the resource identified by the DAV:checked-out property
(see [RFC3253], Section 3.3.1).
JCR: for checked-out versionable nodes: the node identified by the
jcr:baseVersion property ([JSR-283], Section 3.13.12.5).
Brown, et al. Informational [Page 9]
RFC 5829 Version Navigation Link Relations April 2010
predecessor-version
WebDAV: each resource identified by a member of DAV:predecessor-
set ([RFC3253], Sections 3.3.2 and 3.4.1).
JCR: each node identified by a member of jcr:predecessors
([JSR-283], Section 3.13.3.3).
successor-version
WebDAV: each resource identified by a member of DAV:successor-set
([RFC3253], Section 3.4.2).
JCR: each node identified by a member of jcr:successors
([JSR-283], Section 3.13.3.4).
Historically, this should have been part of the specification:
The first thing I'd like to work on is improving the CMIS text that talks about the relation to WebDAV. In its current state it is (IMHO) in the wrong place (I think the comparison should be made with the HTTP binding, not the model), and lacks some precision. In general, although JCR is an API, and WebDAV a wire protocol, both do define a model as well. Sooner or later, people will want to map between CMIS and those, so I think it's inevitable that mappings will be defined — this could be here, in a JSR, in an open-source project like Jackrabbit, or the IETF. I don't think the place matters a lot, as long as it's done properly. It's some time ago that I read the CMIS base spec, but my first impression was that CMIS is a proper subset of the functionality defined in JCR (maybe except query), and defining a mapping CMIS->JCR should be simple. The other way around however will be harder. It seems to me that it would be good to minimize differences where possible. Similarly, WebDAV has large overlap with CMIS, some stuff CMIS doesn't need (like locking), and some stuff missing (type model). On the other hand, WebDAV is extensible, and WebDAV extensions for remoting JCR will be developed anyway. Furthermore, there's some overlap with current discussions on the Atom Protocol mailing list, such as defining extensions for hierarchical collections. It would be cool if we could avoid inventing this for CMIS, if it's already done somewhere else. In this context it would be great to have somebody with GData (Google Data) knowledge in the TC. Also, I expect that Microsoft's AtomPub experts should be involved as well (or are they here already?). Finally, I'd like to understand whether CMIS is mainly thought as a way to connect document stores, or whether we expect it to be used for client (desktop) integration as well. In the latter case it would be good to understand why we're doing something new, instead of extending WebDAV which already has broad client support.
References
