This was the first face-to-face meeting of the standard's sponsors, so do not expect anything that you read here or elsewhere to be more than an indication of where things might be going. Nevertheless I think it is worth sharing some notes about the event.
Let me start by saying that I had a great time in Copenhagen. It is a lovely city, the hotel recommendation (Hotel Guldsmeden Axel) was excellent. Philipp and I arrived on Monday and after checking in started with a healthy meal of Danish specialities including varieties of Herring, which were excellent. Thusly refreshed, we explored a bit of the city until we met up with the other early arrivers for drinks and dinner.
Meeting my peers from companies like Acquia, SDL, Typo3, TerminalFour, Enonic, Liferay, DotNetNuke, Adobe, GX Software, Jahia, Hippo, and Sitecore resulted in highly enjoyable discussions. It is rare to get so many of us into one room – we counted more than 20 – and we half-jokingly pondered upon the chance of a major disaster wiping out half or our industry.
On Tuesday morning Cédric Hüsler (Adobe) opened the discussion of what WEMI could become. As initial goals/use cases he proposed:
- display and mashup content
- index content and meta data
- export all content
- entitlement, access control
- versioning, records management
- data ingestion, write operations
Many discussions centered around what problem we really wish/need to solve and how WEMI differs from existing standards (or indeed if such standards exist). It is clear that more work will be needed to sharpen our focus of what WEMI can provide that does not already exist. All of the suggested use cases seem to have at least partial solutions already, so we have to be very clear where WEMI can add value.
For example, Jay (Acquia) suggested to add a query mechanism to WEMI, an idea I really like. This would be especially useful for mashup's. A look at Open Data revealed that much work in that realm has been done and we could benefit from it. Where could WEMI add value?
We agreed that the standard should be minimal in scope and as simple as possible. And we want to provide an implementation that can easily be adopted by non-CMS's as well. The logic behind this is that we see a big benefit in solving the use case of mashing up information from products that are not a CMS, e.g. a PIM. In other words, what WEMI aims to solve is not so much the mashup between compliant CMS's but rather to get others to be compliant to the CMS world. This way, WEMI-compliant CMS's can easily integrate third-party system's output. This plays right into Magnolia's understanding of virtual presence management, so investing into WEMI from Magnolia's perspective makes sense.
There is potential of WEMI becoming really useful, even sexy. I believe that a good first step will be to flesh out the use cases and write user stories to see what could become of WEMI once defined and implemented. This would make it easier to get others on board, especially "third-party systems".
For example imagine a product that would take an inventory of all images that are used on all the websites of a company. This could be useful to enforce branding guidelines. To achieve this (and given that all systems understand WEMI), WEMI would need to provide a way to ask for specific item types.
This means we need to discuss the level of semantics WEMI understands. One one end WEMI could be quite abstract using nodes and data elements. However, my feeling is that we should indeed define things we might be interested in, e.g. folders, images, videos or even articles (as in "newspaper article"). This idea was broadly supported by Thomas (Enonic).
My final thoughts on this first meeting are that we need to define inspiring use cases that show what could be achieved with WEMI that is costly or hard to do with todays means. This would allow us to get more people excited and to increase the chances of a rapid adoption of the standard once defined.