Last week I travelled to Copenhagen, Denmark to participate in the kick-off meeting for the Web Experience Management Interoperability (WEMI) technical committee (TC) which was recently formed by OASIS ( Organization for the Advancement of Structured Information Standards). OASIS is widely respected as a leading web standards consortium which drives the development, convergence and adoption of open standards for the global information society. OASIS is also the home of CMIS, a Content Management Interoperability Services standard that originated in 2009, which in fact served as the catalyst for the new WEMI initiative.
Where CMIS is focused on an open standard that defines an abstraction layer for controlling diverse document management systems and repositories using web protocols, WEMI is more focused on the exchange of unstructured content between web publishing systems. The name “Web Experience Management” was chosen purposely so that the standard is applicable to the broadest audience possible and is not specific to a specific web publishing system architecture, as this initiative is intended to be applicable to Content Management Systems (CMS), Web Content Management (WCM), Web Engagement Management (WEM), Portals, Site Builders, and many others. The founding members of the WEMI TC include many of the world’s leading authorities on web publishing including Magnolia, Acquia (Drupal), Hippo, Sitecore, SDL, Liferay, TYPO3, Jahia, TerminalFour, Adobe, Telerik, Enonic, GX Software, and of course, DotNetNuke.
The kick-off meeting occurred on April 3rd and was graciously hosted by Sitecore, which was one of the determining factors for the venue being located in Copenhagen ( Sitecore is based in Denmark ) - the other factor being the fact that 11 out of the 14 organizations represented are based in Europe. From a business model perspective, the TC is comprised of both traditional proprietary software vendors, as well as organizations acting as stewards of large open source projects. And from a technology perspective, 3 systems were based on .NET, 2 systems was based on PHP, and 9 systems were based on Java technology. The delegates sent by each organization generally had a strong technology background ( ie. CTO or Chief Architect ), some had experience in defining other web standards in the past, and some were even members of the CMIS initiative.
In its charter, WEMI has three general goals which were utilized to help guide the discussion:
- define a simple domain model and an abstract feature set to be commonly implemented by participating systems
- explicitly use existing systems as a point of reference but also be open to extensions that may be generally useful
- specify a default binding as a lightweight, resource-oriented, HTTP-based protocol
These goals were manifested in a very focused set of use cases:
- Display and Mashup Content from a WCM
- Index Content and Metadata
- Export all Content / Migration
And the charter also provided guidance which was intended to prevent dreaded scope creep. It accomplished this by spelling out the use cases which are considered to be out of scope for the initial set of deliverables:
- Entitlement and Access Control
- Versioning and Records Management
- Data Ingestion / Write operations
Depending on their specific needs, organizations seemed to favor some of the use cases more than others, but the thing which I found especially encouraging was that there appeared to be immediate consensus that all members were facing the same content challenges and were willing to collaborate to create a common framework for solving the problem. This made the initial meeting very productive in terms of keeping the discussion focused and moving in the same direction.
Another item which was encouraging was the fact that nobody in the group seemed to be afflicted with the Not-Invented-Here (NIH) syndrome – meaning everyone was fairly open to utilizing existing standard and protocols where they make sense. A case in point was a preference to utilize the work done in the W3C HTML5 specification for helping us define the domain model. Another observation I made during the discussions was that there appeared to be an opportunity of utilizing existing light-weight data protocols such as the Open Data Protocol (OData) or Google’s Data Protocol (GData) for inspiration and guidance.
Overall I thought that the trip was productive but exhausting. Between flights, airport layovers, train connections, and navigating the streets of Copenhagen, it took me almost 24 hours to travel from my home in Vancouver to my hotel in Copenhagen. Coupled with a 9 hour time zone differential, I was surprised but relieved to avoid any jet lag symptoms on the day of the actual meeting. And as is usually the case with these types of events, I found the conversations with the other members outside of the WEMI meeting to be equally as stimulating and valuable, as the meeting itself.