The Road to WEMI

On Monday, January 16th, OASIS will organize the first conference call to elect a chair for the new Web Experience Management Interoperability (WEMI) Technical Committee (TC). This new TC was announced last November in the aim of defining a standard around the ideas of Web Experience Management (also known as WEM). The Web Experience Management Interoperability standard is both a mouthful and an ambitious goal, and I'd like, in this article, to talk a little about my views of why this standard is needed and what I hope it may become.

Ever since Tim Berners-Lee invented the Web at CERN, the idea of how to integrate complex and distant systems has been in the air. Actually for the old-timers, some of this can be traced back quite far, back to DCE or CORBA standard, where the idea of interacting with distant software was first introduced. The birth of the web brought a new interesting concept to remoting, the idea that what we actually want to publish and interact no longer with pure application logic but with content. Of course in those days it was a lot more about publishing than it was about interacting with content.

Let's fast-forward to today. We now have Facebook, Twitter, instant messaging, forums, comments on public web sites, and an awful amount of spam everywhere :) Yes, some of these improvements were good, and some of them make you waste time flagging inappropriate content manually. But basically the relationship to content has become a lot more powerful, and it is now not only a matter of publishing content it is also a matter of discussing it, sharing it, modifying it quickly and easily, and also tracking its usage and effectiveness. Web sites that used to be static are now becoming more and more dynamic, and users across the world are using social networks to create, share and discuss the content in real-time. For a web site manager, what was a relatively simple task of publishing static files has now become a challenging task of managing powerful content platforms.

There are probably a lot of definitions of Web Experience Management out there, but I think that seeing it from the viewpoint of the modern web site manager it becomes pretty clear what it involves, and what may be done to improve both his and his users' experiences. Usually a web site manager is not a developer, nor a content editor, nor even a marketing manager, but usually someone who interacts with all three roles to provide a nice web site. Web Content Management is therefore mostly renaming itself, Web Experience Management software, because it is evolving to address new needs for the new demands or expectations from users that constantly use highly dynamic and personalized web sites such as Facebook.

Now that we set the groundwork, let's see why we need another standard? And yes, why on earth would we want to go through all the trouble of defining yet another specification when we already have HTTP, REST, CMIS, WebDAV, JCR, and possibly many others (did you ever hear of OAI-ORE)? If you look at the real success of standards, it seems that usually the less complicated they are, the stronger their chance of success. For example the basic HTTP standard was pretty straightforward, and made it relatively easy to implement, so very quickly a lot of different implementations came together and were highly compatible, which was really important for interoperability. On the other side of the spectrum, a complex standard will cause difficulties in the implementation, and interoperability will possibly suffer. Some standards include "levels", or optional parts, to make it a bit easier to integrate the standard in existing or new software. But optional parts will also make it difficult to ensure strong interoperability between implementations. Every standard has had a different main focus, as such is also the case with the new WEMI proposal, which might focus on the dynamic user experience, and how systems may interact to customize the experience he will have with content coming from different sources.

A promising content standard, especially initially, was the Content Management Interoperability Standard (CMIS). What was very interesting in this effort is that it immediately had IBM and Microsoft on-board.

So where do we stand at this point? We need a good standard, we need it to be minimal, we need it to be simple to implement, we need to help build customized user experiences on web sites and we need open source implementations.

The WEMI initial proposal, initiated by David Nueschler at Adobe (formally Day Software), has the following use cases:

• Display and Mashup Content from a WCM
• Index Content and Metadata
• Export all Content / Migration

And the following deliverables:

• WEMI Abstract Domain model and feature set specification (September 2012)
• WEMI resource oriented HTTP binding specification (September 2012)

As you can see from the start a single binding has been defined and effort will be (hopefully) made to keep it simple. One way to think about this is to imagine client implementations in languages such as Javascript, or to imagine connecting native mobile clients such as iOS or Android devices to WEMI services. Using lots of XML for discovery or communication might not be ideal in such clients, and it would be a lot easier to work with proper resource HTTP binding such as true REST resources, exposing their structure using JSON, and possibly sending updates or parameters using standard HTTP methods and form data encoding.

In a more general manner, the standard will need to address use cases of web experience, that is to say to figure out how to use analytics, user data, context and other parameters to retrieve content that is relevant to the end user. So while it may not need to directly specify how these systems work, it will need to provide the basic infrastructure to implement such capabilities in a reusable way. You could for example imagine a way to provide metadata information such as subject, tags, population segment, geographic location to a WEMI service and it would send back relevant content based on those parameters. This way a site could query another site, using a possibly different implementation, for personalized data. In other words, the metadata access and sharing is a critical point of the WEMI standard to be able to build the "engagement" feature set.

At Jahia, we strongly believe that WEMI is an opportunity to help improve interoperability and web experience between content management systems, and we will of course be strong partisans of an open source implementation.