Curated for content, computing, and digital experience professionals

Tag: OASIS (Page 1 of 2)

Alfresco Releases OASIS CMIS 1.0 Public Review Implementation

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:

OASIS Updates ODF to Version 1.1

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.,

W3C and OASIS Jointly Issue WebCGM 2.0

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.,

The ECM and BPM Intersection: Defining “More Than Simple” Workflow

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?”

Office Documents and eXtensibility

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.

Open Document Formats, Religion & Democracy

Two of the topics in the title are things we normally don’t touch in this blog. However, the tempest over Massachusetts’s OpenDocumentFormat decision is inflaming passions almost as much as religious and political issues do. In fact, I am writing about it because I woke up irritated at how ill-informed and irrelevant so much of the discussion about the state’s decision is. (Not a good way to start a blog entry!) I promised myself not to go on for more than the length of a reasonable blog-entry, so rather than dig into all the weeds, here is a short history lesson to bring out the big picture, and hopefully keep the debate focused on the real issue for Massachusetts’s and others contemplating similar decisions.

When we (in the standards community) debated open document standards 20 years ago, there was a religious and political fervor fueling the arguments of both sides. Our side (the SGML side, which included Tim Bray and Jean Paoli, now the chief XML people at Sun and Microsoft respectively), argued that nobody’s content should be held hostage by being stuck in a vendor’s proprietary format, and that the solution was a standard set of rules for describing whatever kind format was necessary that vendors were free to implement. The other side (the ODA “Office Document Architecture” side) agreed with that, however they thought the solution was for a bunch of vendors to get together and agree on a format that, instead of being proprietary to a single vendor, was proprietary to a self-defined group of vendors. This solution was even worse than the status quo for lots of reasons (lowest common denominator functionality, enhancements by slow international committee, unhealthy cabal-like motivations, …). At the time I thought of ODA as the soviet approach, and the SGML approach as the democratic approach. Fortunately, the SGML approach won, and that set in motion the developments that have given us XML today.

You can tell where I am going with this. But there is one more relevant aspect of this history to mention. One of the main arguments behind ODA was that the SGML approach was just too difficult to implement. They had a point, you have to pay for the freedom of flexibility. Their mistake was thinking there was an alternative that could anticipate all reasonable requirements. It can cost even more when you just can’t implement what you need to.

The situation today is a little different, but the need for organizations to be able to do whatever they want with their own content is exactly the same. The imposition of any single schema/format on all documents in any organization simply won’t work. Anybody who has been involved in helping organizations build IT applications knows that exceptions are the rule, and you can’t legislate them out of existence even in authoritarian corporate environments. A good decision for the state would be to simply require all documents to conform to one of a number of publicly documented and freely available XML Schemas – who cares what software did or did not create the content or did or did not design the schema? Certainly there are some complex details to work out, but there is no mystery.

We have had debates on this topic at our Boston conference last year and in San Francisco in the Spring, where there was more agreement than disagreement between Microsoft (Jean) and Sun (Tim) and the issues raised were refreshingly free from politics. It’s too bad we didn’t record it.

There is plenty of coverage on this topic. We have more comments and pointers, but also see Jon Udell and David Berlind.

OASIS Approves DITA as Standard

OASIS announced that its members have approved the Darwin Information Typing Architecture (DITA) version 1.0 as an OASIS Standard. DITA defines an XML architecture for designing, writing, managing, and publishing many kinds of information in print and on the Web. DITA consists of a set of design principles for creating “information-typed” modules at a topic level. DITA enables organizations to deliver content as closely as possible to the point-of-use, making it ideal for applications such as integrated help systems, web sites, and how-to instruction pages. DITA’s topic-oriented content can be used to exploit new features or delivery channels as they become available. Participation in the OASIS DITA Technical Committee remains open. All those interested in advancing this work, including users, XML tools vendors, and consultants on Information Architecture and Content Management Systems (CMS), are encouraged to join the Committee. OASIS hosts an open mail list for public comment and the dita-user mailing list for exchanging information on implementing the standard.

OASIS DITA Technical Committee Seeks your Input

Passing this along from Don Day, Chair of the OASIS DITA Techical Committee:

The OASIS DITA Technical Committee seeks your input on the list of known requirements/enhancements for upcoming DITA TC activity. Your help in ranking this list (or suggesting additional new requirements) will help the TC prioritize the most urgent issues for upcoming DITA 1.1 design work, and beyond. I have posted a list osf the issues currently known to the TC at this location:

Please assess what you consider to be your top 5 requirements and submit those Issue numbers to the DITA TC via the comment form: .
If you have a new issue or requirement not included in this list, please enter it as a separate comment via the comment form. We still need your “top 5” from this list, so read it carefully–most of the known hot issues are in there in one way or another, possibly including yours. There is no need to include more than 5 items in your list at this time; all of the 48 items are candidates for work, but we need to know which are MOST critical for initial work going into DITA 1.1.

This review period opens on May 23 2005 and closes end of day on June 6 2005 (2 weeks).

« Older posts

© 2020 The Gilbane Advisor

Theme by Anders NorenUp ↑