First thoughts after OASIS WEMI face to face meeting in Copenhagen

Yesterday was held the first face-to-face meeting of the OASIS WEMI technical committee, and I'd like to deliver here my first thoughts about what was achieved during this full day of intense brainstorming :)

The first thing to note was the amazing turnout of CMS/WCM/Portal open source and closed source vendors. Among the list were Jahia, Drupal, Adobe, Hippo, Magnolia, Liferay, Enonic, GX Software, SDL, many others (including an independent !) and of course not to forget Sitecore who was hosting the meeting and did a great job at that (thanks!)

The meeting actually had no agenda so it focused more on discovery of the expectations of the actors involved, the potential goals for the standard and the definition of the standard's objectives. I was assuming that because of the amount of vendors present it might be difficult to reach agreements on the initial first steps but much to my surprises consensuses were reached quite fast. It seems there is a strong demand for a standard in the area of web experience management and people were eager to get started to hopefully solve multiple problems spaces.

So what were the main areas of interest?

First the domain model definition was discussed, and while there was no expectation to fully define it in a day, it seemed quite clear that using basic nodes and properties was not semantically sufficient, so higher objects were explored. Among the objects described were pages and site maps, but it then became unclear how to describe finer grained objects. A good idea emerged to look at what HTML5 described in terms of new semantic objects: sections, articles, asides, and so on. It is of course much too early to tell if these will make it into the final specification but I think it gives a good idea of the direction we were going in. Also of notice is the fact that the group really liked the idea of reusing existing notions if they make sense for the new standard rather than re-inventing new concepts systematically. At some point even HTML micro formats were mentioned, and it seemed to be able to fulfill some interesting use cases so this will probably be revisited in the specification process.

The binding protocol was discussed next and here everybody agreed that it should be minimal and lightweight, possibly just using HTTP and JSON representations (with possible HTML renditions too). A strong focus here was to avoid making this layer too heavy to make it easy to implement.

The standard will also provide an open source reference implementation and test suite, maybe even contributed to the Apache Foundation, although again nothing is set in stone at this point so things might still change. Everyone agreed that code should be produced as early as possible, since it is really the best way to validate the standard's proposals.

During the day a query proposal was put forward and seemed to gather interest as a way to quickly access content using search options. Again a consensus seemed to go to a simple and feature limited system to make implementations easy.

The most interesting development, in my opinion of course, during the day concerned passing a context through the HTTP binding, for example in the form of a cookie or a parameter, to influence the retrieval of content in the WEMI producer. This mechanism would allow for personalization or other custom filtering of the retrieved content. Here it was quickly decided that it would be complex to address detailed use cases so it might end up just describing how an implementation might allow for context passing. Along the same lines authentication and authorization will not be specified as was described in the initial TC charter, but the new specification should not make it impossible for implementations to integrate their own mechanisms.

So at the end of the day what does the new WEMI standard look like? It will hopefully look like a good way to access, possibly query, index and export content from different information systems. To compare it to CMIS, it does not aim to be file (or document) specific, but should make it possible to make it easy to expose existing content to various WEMI consumers. WEMI consumers might range from applications running on application servers to JavaScript running inside a browser to a native mobile client, all this with little code since the focus is to use a simple HTTP and JSON binding. Who knows maybe WEMI could even become a new way to build JQuery-based (mobile) applications ?