Liferay has a long history of participation in and implementation of various standards in web software over the years. Notably, Liferay has participated in development of JSR-286 (Portlet 2.0), JSR-314 (JSF 2.0), WSRP, and CMIS. Liferay is once again participating in a new standard called WEMI (Web Experience Management Interoperability).
The Technical Committee for WEMI had its first Face-to-Face meeting earlier this month in Copenhagen (big thanks to Sitecore who hosted all of us!), and I attended as a Liferay representative. You can read the meeting minutes here (thanks to Peeter from Adobe!). It's a bit of a departure from my ordinary duties as community manager, but as a long time user of Liferay's WCM (both UI and API), knowledge of our community's use of (and issues encountered in) Liferay, and with some experience in standards development, it is an interesting role to play for me. I had low expectations given it was the first meeting, the number of participants was large, and no agenda set for the meeting, but was pleasantly surprised by level of knowledge and experience of the group, our ability to stay focused on the getting work done, and the amount of agreement on basic problems.
The funny thing is, I believe that most if not all of the vendors present have already implemented much of what WEMI seeks to standardize, but in a proprietary way, so in that regard I believe it is a ripe area for standardization. Of course, the moment we all got in the same room, the scope and goals of the TC started to evolve, but that's not surprising either. I think the general consensus is that there is some meat to this (after all, if you thought the goals were bogus, you probably wouldn't participate), but in order to build interest and excitement, ensure broad adoption, and keep the TC engaged, we need first to declare some real world use cases for WEMI, useful problems that it can solve that cannot be solved today (through existing standards or existing tools), so we'll be working on those first. There are a couple that have been put on the table, such as site content indexing/archive/retrieval (especially across versions of a CMS, such as when upgrading Liferay), or providing additional context around content objects, for use by social engagement systems. Serge (Jahia) has an excellent pre- and post-writeup in this regard.
It's also important to keep it small and simple, while still providing real value in the first iteration. A 1.0 spec that simply sets the groundwork for 2.0 is a waste of time, because no one will stick around for 2.0 due to lack of adoption. So on that topic we all agreed as well. Also, as Boris (Magnolia) states, we mustn't make yet another "hierarchical nodes and data elements" standard -- we already have a couple of those, and it reminds me of this excellent XKCD comic:
WEMI must focus its efforts at a level above things like CMIS (in fact, WEMI started during CMIS development, where some participants felt it was missing several key parts to CMS interoperability) if it is to provide real value.
So, what's in it for Liferay?
Why would Liferay participate and implement such a standard? There are many reasons, but here are some:
- It's currently hard to programmatically aggregate and mashup content from Liferay for use in a browser or mobile device. Yes, you can use our JSON-friendly APIs to get at content, or our Java APIs, but you have to do a lot of groundwork to even get to the point where you can call the APIs and understand what you can do with it. This is one of the reasons we have things like the Asset Publisher (which does a lot of that groundwork for you) and the ability to export portlet content as widgets, neither of which give you programmatic access to the content and its associated metadata.
- While documentation is improving, it's still not close to 100%, so there are many APIs and domain models that have little or no documentation.
- Content archive/retrieval is done through import/export, but a) it's unusable across different versions of Liferay, and b) its format (LAR) is also mostly undocumented (though it's somewhat easy to infer its contents if you know a lot about Liferay's architecture), but in general only Liferay knows what to do with them.
- Liferay provides a lot of functionality wrapped around content (versioning, workflow, social, etc) but most of this is stripped out or opaque when accessing content through content APIs. You have to do a bunch of extra work to find this additional data and relate it to the content.
- Liferay customers often wish to aggregate web content from other systems, so having a good understanding of this up and coming standard will help us implement it faster.
A standard also forces implementers to adhere to the published, documented, (and in cases of a good standard) well-understood spec - and WEMI in particular (with its goal of simplicity and usefulness out of the gate) will define context and content metadata such that interesting content-centric functionality provided by vendors is exposed in a well known and consistent way.
Other Aspects
There were many other topics broached during the meeting, and I've included a few notable ones here:
- Since in general, reuse/recycling is a good thing in many aspects of life, the group also recognizes that there could be existing standards that could be co-opted for use by WEMI as building blocks (for example, semantic constructs from HTML5 such as
<article>, or build WEMI on top of OData and borrowing their querying capabilities) and more investigation is ongoing. - Content may appear to be arranged as a hierarchy when viewed in the context of a desktop website, but content served to a mobile device may have an entirely different organization. WEMI should allow for this.
- Serialization/representational formats/protocol bindings: Let's stick with formats friendly to the consumers we are targeting with WEMI: meaning, let's use JSON and HTML, not XML and/or SOAP.
- Access Control is specifically out of scope for WEMI (too complex, no least common denominator, etc), but the concept of contexts and personalization may prove useful. Contexts allow you to declare the purpose/destination of content during the retrieval/aggregation, so that even more aggregation work is done for you by the CMS.
In summary, I think this working group works well together, no one showed up and dropped a fully baked implementation and said "this is where we start", and I think we will make quick work of this and have something quite useful quite quickly. So, I am looking forward to getting into it!
