CMSWire has a nice article briefly explaining CMIS. At this stage of the standards process, this level of understanding of CMIS is probably sufficient for most – especially if you are working in web content management.
Archive for the ‘standards’ Category
CMIS in brief
Thursday, November 6th, 2008ISO adopts OOXML format as international standard
Wednesday, April 2nd, 2008CMSWire’s Brice Dunwoodie passed me this InfoWorld article about ISO’s adoption of OOXML.
Contrary to what you would expect from me, I actually think this is a good thing. Microsoft Office is the de facto standard. Being a de jure, official standard doesn’t help OpenDocument if when you send an open document file to anyone they say that they can’t open it. Ideally, Microsoft would have adopted OpenDocument but that wasn’t to happen. The next best thing is for MS to adhere to their OOXML standard and alternative office suites support it. That Microsoft originated the standard doesn’t mean that they will be the only one to benefit from it going forward. Just look at Sun and Java.
While I don’t think the world loses with this move, OpenOffice (Sun in particular) and OASIS certainly took blows. OpenOffice can quickly recover by building in support for OOXML. The format should be easier to support than having to reverse engineer prior Microsoft formats. OASIS gets injured because it shows the limitation of de jure standard against a de facto standard.
The EU’s "Interactive Knowledge" project
Tuesday, March 18th, 2008Today Sandro Groganz blogged an announcement of a new initiative by the European Union called the “Interactive Knowledge” project. The goal of the project is to promote the latest web standards like CSS3 and RDF (semantic web). They intend to do this by giving out grants to small CMS vendors and adopters to support these standards.
This program could have a huge impact on those open source projects that focus on standards and bringing the web to the next level. In Dries Buytaert’s Drupalcon keynote, he made specific reference to how RDF can give Drupal the opportunity “to build a graph that connects everything” (see my notes). There are number of open source projects that are already walking the walk when it comes to standards: Plone (WCAG), Alfresco (JSR 170), Hippo (WebDAV and soon JSR 170), and Jahia (JSR 168) all place a high value on supporting standards. Some commercial vendors like Day Software have also made huge contributions in developing standards but it is less common for them to take the lead and drive (like Day has).
Waiting for customers of commercial CMS products to demand RDF has not broken the chicken and egg impasse that holds back widespread adoption of these technologies. There is no pressure to implement RDF and microformats if no one is using browsers and services that leverage this information. No one develops technologies to leverage this information if it is not widely available. Targeting smaller CMS products with money that is meaningful to them seems like a good way to seed the long tail of the Internet with a movement that will get the interest of the larger players. Remember, the big CMS vendors were the last ones to get RSS.
If you are interested, please send an email to Wolfgang Maass (wolfgang dot maass at hs-furtwangen dot de) no later than this Thursday, March 20th, 2008. A little more lead time would have helped but I am sure that if you contact him with your interest, you can get your foot in the door.
iECM: Interoperable Enterprise Content Management
Monday, December 19th, 2005iECM is a new standard being developed through AIIM – the organization that developed the first definition of ECM. The goal is to define a standard or set of standards to allow different Enterprise Content Management software to be able to work together in a heterogeneous environment. As you would expect, if you have been reading this blog, I am very hopeful for this standard. Such a standard would move ECM from a “one CMS to rule all” vision to a more practical distributed environment where different system are connected.
Based on this, you can understand the concern that my experience with the registration process raised. After looking at the iECM Blog and seeing nothing, I figured I should register to the mailing list to see what is going on. And that is where the trouble began.
It turns out that, in order to register, you need to fill out a PDF form. I run Fedora Core 4 and the default PDF viewer is Evince. In Evince, it looked like you were supposed to print out the form, fill it out in ink, then send it in. Not seeing a mail address, or a place to sign (why else would they require a mail form?), I knew something was up. I figured it was an active PDF form after working with them on a project for a big insurance company that needed this technology for some sort of compliance.
So I downloaded and installed the Adobe Acrobat Viewer. Using the Adobe Viewer, I saw a submit button! But my hassle was not over. After I filled out the form and hit submit, I got a pop-up asking me to select my mail client. Thunderbird was not on the list. I had to save a file locally and then attach it to an email to the address on the pop-up (copying and pasting the address and subject was not enabled).
This is not my idea of interoperability. Interoperability would be to use a standard HTML web form, not a proprietary file format and a proprietary viewer. If it had to be an Adobe technology, they could have used Macromedia’s ColdFusion or JRun and Java. This also hints that this group is really oriented to document management and not web content management. I am still hopeful that this standard can bear some fruit and become meaningful in the content management industry, but this experience was discouraging
JCR: More than just Java
Monday, October 24th, 2005If you have been intrigued by the The JCR but feel left out because you are not a Java shop, you might be interested to know that other technologies are getting in the game as well. Henri Bergius, of the Midgard CMS has started working on making Midgard accessible to a JCR via JNI (the Java Native Interface which allows you to execute native, non-java, code from a Java application). There has also been talk about a PHP-170 project to implement a JSR 170 compliant repository in PHP although no code has been submitted.
More recently, Stefane Fermigier has written about an attempt to hook Zope into a JCR by using JPype, a Java-Python bridge. In this blog entry, Stefane makes a good case that the structure of the JCR is very similar to the ZODB because both are node based rather than relational (as in a relational database). Having JCR storage option this would address a common issue with Zope which is that the ZODB is closed and difficult to manage in extreme conditions. My current client has a ZODB which is over 45 GB (That is just text. Images are stored outside.) and is growing at a rate of 2 GB per month (packed). We are working on a prototype to store content in a relational database to get around that limitation. In the elevator, I ran into a former co-worker who works for another company upstairs and they are doing the exact same thing. The ZODB is enticingly easy to build applications on and, in most cases, more than sufficient. However, in extreme cases, alternatives, especially standards compliant ones, are nice to have.
JSR 170 Approved
Friday, June 24th, 2005I was catching up on my Gilbane reading and noticed an announcement that JSR 170, the specification for the Java Content Repository (JCR), has finally been approved. Thanks and congratulations to Day Software’s David Nuescheler and the Apache Jackrabbit Team for pushing the JCR through this arduous process.
This news could not come at a better time for CMS owners and buyers who must be concerned with this latest round of M & A. The JCR will allow organizations to store their content in a standards compliant repository that will enable greater flexibility in the tools they use to manage their content. Now all we have to do is wait for a critical mass of CMS providers to support the JCR. The open source world is clearly in the lead with Apache JackRabbit, the JCR reference implementation and several open source CMS are using it. Day Software has a JSR 170 compliant JCR in Beta. Expect IBM to be the next company to release a commmercial JCR. Oracle appears to be dragging their feet and blew an opportunity to integrate JCR support into their new ECM product or their database.