<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: The Challenge of CMIS</title>
	<atom:link href="http://wordofpie.com/2009/04/20/the-challenge-of-cmis/feed/" rel="self" type="application/rss+xml" />
	<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/</link>
	<description>Ponderings on Life, the Universe, and Information</description>
	<lastBuildDate>Fri, 10 Feb 2012 22:28:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Pie</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3920</link>
		<dc:creator><![CDATA[Pie]]></dc:creator>
		<pubDate>Fri, 01 May 2009 20:46:46 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3920</guid>
		<description><![CDATA[I&#039;ve heard the same thing, though it saddens me as I like that aspect very much.]]></description>
		<content:encoded><![CDATA[<p>I&#8217;ve heard the same thing, though it saddens me as I like that aspect very much.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Walter</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3918</link>
		<dc:creator><![CDATA[Walter]]></dc:creator>
		<pubDate>Fri, 01 May 2009 20:08:42 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3918</guid>
		<description><![CDATA[From reading the reviewer&#039;s notes in the 0.6 Word doc, it looks like policies are going to be struck from the spec (every time policy is mentioned, there&#039;s a note that says something like &quot;TODO: remove this when we remove/kill policies&quot;). Unless maybe that&#039;s just one anti-policy reviewer&#039;s wishful thinking/hinting.]]></description>
		<content:encoded><![CDATA[<p>From reading the reviewer&#8217;s notes in the 0.6 Word doc, it looks like policies are going to be struck from the spec (every time policy is mentioned, there&#8217;s a note that says something like &#8220;TODO: remove this when we remove/kill policies&#8221;). Unless maybe that&#8217;s just one anti-policy reviewer&#8217;s wishful thinking/hinting.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pie</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3886</link>
		<dc:creator><![CDATA[Pie]]></dc:creator>
		<pubDate>Wed, 22 Apr 2009 16:07:54 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3886</guid>
		<description><![CDATA[Thanks for the clarification, but I stand by my statement. Not everything should be an extension. Not ready to start making any determinations at this point though. I just want CMIS 1.0 out the door.]]></description>
		<content:encoded><![CDATA[<p>Thanks for the clarification, but I stand by my statement. Not everything should be an extension. Not ready to start making any determinations at this point though. I just want CMIS 1.0 out the door.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Julian Reschke</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3880</link>
		<dc:creator><![CDATA[Julian Reschke]]></dc:creator>
		<pubDate>Wed, 22 Apr 2009 15:13:42 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3880</guid>
		<description><![CDATA[&lt;cite&gt;As for extensibility…some things, not going to argue which ones at this time, should be standard and not extensions. Extensibility is important, critical even, but not everything should be an extension.&lt;/cite&gt;

I didn&#039;t say that everything should be an extension.

Also, just because something is an extension doesn&#039;t mean it can&#039;t be a standard. For instance, both AtomPub and WebDAV (Proposed Standards) extend HTTP/1.1 (Draft Standard). Also, WebDAV Versioning and WevDAV ACL extend WebDAV.

So, an extension to WebDAV that would defined a document type model would be an extension to WebDAV (using one or more of WebDAV&#039;s extensibility points), but could become itself a standard.

More clearer now?]]></description>
		<content:encoded><![CDATA[<p><cite>As for extensibility…some things, not going to argue which ones at this time, should be standard and not extensions. Extensibility is important, critical even, but not everything should be an extension.</cite></p>
<p>I didn&#8217;t say that everything should be an extension.</p>
<p>Also, just because something is an extension doesn&#8217;t mean it can&#8217;t be a standard. For instance, both AtomPub and WebDAV (Proposed Standards) extend HTTP/1.1 (Draft Standard). Also, WebDAV Versioning and WevDAV ACL extend WebDAV.</p>
<p>So, an extension to WebDAV that would defined a document type model would be an extension to WebDAV (using one or more of WebDAV&#8217;s extensibility points), but could become itself a standard.</p>
<p>More clearer now?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pie</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3876</link>
		<dc:creator><![CDATA[Pie]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 17:24:14 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3876</guid>
		<description><![CDATA[This is something that I feel is more 2.0 anyway.  I am waiting for CMIS 1.0 before I start railing for Transactions.  

I have situations that need Transactions, but I understand that it is an more complicated feature.  It is more focused on the situation when you are linking into a repository from a system, like a Case Management system, where several actions have to take place and if any of them fail, roll them back.]]></description>
		<content:encoded><![CDATA[<p>This is something that I feel is more 2.0 anyway.  I am waiting for CMIS 1.0 before I start railing for Transactions.  </p>
<p>I have situations that need Transactions, but I understand that it is an more complicated feature.  It is more focused on the situation when you are linking into a repository from a system, like a Case Management system, where several actions have to take place and if any of them fail, roll them back.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Florent Guillaume</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3875</link>
		<dc:creator><![CDATA[Florent Guillaume]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 17:13:05 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3875</guid>
		<description><![CDATA[Actually some of the &quot;core&quot; vendors have repositories that cannot support transactions, and they objected to having them put in the standard... In the spirit of &quot;common ground&quot;, transactions are therefore not there.

If the standard says that they SHOULD be supported but doesn&#039;t not specify how, I&#039;m not sure it&#039;ll help. It&#039;s all up to the protocols implementations.]]></description>
		<content:encoded><![CDATA[<p>Actually some of the &#8220;core&#8221; vendors have repositories that cannot support transactions, and they objected to having them put in the standard&#8230; In the spirit of &#8220;common ground&#8221;, transactions are therefore not there.</p>
<p>If the standard says that they SHOULD be supported but doesn&#8217;t not specify how, I&#8217;m not sure it&#8217;ll help. It&#8217;s all up to the protocols implementations.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pie</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3874</link>
		<dc:creator><![CDATA[Pie]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 16:04:23 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3874</guid>
		<description><![CDATA[Florent, thanks for the comments.  My thoughts on the levels is specific to binding support. I&#039;d rather have the entire binding or none of the binding.  As mentioned before, my Policy thoughts will have to come later after I ponder it in more detail.

As for WS-Transactions, the support needs to be provided by the CMIS implementation. The CMIS standard could just say that they need to be supported and that would be a good step.  I have two scenarios for Transactions which I&#039;ll be sharing shortly.  All this client work keeps distracting me.]]></description>
		<content:encoded><![CDATA[<p>Florent, thanks for the comments.  My thoughts on the levels is specific to binding support. I&#8217;d rather have the entire binding or none of the binding.  As mentioned before, my Policy thoughts will have to come later after I ponder it in more detail.</p>
<p>As for WS-Transactions, the support needs to be provided by the CMIS implementation. The CMIS standard could just say that they need to be supported and that would be a good step.  I have two scenarios for Transactions which I&#8217;ll be sharing shortly.  All this client work keeps distracting me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Florent Guillaume</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3873</link>
		<dc:creator><![CDATA[Florent Guillaume]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 15:34:24 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3873</guid>
		<description><![CDATA[Regarding CMIS-54, the actual resolution is that the MIME type is optional. The reason for this is that some existing repositories (or simply filesystems) don&#039;t have a way of knowing a MIME type for the files they store, and the HTTP spec (for one) is very clear that it&#039;s a no-no to invent a MIME type for a file if you don&#039;t know it. Better serve it without any MIME type than invent one.

Regarding transactions, they can be supported by the SOAP protocol, using WS-Transaction. No need to add them to the domain model.

For policies, I&#039;d rather have some actual interoperability using simple ACLs than no interoperability using vague policies. Policies are so abstract anyway that every vendor exposing them would have to provide extensions. That&#039;s not interoperability really.

Also I wish people stopped pitting WebDAV *against* CMIS. One is a wire protocol extending HTTP, the other one is a domain model with several protocols to implement it. If WebDAV folks want to provide the required spec to implement the CMIS model, they&#039;re actually very welcome, the CMIS TC will support them, and maybe WebDAV will be a third available protocol in CMIS 2.

Finally, having several levels of compliance is something the CMIS TC really wants to avoid if possible, as it would to lead to lots of headache for implementors (especially clients). Levels of compliance means that consensus was not reached on what&#039;s the common ground between vendors. We may end up with having 3 levels for ACLs, as a necessity, but having them for the core domain model would be a step backwards.]]></description>
		<content:encoded><![CDATA[<p>Regarding CMIS-54, the actual resolution is that the MIME type is optional. The reason for this is that some existing repositories (or simply filesystems) don&#8217;t have a way of knowing a MIME type for the files they store, and the HTTP spec (for one) is very clear that it&#8217;s a no-no to invent a MIME type for a file if you don&#8217;t know it. Better serve it without any MIME type than invent one.</p>
<p>Regarding transactions, they can be supported by the SOAP protocol, using WS-Transaction. No need to add them to the domain model.</p>
<p>For policies, I&#8217;d rather have some actual interoperability using simple ACLs than no interoperability using vague policies. Policies are so abstract anyway that every vendor exposing them would have to provide extensions. That&#8217;s not interoperability really.</p>
<p>Also I wish people stopped pitting WebDAV *against* CMIS. One is a wire protocol extending HTTP, the other one is a domain model with several protocols to implement it. If WebDAV folks want to provide the required spec to implement the CMIS model, they&#8217;re actually very welcome, the CMIS TC will support them, and maybe WebDAV will be a third available protocol in CMIS 2.</p>
<p>Finally, having several levels of compliance is something the CMIS TC really wants to avoid if possible, as it would to lead to lots of headache for implementors (especially clients). Levels of compliance means that consensus was not reached on what&#8217;s the common ground between vendors. We may end up with having 3 levels for ACLs, as a necessity, but having them for the core domain model would be a step backwards.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephane Croisier</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3872</link>
		<dc:creator><![CDATA[Stephane Croisier]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 14:16:34 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3872</guid>
		<description><![CDATA[Yes, I agree with you (and still again with Kas: CMIS in search of scenarios: http://asserttrue.blogspot.com/2009/04/cmis-standard-in-search-of-scenarios.html): CMIS looks like being driven by techies for techies. As a product owner and not a code architect guru I am rather trying to envision possible impacts and consequences on features and on possible customers expectations. But everybody agrees on the scope of v1.0: it should be as minimalistic as possible and rapidly out. But if you also want some massive adoption, user stories and possible conflicts of interests with other existing specifications should be clarified first. Else Content Applications Providers will start gambling and betting on what is the best standards, which one they should implement, how each standard is or is not compliant with the others, etc... And this is usually the beginning of the end.

Regarding federated search (and content federation in general) CMIS is raising a lot of interesting questions. Federated Search Vendors are currently the most advanced in term of management of cross-content repositories issues. Vendors such as Autonomy are already packaging &lt;a href=&quot;http://www.autonomy.com/content/Products/idol-modules-connectors/index.en.html&quot; rel=&quot;nofollow&quot;&gt;400 custom CR connectors&lt;/A&gt;. It will be interesting to see the impact of CMIS on them. If I analyzed correctly your unified search prototype it is based on multiple search queries executed against each mounted CMIS connector. This is exactly what a vendor such as Autonomy is not recommending to do (cf: http://www.autonomy.com/content/Technology/autonomys-technology-limitations-of-other-approaches-federation/index.en.html). So it will be interesting to see how CMIS will help solve (or not) certain issues in this area. At lease it will help commoditize the content connector industry. Quite a shame that neither Interwoven nor Autonomy are member of the CMIS TC (excepted Exalead there are not a lot of other search vendors in there).

Finally always in term of content federation I envision a lot of issues as soon as some standard &quot;meanings&quot; could not be shared and reused in between each CR silo. Rendering or querying some remote documents is one thing, trying to use heteregenous compound documents split over multiple CR will be another one (nothing about your AIIM demonstration, it was great. Just some long term oriented toughts). I wrote something about it (http://scroisier.posterous.com/considering-cmis-as-another-plug-to-the-seman) and it would be interesting to see if CMIS will become the missing link between 1/ ontologists still mainly driven by Semantic Web oriented technologies (RDF; OWL; SPARQL;...) and 2/ classical CM vendors (JCR; CMIS; WebDAV...). But here again, at a certain point in time, things will have to better fit all together in the big picture of a unified content world. I bet on Tim Barnes-Lee for the long term story ;-)]]></description>
		<content:encoded><![CDATA[<p>Yes, I agree with you (and still again with Kas: CMIS in search of scenarios: <a href="http://asserttrue.blogspot.com/2009/04/cmis-standard-in-search-of-scenarios.html" rel="nofollow">http://asserttrue.blogspot.com/2009/04/cmis-standard-in-search-of-scenarios.html</a>): CMIS looks like being driven by techies for techies. As a product owner and not a code architect guru I am rather trying to envision possible impacts and consequences on features and on possible customers expectations. But everybody agrees on the scope of v1.0: it should be as minimalistic as possible and rapidly out. But if you also want some massive adoption, user stories and possible conflicts of interests with other existing specifications should be clarified first. Else Content Applications Providers will start gambling and betting on what is the best standards, which one they should implement, how each standard is or is not compliant with the others, etc&#8230; And this is usually the beginning of the end.</p>
<p>Regarding federated search (and content federation in general) CMIS is raising a lot of interesting questions. Federated Search Vendors are currently the most advanced in term of management of cross-content repositories issues. Vendors such as Autonomy are already packaging <a href="http://www.autonomy.com/content/Products/idol-modules-connectors/index.en.html" rel="nofollow">400 custom CR connectors</a>. It will be interesting to see the impact of CMIS on them. If I analyzed correctly your unified search prototype it is based on multiple search queries executed against each mounted CMIS connector. This is exactly what a vendor such as Autonomy is not recommending to do (cf: <a href="http://www.autonomy.com/content/Technology/autonomys-technology-limitations-of-other-approaches-federation/index.en.html" rel="nofollow">http://www.autonomy.com/content/Technology/autonomys-technology-limitations-of-other-approaches-federation/index.en.html</a>). So it will be interesting to see how CMIS will help solve (or not) certain issues in this area. At lease it will help commoditize the content connector industry. Quite a shame that neither Interwoven nor Autonomy are member of the CMIS TC (excepted Exalead there are not a lot of other search vendors in there).</p>
<p>Finally always in term of content federation I envision a lot of issues as soon as some standard &#8220;meanings&#8221; could not be shared and reused in between each CR silo. Rendering or querying some remote documents is one thing, trying to use heteregenous compound documents split over multiple CR will be another one (nothing about your AIIM demonstration, it was great. Just some long term oriented toughts). I wrote something about it (<a href="http://scroisier.posterous.com/considering-cmis-as-another-plug-to-the-seman" rel="nofollow">http://scroisier.posterous.com/considering-cmis-as-another-plug-to-the-seman</a>) and it would be interesting to see if CMIS will become the missing link between 1/ ontologists still mainly driven by Semantic Web oriented technologies (RDF; OWL; SPARQL;&#8230;) and 2/ classical CM vendors (JCR; CMIS; WebDAV&#8230;). But here again, at a certain point in time, things will have to better fit all together in the big picture of a unified content world. I bet on Tim Barnes-Lee for the long term story <img src='http://s1.wp.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bex</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3871</link>
		<dc:creator><![CDATA[bex]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 13:33:00 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3871</guid>
		<description><![CDATA[Thanks for the update!

I haven&#039;t been as active as I&#039;d like in the whole CMIS analysis space... so I&#039;m glad you have been!]]></description>
		<content:encoded><![CDATA[<p>Thanks for the update!</p>
<p>I haven&#8217;t been as active as I&#8217;d like in the whole CMIS analysis space&#8230; so I&#8217;m glad you have been!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pie</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3870</link>
		<dc:creator><![CDATA[Pie]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 13:20:39 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3870</guid>
		<description><![CDATA[I agree with your assessment on Microsoft. I talked about &lt;a href=&quot;http://wordofpie.com/2008/09/11/vendor-support-for-cmis/&quot; rel=&quot;nofollow&quot;&gt;Vendor Support&lt;/a&gt; in more detail back in September, and the &lt;a href=&quot;http://wordofpie.com/2009/02/05/cmis-and-sharepoint/&quot; rel=&quot;nofollow&quot;&gt;importance of SharePoint to CMIS&lt;/a&gt; in February.

Levels of compliance is good and I would understand if vendors supported one binding only.  I would prefer it be the Web Services binding though as that is where the larger gap in the IT infrastructure is located.]]></description>
		<content:encoded><![CDATA[<p>I agree with your assessment on Microsoft. I talked about <a href="http://wordofpie.com/2008/09/11/vendor-support-for-cmis/" rel="nofollow">Vendor Support</a> in more detail back in September, and the <a href="http://wordofpie.com/2009/02/05/cmis-and-sharepoint/" rel="nofollow">importance of SharePoint to CMIS</a> in February.</p>
<p>Levels of compliance is good and I would understand if vendors supported one binding only.  I would prefer it be the Web Services binding though as that is where the larger gap in the IT infrastructure is located.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pie</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3869</link>
		<dc:creator><![CDATA[Pie]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 13:11:57 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3869</guid>
		<description><![CDATA[Julian, thanks for your comment. I&#039;ll have to get back to you with a detailed response, but I wanted to share your thoughts with others now.  Note that I think WebDAV has been, and should continue to be, an important part of the entire solution.

I will say that my excitement over the standard centers on the Web Services binding. I see the AtomPub Binding more as a way to stop a WS-* v ReST war from breaking out in the committee. I wasn&#039;t involved in the discussions, so I can only guess.

As for extensibility...some things, not going to argue which ones at this time, should be standard and not extensions. Extensibility is important, critical even, but not everything should be an extension.]]></description>
		<content:encoded><![CDATA[<p>Julian, thanks for your comment. I&#8217;ll have to get back to you with a detailed response, but I wanted to share your thoughts with others now.  Note that I think WebDAV has been, and should continue to be, an important part of the entire solution.</p>
<p>I will say that my excitement over the standard centers on the Web Services binding. I see the AtomPub Binding more as a way to stop a WS-* v ReST war from breaking out in the committee. I wasn&#8217;t involved in the discussions, so I can only guess.</p>
<p>As for extensibility&#8230;some things, not going to argue which ones at this time, should be standard and not extensions. Extensibility is important, critical even, but not everything should be an extension.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pie</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3868</link>
		<dc:creator><![CDATA[Pie]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 13:00:09 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3868</guid>
		<description><![CDATA[Stephane, Thanks for your comment.  The story needs to be better explained.  For me, the ECM-to-ECM is actually the secondary use-case.  I see it more as you want it, Content applications with ECM back-ends.  It isn&#039;t just WCM though, Case Management systems and providing ECM as infrastructure to the Enterprise are essential.  This requires more advanced features.  The Alfrescal does not leverage all of CMIS, and maybe it is better done with WebDAV.  On the other hand, it could just be at the first iteration and more advanced features will require the more advanced CMIS features.

I know, from experience, that a CMIS application needs to be able to query the object model so that subtle differences in the &quot;same&quot; model can be determined from repository to repository.  Alternatively, querying the repository for details may tell you what fields to map.  Afrescal is a one-to-one.  Taking it and making it one-to-many, just that one step, may require CMIS over WebDAV.

As for a better example, hop onto the Alfresco Webcast tomorrow, link in the post.  The AIIM iECM committee wrote a Search Federator using CMIS, Web Services Binding, to conduct searches against Alfresco, EMC, and Nuxeo.]]></description>
		<content:encoded><![CDATA[<p>Stephane, Thanks for your comment.  The story needs to be better explained.  For me, the ECM-to-ECM is actually the secondary use-case.  I see it more as you want it, Content applications with ECM back-ends.  It isn&#8217;t just WCM though, Case Management systems and providing ECM as infrastructure to the Enterprise are essential.  This requires more advanced features.  The Alfrescal does not leverage all of CMIS, and maybe it is better done with WebDAV.  On the other hand, it could just be at the first iteration and more advanced features will require the more advanced CMIS features.</p>
<p>I know, from experience, that a CMIS application needs to be able to query the object model so that subtle differences in the &#8220;same&#8221; model can be determined from repository to repository.  Alternatively, querying the repository for details may tell you what fields to map.  Afrescal is a one-to-one.  Taking it and making it one-to-many, just that one step, may require CMIS over WebDAV.</p>
<p>As for a better example, hop onto the Alfresco Webcast tomorrow, link in the post.  The AIIM iECM committee wrote a Search Federator using CMIS, Web Services Binding, to conduct searches against Alfresco, EMC, and Nuxeo.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Serge Huber</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3867</link>
		<dc:creator><![CDATA[Serge Huber]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 10:43:44 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3867</guid>
		<description><![CDATA[Thank you for the interesting sum up on CMIS. I think that it is interesting, mostly by the industry momentum that it has but I think that again Microsoft will make it or break it. With such a stronghold on the desktop and content production, it is their commitment to this standard that will make the difference to the previous approaches in this area (thinking of previous iECM standards). For me the real test for CMIS will be to be able to integrate on &quot;lightweight&quot; platforms, such as Javascript clients and legacy servers. If this technology can stretch this far this would be a real disruptive technology, otherwise it would just become another difficult-to-implement and less used standard.

One of the nicer ideas in the JCR (JSR-283) standards, early on was the idea of having &quot;levels&quot; of compliance. This offered a way to still adhere to the standard, at least in the most important aspects, and be able to gradually integrate the more complex parts. CMIS has some similarities in this approach but they still would need refining.

Anyway, it is promising to say the least, and will be very interesting to develop with.]]></description>
		<content:encoded><![CDATA[<p>Thank you for the interesting sum up on CMIS. I think that it is interesting, mostly by the industry momentum that it has but I think that again Microsoft will make it or break it. With such a stronghold on the desktop and content production, it is their commitment to this standard that will make the difference to the previous approaches in this area (thinking of previous iECM standards). For me the real test for CMIS will be to be able to integrate on &#8220;lightweight&#8221; platforms, such as Javascript clients and legacy servers. If this technology can stretch this far this would be a real disruptive technology, otherwise it would just become another difficult-to-implement and less used standard.</p>
<p>One of the nicer ideas in the JCR (JSR-283) standards, early on was the idea of having &#8220;levels&#8221; of compliance. This offered a way to still adhere to the standard, at least in the most important aspects, and be able to gradually integrate the more complex parts. CMIS has some similarities in this approach but they still would need refining.</p>
<p>Anyway, it is promising to say the least, and will be very interesting to develop with.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Julian Reschke</title>
		<link>http://wordofpie.com/2009/04/20/the-challenge-of-cmis/#comment-3866</link>
		<dc:creator><![CDATA[Julian Reschke]]></dc:creator>
		<pubDate>Tue, 21 Apr 2009 07:50:46 +0000</pubDate>
		<guid isPermaLink="false">http://wordofpie.wordpress.com/2009/04/20/the-challenge-of-cmis/#comment-3866</guid>
		<description><![CDATA[&lt;cite&gt;Then there is WebDAV.  If you look strictly at the AtomPub binding of CMIS, you get confused as to what the point may be.  Remember, this is not just for applications to save and update content in a repository.  CMIS has advanced queries and, as a whole, is able to function as a standard interface in a Service-Oriented Architecture.  WebDAV does not have object typing, schema, folder navigation, or querying.  WebDAV is a useful way to save content from your desktop applications to an ECM repository, but it won’t link-up to your ESB or serve as the basis for an integration like the aforementioned Drupal/Alfresco blending.&lt;/cite&gt;

AtomPub doesn&#039;t have object typing or &quot;schema&quot; either. That is what extensibility is for.

AtomPub doesn&#039;t have folder navigation, but WebDAV does.

AtomPub doesn&#039;t have query, but WebDAV does (RFC 5323).

It seems to me that the people who dismissed WebDAV as protocol binding early on didn&#039;t really understand the WebDAV feature set and its extensibility model. The text about WebDAV in version 0.50 of the draft kind of proves that.]]></description>
		<content:encoded><![CDATA[<p><cite>Then there is WebDAV.  If you look strictly at the AtomPub binding of CMIS, you get confused as to what the point may be.  Remember, this is not just for applications to save and update content in a repository.  CMIS has advanced queries and, as a whole, is able to function as a standard interface in a Service-Oriented Architecture.  WebDAV does not have object typing, schema, folder navigation, or querying.  WebDAV is a useful way to save content from your desktop applications to an ECM repository, but it won’t link-up to your ESB or serve as the basis for an integration like the aforementioned Drupal/Alfresco blending.</cite></p>
<p>AtomPub doesn&#8217;t have object typing or &#8220;schema&#8221; either. That is what extensibility is for.</p>
<p>AtomPub doesn&#8217;t have folder navigation, but WebDAV does.</p>
<p>AtomPub doesn&#8217;t have query, but WebDAV does (RFC 5323).</p>
<p>It seems to me that the people who dismissed WebDAV as protocol binding early on didn&#8217;t really understand the WebDAV feature set and its extensibility model. The text about WebDAV in version 0.50 of the draft kind of proves that.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

