- 5 Things to Consider when Integrating your Content Management System and Portal
(6 comments) - CMS Review: Oracle Universal Content Management (UCM)
- Is Microsoft's New Windows Phone 7 Smartphone Competition for iPhone?
- Installing SharePoint 2010 on Windows 7
(5 comments) - Google's Marketplace Spells Trouble for Microsoft
(5 comments) - Sun Microsystems Chief Open Source Officer Leaves Oracle
- Google Opens Marketplace for Google Apps: Box.net, Zoho on Board
(2 comments)
Get the NewsletterWCM Field Notes: The Skinny on JCR, CMIS and OSGi
WCM Fields Notes is a regular column written in collaboration with Jon Marks (@McBoof), head of development at LBi. This first issue looks at evolving standards in the content management space and how they might influence you when selecting and implementing a web content management system.
The web is humming with talk of standards at the moment — due mainly to the fact that the Content Management Interoperability Standard (CMIS) version 1.0 is nearing its final state and open for public review.
To celebrate this, I recently drew a picture:
CMIS, JCR and OSGi for Idiots by Jon Marks (full version here)
Now while this picture is undoubtedly the best thing you've ever seen, it may very well make zero sense to you. To address that problem, in this article I shed some light on what the JCR, CMIS and OSGi standards are, and why you should care about them.
Java Content Repository (JCR) Alive and Well
Unlike standards such as WebDAV and the other JCR (the Johnson County Republicans), the Java Content Repository is still in active development.
For the purposes of this article, let's define the JCR as an infrastructure specification for interacting with general purpose content repositories using a Java API. If JCR is a new topic for you, I strongly recommend having a look at JCR In 15 Minutes by Bertrand Delacretaz.
For the rest of us, let's remember that a content repository is a multi-purpose service that combines the best of relational databases and file systems, with a number of useful facilities like versioning and observation. The following diagram — presented by David Nuescheler (@davidnuescheler), JCR Spec Lead,Official JCR/CMIS Liaison and CTO of Day Software, at the recent JBoye conference in Aarhus — provides us with a quick reference for typical content repository services.
Content Repository Concepts by David Nuescheler
The Java Content Repository specification has evolved over a number of years and with the participation of many different software organizations. Three months ago we saw the final release of version 2.0 of the spec. The two versions of the Java Content Repository — JCR 1.0 and JCR 2.0 — are defined by two Java Specification Requests, JSR-170 and JSR-283 respectively.
The following diagram provides a high level view of JCR and the domains of v1.0 versus the v2.0 specification.
JCR from 10,000 Feet — v1.0 versus v2.0
The v2.0 iteration deprecated XPath support and introduced a number of new features, with my personal favorite being Shareable Nodes. The Shareable Nodes feature gives you the ability to implement a content graph, not just a tree. In other words, with v2.0 a content item in the repository can have more than one parent.
Does JCR Need to be in Your RFP?
In the field, I still see the JCR specs mentioned in many content management RFPs. Then again, we know that buzzwords are often included in CMS RFPs just for the sake of it. To this point Matt Hamilton (@HammerToe), Technical Director of Netsight, tweeted this recently:
Got govt tender doc mandating JCR-* standards, which effectively mandates Java. Can a govt body legally mandate a technology in a tender?
Matt raises an interesting question. I don't think we'll ever know if this was put into the RFP to intentionally mandate Java, or was simply cut-and-paste from some other buzzword-rich requirements document.
I often see strange stuff in CMS RFPs. Piero Tintori (@pierotintori), CEO at TERMINALFOUR (news, site) has some funny examples of questions he recently saw. My favorites include "What size are the shipping pallets used for your product?" and "Is your product radioactive?".
You need to understand that mandating JSR-170 and/or JSR-283 in your RFP implies a Java-based CMS. If you include such requirements, know precisely why, have a clear business case supporting your thinking, and don't waste the time of the non-Java vendors by sending the RFP to them.
The New Kid on the Block: CMIS
The Content Management Interoperability Specification (CMIS) is an OASIS project started in 2008 and driven by a number of medium and large content management vendors (i.e., Alfresco, Day, EMC, Fatwire, IBM, Microsoft, Open Text and others).
At this point I'm assuming that most readers have basic familiarity with CMIS. But for those that don't, have a look at the informative JCR loves CMIS presentation by Nuescheler and review the CMSWire coverage here. If you're feeling ambitious, you can take the deep dive on the OASIS project website.
For the purposes of this article, let's define CMIS as an interoperability specification for interacting with document-centric content repositories via HTTP-based protocols.
To keep ourselves on the straight and narrow, focus on the oft overlooked word interoperability in the CMIS acronym. Keep in mind that the aim of CMIS is to allow diverse systems to interoperate.
Further, CMIS is by definition a lowest common denominator specification — it only provides core functionality. And by being simple, it is meant to be easy for vendors to implement. In terms of its place in the standards world, CMIS is intended to complement JCR, not compete with it — JCRs are used as a systems internal repository, where as repositories interacted with via CMIS-compliant interfaces are typically supplementary.
CMIS from 10,000 Feet
Should it be called DMIS?
There is broad agreement that CMIS 1.0 focuses on document-centric use cases — and it's for this reason that I raise the (rhetorical) DMIS question. This is also the reason that the WCM Field Notes on CMIS make for easy reading — there are none, nor will there be for a while.
CMIS is not a Web Content Management (WCM) specification, nor is it an Enterprise Content Management (ECM) specification. In fact, let's keep in mind that it isn't a content management specification at all. It is a content repository interoperability specification.
If you are managing composite HTML pages (that's WCM), CMIS isn't ready for you. Please don't go adding CMIS as a requirement in your WCM selection RFP document quite yet. It's not big and it's not clever. Feel free to include it in your Document Management RFP as recently suggested by Alan Pelz-Sharpe of CMS Watch.
If CMIS is Not for WCM…Then What?
As usual, Laurence Hart (The Pie) explains it best, so I'm going to paraphrase him. His first example is Repository-to-Repository (R2R) interaction.
R2R interactions happen often in existing Enterprise CMS suites, often in proprietary ways. A fairly typical example is the journey of a piece of content from the collaboration tool (authoring environment) to the content management tool (to publish it) to the records management tool (to keep it compliant).
Each component in this journey could speak CMIS and pass the content directly between one another. As CMIS does not have an event system to let some external workflow engine know about changes, this kind of integration can't be easily replaced by an external application without hacking.
I prefer Laurence's second use case — Application-to-Repository (A2R) interaction. Here we have an application that uses CMIS to talk to any compliant repository. This is the "SQL for Content Repository" situation and the possibilities are endless. The "application" could be lightweight JavaScript running in a browser for a bit of CMIS mashup fun.
His third use case, Federated Repositories, is A2R on steroids — a single user interface presents the information from multiple repositories. This is clearly good news for a cross-repository search but, then again, search engines have always been good at indexing disparate sources and aggregating the results, so we probably don't need CMIS for that. But if we want to edit the results and save them back to the repository, we need a lot more than a search engine.
People have suggested that CMIS might be useful for content migrations. This makes some sense, but only if you're in a hurry to decommission a legacy system. Otherwise, just leave the content where it is and use one of the methods above to get at it.
It will be interesting to see if pure-play content migration vendors such as Vamosa and Kapow take an interest in it. My guess is no.
[Editor's Note: For more on this topic, see our series on content migration tools.]
A CMIS vs. WSRP Diversion
For clarification purposes, it's worth mentioning two other Java Specification Requests common in the CMS field. JSR-168 and JSR-286 define different versions of the Java Portlet Specification.
I think that the relationship between CMIS and the JCR is quite similar to the relationship between Web Services for Remote Portlets (WSRP) and the Java Portlet Specs:
- One provides a local API, the other is meant to be used remotely over HTTP
- One is Java based (although the JCR has been ported), while the other is programming language independent
- Java Portlets and JCR repositories can be exposed via WSRP and CMIS using Apache WSRP4J and Apache Chemistry respectively
- The one is a Java Community Process specification, the other is an OASIS specification
- They are complementary, not competing technologies
With that said, it appears that WSRP is losing the standards war to widely adopted, simpler things like Google's OpenSocial and other widget/gadget platforms. Let's hope the same isn't in store for CMIS.
OSGi - the Dynamic Module System for Java
You may not have heard of OSGi, and the acronym certainly doesn't give away any secrets. It used to stand for the Open Services Gateway initiative, but it doesn't stand for much of anything these days. This is not to say that OSGi is passé or dead. Au contraire.
To start, it's much more helpful to use the tagline: The Dynamic Module System for Java (tm). It doesn't have much to do with the JCR or CMIS, except that it is an important part of Day Software's JCR repository product, and is included on my most excellent diagram. More seriously, I feel it deserves a mention and that content management people should be aware of it.
Enterprise Java No Place for Dilettantes
Let's face it, Java Enterprise Edition can be a beast — the world is trying to keep things simple and Java EE certainly isn't. This is precisely why Java application frameworks like Spring have taken a big bite of the market. The main selling points for OSGi are that compared to a traditional Java enterprise application deployment, an OSGi-based app improves modularity and is much simpler.
OSGi provides a framework which sits on top of a Java Virtual Machine. Developers create bundles which live inside the framework. The framework manages the lifecycle of these bundles — installing, starting, stopping and uninstalling them, the dependencies between them (saving you from Dependency Hell) and controls access to them. The framework also provides a Compendium of Services (much like Java EE) to make a developer's life easier. These include logging, configuration management, monitoring, caching, deployment and provisioning.
The following diagram provides a high-level view of bundles and OSGi framework services. For a deep dive on why one might fall in love with OSGi, you can scratch around in the OSGi Alliance website.
OSGi and Bundles From 10,000 Feet
Why You Should Care
Content management people with a penchant for Java should have an eye on OSGi. Why? Because with OSGi one can do many neat things in a sane manner. For example, engineers might use OSGi as a basis for a product's auto-update feature. Or they can use it to deploy code and content bundles between different environments. Or they could run two versions of a product side-by-side. All the while, their code will be neater and more modular, and change management will be more rational.
For now, let's just settle for two OSGi takeaways. Firstly, writing truly modular software is good, and OSGi provides a framework for doing this. Secondly, you don't just deploy applications. You deploy everything. When I say everything, this includes code, content, configuration or combinations of these things together.
If you find these concepts appealing, I urge you to read more about OSGi and consider how its use might impact your life and/or the sanity of the platform you're about to invest in. But think carefully about including OSGi as a CMS RFP requirement — doing so will dramatically limit your options.
Some good OSGi starting points:
- The OSGi Architecture — the official overview
- The Web on OSGi: Here's How — contains different architecture options
- Hello, OSGi, Part 1: Bundles for beginners — a tutorial
- Bundle.update: the Current State of OSGi — recent news on OSGi developments
In summary
The success of a standard is, in my humble opinion, measured entirely by how widely it is adopted. When you're out hunting in the Web CMS field, you've got to keep your eye out for the important ones. Long-established standards are easy to spot, but sometimes a standard is on the verge of fame so you miss it. There is nothing more depressing than hacking together your own proprietary mess only to discover that something already exists that will do a far better job than you ever did. So, when putting together your solution architecture remember:
- If you're using a Java API to access a content repository, make sure you think about the JCR as an alternative
- If you're accessing remote documents over the web, consider using CMIS.
- If you're scared of building a tightly coupled Java monolith, read more about OSGi
The standards are out there. Stand on the shoulders of giants. Use them.
And now we'll close with the wisdom of Bob Dylan:
Oh, what did you see, my blue-eyed son?
Oh, what did you see, my darling young one?
I saw a newborn baby with wild wolves all around it,
I saw a highway of diamonds with nobody on it,
- A HARD RAIN'S A-GONNA FALL
About the Author
Jon Marks is Head of Development at interactive agency LBi in London. He specializes in web content management solutions. You can following him on Twitter here or via his blog jonontech.com.
Was this article useful?
Email It
Stumble It
Add RSS22 Reader Comments
Leave a Response
Processing...
Job Openings View all
| Post a job
| 
RSS
- Director of Mobile Applications at Barnes and Noble
- Senior IA / UX Designer at Fox Mobile Group
- Analyst, Serving Customer Intelligence Professionals at Forrester Research
- Senior Sales Rep at Clickability
- Project Manager/Digital Media at TMG
- LiveServer/RedDot/OpenText - CMS Developer at LP Associates
- Lead Developer (Drupal) at Sandusky Newspapers, Inc
- Android Developer at Yelp
Featured Events View all
| Add event
| RSS
- Apr 21, 2010 – Drupalcon San Francisco 2010
- Apr 22, 2010 – AIIM International Expo 2010
- May 5, 2010 – CMS Expo 2010 (Evanston)
- May 6, 2010 – J Boye Philadelphia 2010
- May 20, 2010 – Gilbane Conference San Francisco
“Application-to-Repository (A2R) interaction” is a common WCM pattern, and is used in various WCMS products (including OpenText VCM, Jackrabbit / Day CRX and Alfresco WCM, amongst others).
Given this, isn't it a bit premature to say that CMIS is not for WCM? WCM may not have been a focus for CMIS 1.0, but to say that it's not relevant for WCM at all is to miss some interesting opportunities.
Excellent. Let's finish this CMIS versus DMIS discussion.
To start, two confessions. Firstly, I was in the CMIS is great for non-document Content Management camp when we discussed it back in June. See the comments on this article: http://asserttrue.blogspot.com/2009/06/cmis-or-dmis.html
Secondly, I always agree with Pie and he thinks CMIS is great for Content Management. So I'm bound to do yet another U-Turn and decide it is fine.
That said, I've been persuaded recently that CMIS 1.0 is actually quite painful to use for composite HTML content management. A simple HTML page consists not just of the HTML, but also the associated images, CSS, JavaScript and other assets. Managing the references between these assets and composing them on the client after being retrieved via the CMIS sounds tricky. The upload is equally awkward. I'm rather hoping David N or Stephane C comes rushing to my defense …
Also, I really don't think the name should be changed. CMIS is just fine. But, the current version of the standards will be most useful for documents, not HTML content. All the plug fests and demos I've seen have focussed on the DM use cases. Hopefully version 2.0 will tackle the HTML documents.
One could argue that the main reason that WebDAV isn't under active development is that it's mature, and already covers functionality others still have to achieve.
That being said, WebDAV is an extension of HTTP, and thus participates in whatever new the HTTP community comes up with, such as the PATCH method.
Also, how exactly are three RFCs in the last 14 months, plus some more in the pipeline, “not active development”?
Hi Julian,
I must confess I don't follow new WebDAV RFC's. From my point of view, it's a successful standard that has been adopted by nearly every CMS vendor. It deserves to be in a CMS RFP. I just think of it as an old friend that does exactly what it is meant to do, and does it well. Can you outline what the key features of the new RFCs are for us?
Good point about HTTP PATCH. For those that haven't heard of it, I recommend Justin Cormack's article on it:
http://blog.technologyofcontent.com/2009/12/smart-resources-or-why-you-should-care-about-http-patch/
We expected to see more vendors implement OSGI when we added it to our platform in 2007. It's mostly used in 'containers' such as glassfish and Websphere, but it's great to have in a product such as a WCM (*start naming discussion here*).
We use OSGI to support uploading custom modules (or add-ons or plugins or whatever you call them). OSGI provides a good separation in the architecture and provides the necessary features such as dependencies, versioning, instant deployment etc. But you're right: it's completely different from JCR or CMIS
Last year's RFCs covered SEARCH (DASL), plus minor extensions to ACL handling, plus extensions to MKCOL.
I the pipeline, for instance, are (a) BIND (the WebDAV equivalent of multifiling), plus (b) extensions for creating resource where the server assigns the URL.
As far as I can tell, the main missing piece is exposing JCR node type/property type info per WebDAV.
Jon, as you mentioned it JCR is an infrastructure specification while CMIS is an interoperability standard. So this generally means that we need scenarios with at least two ?content silos? to get some CMIS utility.
That?s said and coming back to WCM we are always facing the two traditional approaches:
1) WCM is treated as a dedicated content silo. In such use cases Web Content does not need all the bells and whistles of an ECM back-end system. For example when entering your status update on Facebook or when you post a blog post on Posterous you usually do not want to care about versioning, file plans, ontologies, workflow, staging and other ECM-oriented goodies. Lots of web initiatives do not need all these features so there are no reasons to standardize and to integrate them.
2) WCM is only acting as a presentation layer. But the content production and the lifecycle of your key content assets is managed by an ECM back-end system. And this should of course not be limited only to your binary documents; this could perfectly include any other value added content assets. If I take my previous blogging example again, the Harvard Business School is posting thousands of high value blog posts a year. They perhaps want to manage such content assets from a more secure and reliable manner than just posting them into a *lightweight* WCM system.
So as you mentioned it, this is perhaps not worth or often over complex to put ALL your content into a separate ECM/DAM/RM platform (including all your one pixel gif icon, some temporary ads banners, all contextual cross-references boxes, etc). As usual the situation is not black or white. It really depends of each customer use case and a need to more precisely inventory and define what are the key strategical content assets vs secondary non (or less) critical content items.
Finally we could certainly take a more extremist position and question ourselves to know if CMIS could also act as an infrastructure specification to develop some ?CMIS Stores? in order to let you build some Content Applications. In such a scenario CMIS directly fight with the JCR leading to some hot and passionate debates (not counting of course all engineers-oriented argumentations about the usage of such or such design patterns among the two spec ? three if we include WebDAV).
Stéphane
Jon, excellent post. Just wanted to share one thing, not all content is HTML/”Web Content” or documents.There are images which I might manage as an ad agency. There are videos and audio files. There are all sorts of things that can be managed.
Sounds like the problem is that CMIS doesn't handle links and references very well. That would apply to compound documents. If the information is embedded within the document, then is it the repository's or application's responsibility to identify and process those links?
-Pie
First of all, thanks a lot to Jon, excellent post!
On WCM and CMIS I think the charter explicitly excluding WCM pretty much illustrates the DM focus. Which I think is a good thing for the TC.
http://xml.coverpages.org/cmis.html#CMIS-Charter
On the usecase mentioned around both reading and writing (web) content from a browser, I think it has been discussed back and forth in the TC.
http://markmail.org/thread/3wv7ploaglahfkqv
Let me try to illustrate the detail.
(1) Uploading a “document” from a browser.
At this stage current real-life browsers allow to upload a file with a multi-part post to a server. Essentially being able to write the content repository from a simple HTML form in general in my opinion would definitely be a must for a REST oriented protocol used for WCM.
(2) Displaying content with “references”
Let's assume that we have and HTML “document” that refers to images, css, js or other html documents through an “img”, “script” or “a”. Well any real-life HTML document you could find ;)
Now let's assume that one would like to store the HTML document plus some of the assets that it refers to in a CMIS repository, and use the CMIS protocol to read from it with a browser.
This is not just very impractical, since there is no concept of a “path” in CMIS but entirely impossible, since one would have an ID based access to the CMIS server to first to look-up the (implementation specific) URL on read the image from. So, you strictly speaking you could not even refer to images in a CMIS repo since a document is identified not by URL or path but by CMIS ID.
Compound documents don't change a thing about it.
I appreciate that the CMIS specification effort is focused on DM, and I really think that's perfect considering the group of people that we have involved, but it is absolutely apparent that CMIS is a subset of WebDAV in terms of features and functions, install base and availability but more importantly also in terms of considered usecases since of course WebDAV handles (2) beautifully.
Of course it is possible to introduce the concept of a “path” in any particular implementation and further constrain the implementation to be usable for the web, but those would be implementation specific extensions that would not be portable across other CMIS implementations.
Bottom-line: If you have a browser and want you use content for the web using CMIS as protocol is definitely not a viable choice.
Given that the scope of CMIS is (fat)client-server or server-server interop for document management, I think that's perfectly fine.
It is just out of scope.
As long as we don't have the concept of a “path” as a first class citizen in CMIS don't even think of the web.
regards,
david
Pie, CMIS does actually cover generic relations fairly well at the repository level, though not at the document level. I think the expectation here is that documents are opaque and therefore relations must be managed purely externally from the documents. This is one of the big differences to web applications where relations are directly related to documents.
Jon, CMIS does in fact have an event system, so the event based use cases are possible.
It's a great article and I see a lot of people who love the images.
But like julian mentioned, why do we need CMIS? Just because nobody understands WebDAV?
WebDAV already knows the concept of a “path”, that's why it is also used by WCMs and placed in the RFPs. (also described in one of the comments)
I think WebDAV is just missing one thing. A RI (reference implementation) with something like a TCK.
Last but not least I'm often have the feeling, that this is just a big marketing campaign, due the fact that the same vendors worked on JCR 1.0 and 2.0. The most of them started working on CMIS 1 1/2 year before the JCR 2.0 got finished and tattled on their community events about this standard. The most of them worked also on iECM. So why should a customer should trust this companies?
If we are not starting to pay attention what is already out there, we will lose the confidence of the one's we do this stuff for.
Daniel
I wish people would stop calling CMIS a “lowest common denominator”. That's quite a misuse of the term…
CMIS is actually the Greatest Common Factor between all participating vendors.
Florent,
So, I agree. I quote from Wikipedia: http://en.wikipedia.org/wiki/Lowest_common_denominator
“In common non-mathematical usage, the term “least common denominator” is often misused for the concept of the greatest common divisor.”
I've misued the term. CMIS is a Greatest Common Factor spec :-)
Hi Florent,
good point on the 'greatest common factor'…
(…quickly changing my stock cmis slides ;) )
regards,
david
When seeking the greatest common linguistic factor we work to balance precision with comprehension. In doing so one might just get stuck with the lowest common denominator. :)
Just some thoughts…
- Florent: Thank you.
- Justin, I'm aware of the repository relationships. It is the ones embedded within the document that are a problem. This has been an issue since DDE and OLE links back in the 90s, before HTML pages were composite. Unless the underlying system receives the content and establishes those relationships in the repository, there isn't much that CMIS, as a standard, could do. Doesn't mean someone's implementation couldn't do some of that behind the scenes or that my application couldn't figure that out and make multiple calls.
- David: Read the “exclusion” of WCM more closely. The phrase is “out of scope for the initial set of deliverables.” The reason is simple, if they tried to accommodate every use-case in version 1.0, we'd never get there. 1.0 is about getting it to support the greatest common factor in a timely manner. Reading and writing content to a browser is not, in my opinion, WCM. Your mashup concept, which could be leveraged into another binding, is interesting.
- Daniel: WebDAV is a protocol, but it doesn't really have much of a domain model. WebDAV might make a good 3rd binding for CMIS. Look into that. There are use cases where that would work better than the Restful AtomPub or Web Services bindings.
People need to remember, just because a standard, any standard, doesn't support a use-case doesn't mean that it is useless, missed the boat, or is too focused on a domain area. If we are still debating these same issues in 5 years around CMIS, then I'll concede the point, but as other standards out there have shown, the initial release is not the final point. JCR and WebDAV have evolved, and so shall CMIS.
-Pie
I think it would be helpful if people could point out what concretely is missing in WebDAV.
“it doesn't have a domain model” is a comment that's hard to respond to. Why does it need one? What problem is caused by not having one? Doesn't it really have one?
Once we get to specific things like “I want to expose metadata schemas/node types”, that's easier to deal with. WebDAV is an extensible system, and the best way to address missing features is by … adding them. Not coming up with a separate protocol.
So, I'd really like to hear some concrete feature requests.
Julian, the issues I have with webdav here are:
1. It is not very extensible. Properties are, ok, but you have documents, folders, collections, properties, and no generic extensibility to add more. CMIS is extensible much more generically in principle.
2. Please don't add anything else to webdav! It was not a good design to start with! Ok so it was an early attempt, but we have better HTTP modelling tools now, like Atom for example. See the WebDav Book of Why http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0339.html for some of the horrendous mistakes. It is time to freeze the webdav spec and move on.
3. You cannot say run a webdav repo in the same URL space as say the CMIS one, as they are effectively incompatible.
I really dont know why everyone likes it so much…
Justin,
1) where's CMIS more extensible? WebDAV inherits all HTTP extension points (methods, header fields, MIME types, link relations, whatnot), plus can use additional properties.
2) AtomPub is horrible for managing hierarchical storage, and for namespace operations (COPY, MOVE etc). We see the results in CMIS. It needed to define its own extensions for navigating the hierarchy, and it lacks namespace operations.
I agree that there are a few problems in how WebDAV works, but so far I haven't seen them causing a problem in practice.
3) Please elaborate on that.
Hi,
Thanks for this interesting article, and for all the interesting discussions following.
I would simply like to add my personal opinion to the thread:
1. About the advice “Please don't go adding CMIS as a requirement in your WCM”, i really think you are wrong here, or should be more precise in explaining your thoughts. There are use cases where a WCM installation will benefit from CMIS standard a lot. A case could be when you need to rely on CMIS as a client (it is not obvious reading you, if you meant this part of having “CMIS as a requirement”, in anyway implementing CMIS client capabilities might be simpler than server capabilities, it is not obvious and still might make sens in a requirement list. Another case could be that, while looking at a WCM, it might be that part of it, you handle some assets that can fit well in the CMIS fields and then it could be useful. I am thinking of documents attached to all modern WCM project (video, images, other documents) and this could by the way be very interesting considering User Generated Content on a WCM platform that you would like to leverage in another system.
2. As an immediate consequences, i don't think i share your definition of WCM, which seems to be very “HTML centric”. I don't think the mission of a WCM is to manage composite HTML pages, but to publish composite content to any web channel, the HTML being part of the channel. Modern WCM is/should not anymore be managing HTML as part of the Content itself but only as part of the Delivery !
3. About the very interesting (and unexpected for me) discussion about Webdav Vs Cmis. I am very happy to read this as it really make sens to look at those 2 standards from a common angle. I would be with Justin and some others that are having some issues with WebDAV. I might however not be able to dig into real technical or purely design aspects of it but simply, from the ground, looking at how WebDAV has been implemented by several system and applications vendors. I can only states that this standard is loosing a big part of its promises simply because it is not really reliable for those who expect it to be as simple as a remote file system interface, simply because the usual systems and apps out there in the market are really not implementing it properly and in a consistent way. Julian, you might have not seen personally WebDAV causing a problem in practice, i can insure it is, and on quite some projects of all kind !
Cheers,
Roland,
I agree that there are broken WebDAV servers and clients out there. There are probably many reasons for that, the lack of a RI, the lack of a *complete* test suite (Litmus is nice, but not sufficient), and the fact that many vendors only test with a certain client.
The right thing to do here is to fix what's broken, and to extend what needs to be extended, not to come up with something completely different.
That being said, I'd be interested to hear in detail about the problems you're seeing; but maybe not here, but over on the WebDAV mailing list… (http://lists.w3.org/Archives/Public/w3c-dist-auth/)
Hello, Jon Marks
You can add to that great picture the xCMIS project.