Alfresco Software announced that it has included the OASIS Content Management Interoperability Services (CMIS) Version 1.0 in Alfresco Community 3.2 to enable developers and organizations to participate in the public review process. The OASIS CMIS Technical Committee (TC) has recently approved CMIS Version 1.0 as a Committee Draft and announced the start of a two month public review period. The objective of the CMIS specification is to deliver a common REST or Web Services API that can be used to develop write-once, run-anywhere, next generation content and social applications. The CMIS specification is backed by vendors including Alfresco, Adobe Systems, EMC, IBM, Microsoft, OpenText, Oracle and SAP. As an OASIS TC member, Alfresco is able to offer an implementation of CMIS for developers who wish to participate in the public review process. The public review ends December 22, 2009. The OASIS TC has issued an open invitation to comment and strongly encourage feedback from potential users and developers. CMIS 1.0 Public Review can be downloaded with Alfresco Community 3.2 at: http://wiki.alfresco.com/wiki/Download_Community_Edition.
OASIS announced that its members have approved version 1.1 of the Open Document Format for Office Applications (OpenDocument) as an OASIS Standard, a status that signifies the highest level of ratification. The result of a collaboration between advocacy groups for the disabled and open source and commercial software vendors, this new version of the standard provides key accessibility enhancements to ensure that the OpenDocument format (ODF) addresses the needs of people with disabilities. OpenDocument 1.1 supports users who have low or no vision or who suffer from cognitive impairments. The standard not only provides short alternative descriptive text for document elements such as hyperlinks, drawing objects and image map hot spots, it also offers lengthy descriptions for the same objects should additional help be needed. Other OpenDocument accessibility features include the preservation of structural semantics imported from other file formats, such as headings in tables, and associations between drawings and their captions. The new version of OpenDocument reflects the work of the OASIS OpenDocument Accessibility Subcommittee, which is made up of accessibility experts from IBM, the Institute for Community Inclusion (ICI), RNIB, Sun Microsystems, and others. The Subcommittee’s recommendations were incorporated into the OpenDocument specification by members of the OASIS OpenDocument Technical Committee, which includes representatives from Adobe Systems, IBM, Intel, Novell, Sun Microsystems, and others. http://www.oasis-open.org/committees/office/, http://www.oasis-open.org
W3C and OASIS have published WebCGM 2.0, a new industry standard for technical illustrations in electronic documents. WebCGM, which is widely deployed in the defense, aviation, architecture, and transportation industries, has reached new levels of interoperability thanks to this joint effort between OASIS and W3C. Computer Graphics Metafile, or CGM, is an ISO standard for a tree-structured, binary graphics format that has been adopted especially by the technical industries (defense, aviation, transportation, etc) for technical illustration in electronic documents. As the Web emerged as the environment for sharing and creating documents, it became apparent that the best way to use CGM on the Web needed to be clarified, particularly for interactivity such as hyperlinks and hotspots. WebCGM 2.0 adds a DOM (API) specification for programmatic access to WebCGM objects, and a specification of an XML Companion File (XCF) architecture, for externalization of non-graphical metadata. WebCGM 2.0 also builds upon and extends the graphical and intelligent content of WebCGM 1.0. The design criteria for WebCGM aim at a balance between graphical expressive power on the one hand, and simplicity and implementability on the other. A small but powerful set of standardized metadata elements supports the functionalities of hyperlinking and document navigation, picture structuring and layering, and enabling search and query of WebCGM picture content. http://www.oasis-open.org, http://www.w3.org/
As a former glue person, I spent numerous hours trading acronyms and definitions with IT analysts on the subject of data and process modeling in the content versus data worlds. Circa 1999, my friend Bob Boeri and I even went so far as to relate logical data models and data dictionaries to DTD structures, using Near and Far Designer as analogous to the more entrenched data modeling tools.
Our goal was to create “common ground” between IT’s deep but solely data-centric view of business applications and the needs of various business units whose focus was decidedly document-centric. Once our “data is content and content is data” analogy was mantra, we had an easier time with subsequent process modeling discussions; i.e. “what we want our content to do with your data” and vica versa. (Reminiscent of those “how did your chocolate get into my peanut butter commercials”)
In the ECM and BPM intersection, those discussions are once again becoming commonplace as more and more complex business processes require hybrid combinations of unstructured content, structured XML content and traditional data from back-end systems. Hence, information analysts that work with IT and business units must define a common knowledge base of process modeling requirements, flows, and techniques.
More than simple workflow (a.k.a “create, edit, approve, publish”), process models for functions such as compliance, claims processing, and contract management need to combine data-centric techniques with the content-centric, human-driven interactions these functions require. In fact, just as data sources are now hybrids, so too are the processes that require, manipulate, and share them. The BPM suite market is increasingly adding simple document management functionality at the business monitoring level to account for content-centric requirements.
More interesting is the market’s approach to workflow, which still appears either data-centric or document/content-centric in terms of standards modeling languages. In fact, a BPM suite vendor’s architecture choice for process modeling and execution is also a clue to their data versus content strengths via support for XPDL (XML Process Definition Language) versus BPEL (Business Process Execution Language). Highlights:
- XPDL – initiated and managed by the Workflow Management Coalition (WfMC), XPDL is decidedly human workflow-centric and more oriented for document-driven processes. No surprise that workflow, document management pure-plays, and some ECM players with BPM modules have strong XPDL modeling and processing engines. More info at
- BPEL – originally submitted to OASIS from IBM, Microsoft and BEA, BPEL is decidedly data-centric and more oriented for straight-through processing. No surprise that platform and middleware vendors entering the BPM suite market have strong BPEL modeling and processing engines. More info at BPELSource and
- OASIS One of the more significant questions at the ECM and BPM intersection is, “Where is the best of both worlds in terms of process modeling for complex workflow that is a human and data-driven hybrid?”
Jon Udell wrote yesterday that we should really be getting beyond the office document format debate swirling around the Massachusetts decision, because all heavy footprint authoring applications are headed for oblivion in our increasingly net-software-as-service world. (David Berlind also weighs in on the death of fat clients apps.) Tim Bray is skeptical because “… authoring software is hard.” While my view of the ODF debate is much closer to Jon’s than Tim’s, I agree with Tim’s caution here. While my coding skills were never in the league of either of these guys I have spent a lot of time working on authoring software, and more importantly, collecting requirements from users. Admittedly this was well before the Web existed, but what hasn’t changed one bit, is the need for authoring software to meet a staggering array of complex user requirements. Authoring software has to be flexible and extendable to meet the always unanticipated user needs. Authoring software is hard, and differing formatting and integration requirements will keep it that way.
Note that extending software functionality is not unrelated to extending the encoding of the content, which reminds me that…
Ironically, the reason I agree with Tim here is exactly why I disagree with the ODF decision: extensibility should be the first requirement of a government decision on an open document standard, and ODF looks uncomfortably like a limited implementation. From a practical point of view, scope is critical, but as Jon says, “In theory, governments should mandate standards, not implementations.” Perhaps the way to think about it is that governments should mandate standards (XML) but adopt implementations (form OASIS and Microsoft and perhaps others). Realistically there will be multiple versions (implementations) of each anyway, so a single implementation will never be enough.