OASIS Open

The OpenDocument Foundation, Inc.

(B) Florian's proposal

Hi all,

I'm voting in favor of the Novell List Enhancement Proposal, and welcome this opportunity to explain my decision as well as comment on the process.

We arrive at this decision after months of trying to come to grips with what has been more often than not a confusing, contentious and shifting discussion with the values of application specific implementation needs deeply entangled with the broader values, objectives, purposes and responsibilities of the ODf specification.

That we stayed true to the consensus process and were able to evaluate “both” list enhancement proposals against the broader issues and expectations for the ODf specification is in itself a worthy achievement.

Critics of ODf are want to make claims that the ODf process is dominated by a single vendor. They claim loudly and often that ODf is application specific by design, and does not take into consideration real world issues such as compatibility with existing file formats and the need to accommodate application feature sets outside the features implemented by OpenOffice. They do this without evidence or substance, but with the deafening roar of a monopolist in control of most of the world's binary documents, and, the systems bound workgroup-workflow business processes represented by those documents.

And we are left the task of defending the ODF specification process.

Which is why i feel this vote has far more meaning than that of a decision between two list enhancement proposals. That we were able to reach this moment with our open consensus process prevailing and the great span of ODf objectives and the world's expectations becoming the measure for evaluating these fine proposals is the best defense of the ODf specification process we could ever offer.

In the long run, people will forget the issue of the list enhancement proposals themselves. What will be remembered is the defining proof of the open consensus process that shouts back at the deafening roar. At the end of the day, it is the open consensus driven process of ODf that stands as a guarantee to the world that the decision to put their information into our XML file format is the right thing to do.

While i do believe that the Sun/KOffice List Enhancement proposal is creative and uniquely innovative, i don't believe we get to go back to square one and re invent the wheel; no matter how appealing, tempting, or application benefiting that might be. These issue were easier way back when, but once ODf 1.0 was released to the public, enhancements and changes to the specification demand consideration of larger responsibilities and expectations. The problem becomes that of doing everything we can at the specification level to encourage and accommodate innovative application features and advances; and do so without compromising our legacy obligations.

My reasons for favoring the Novell List Enhancement proposal are based on the considerations provided for the following list of priorities:

* Clarify and enhance the ODf 1.0 list implementation model without compromising innovative implementations

* Maintain application specific independence
Design for compatibility with existing file formats (MS binaries, RTF, HTML, XHTML)

* Design for 100% round trip conversion fidelity with MS binaries and MS OfficeOpenXmL

* Design for backwards compatibility (ODf 1.0, 1.1)

* Design for multi platform application interoperability and document exchange

No doubt these are difficult constraints to work within, but i think Novell has done an outstanding job.

Either way, i have to say that these are good proposals. In the long run though, the most important statement we've made is that during the list proposal process, we took into consideration such a wide ranging set of expectations and design objectives. One of the most interesting exercises the proposals were walked through was that of the Comparative Evaluation of Proposals based on Requirements. Regardless of whichever list proposal the technical committee decides, on, the Comparative Evaluation document is an important contribution to the public discussions concerning the ODf – MOOXML controversy. One which the critics of OpenDocument will have a hard time spinning.

There is one last point about continuity that i would like to comment on. During the often contentious list enhancement proposal discussions, more than a few comments were made that left me wondering about the validity of requirements and concerns i felt were important. Requirements and concerns like the above list. The discussions were filled with with conversation ending platitudes like, “that's out of scope”, “that's out of bounds”, “that's not our problem, let the converters deal with that”, and “it's the translators problem, let them figure it out”.

I patiently listened to these arguments, trying to figure out what it is the application specific developers were really seeking. Asking myself, as so many other on the TC did, why it is that the developers cannot reach consensus and come up with a single proposal they agree on?

Novell of course has a very different problem set to solve than that laid out by Sun and KOffice. They are involved in the Microsoft-CleverAge Translator Project. Backwards compatibility, round trip fidelity, compatibility with existing file formats are primary concerns for them.

For me, these concerns are well within the historical and continuous context of the work we do on the ODf specification. In fact, my check list of dream requirements goes beyond Novell's concerns.

So i wonder where it is i'm out of touch? To me these issue are part of our continuity and worthy of consideration. And i'm most grateful that through the leadership of Michael Brauer, the TC came to discuss and thrash these issues within the full context of that continuity.

Still, i want to explain how i see things.

I'm one of the three members of this TC that has served since that first meeting in December of 2002. If there's a sense of continuity, Michael, Patrick and myself own the responsibility of bringing this sense to future generations of TC participants. I'll be brief :)

IMHO, there have been three distinct phases of ODf development. Each phase has been marked by different membership groups sharing similar goals, objectives and concerns. Being different in terms of participants, concerns and objectives, each phase has had it's own struggle with that continuity of purpose the public expects.

The first phase of ISO/OASIS ODf development began of course with that first group that met in December of 2002. Some interesting things happened at that first meeting that, looking back, actually define the entire participation era of that first group. That group shared a concern about the need for a migration bridge between existing documents and information processes, and ODf XML.

Our critics are fond of saying that that the reason they had to develop MOOXML is that OpenDocument was not designed or intended to be compatible with existing file formats – the infamous “billions of binary documents needing conversion to XML” problem. Yet at that first meeting, a proposal was made by Stellent's Phil Boutros to include in the charter the express objective of “compatibility with existing file formats”.

Further discussion revealed that Phil's proposal had the overwhelming support of the many members with an interest in enterprise publication, content and archive management systems. This included Boeing, ArborText, Documentum, Corel, SpeedLegal, and the Australian National Archives representatives.

While the proposal was never brought to a vote, the specification work that took place during the next 15 months was marked by the primacy and importance of this concern. The result is that ODf 1.0 is incredibly flexible. So much so that today we can refute the allegations our critics are want to make, and say that ODf can handle anything MSOffice and the legacy billions of binary documents can throw at it. ODf is fully compatible with “the existing file formats” in question. And can even scale out to handle the legendary MSOffice development layer where business processes, line of business apps and assistive technology add-ons have extended MSOffice feature sets.

The flexibility of ODf is extreme, and we owe it to this first phase group that saw the need, and responded with an innovation wonder. Overwhelmingly those early members represented interests outside the focus of those with a direct interest in the desktop office suite – desktop productivity environment area. The office suite contingent was in fact a distinct minority. Document processing and enterprise publication, content and archive management systems were the dominant voices during phase one. With great foresight they provisioned ODf exactly for a public battle and raging controversy that would be years in the making, but is now upon us.

The second phase of ODf was one where a comparative handful of participants prepared and saw ODf through the completion of both the OASIS and the ISO submission and approvals. (The ISO preparation work actually took place before ODf was submitted to OASIS membership for approval).

What really marked the second phase work however were the requests from the European Union, and the rapid response their concerns received. They asked us to change our name from OpenOfficeXML to something more agreeable to Microsoft. We did. Now Microsoft has the name OfficeOpenXML. They asked us for XForms, SVG and SMiL. Done. The legendary Daniel Volgelheim pulled off one of the most spectacular developer feats i've ever witnessed, delivering a complete application interface within 45 days of the request. The asked us to submit the newly christened ODf to ISO. And the most intensive editorial re write imaginable began without hesitation.

My point here is that when the real world asked us to jump, the second phase ODf TC responded immediately with “how high”. There was no hesitation or discussion about scope and bounds and whose problem this should be. The only question asked was, “what's the best way of getting this done?” And this was at a time when two people calling in more often than not constituted a quorum.

With the ratification of ODf 1.0, phase three began as a slew of new members joined the effort. This is a ride that continues to this day, and is very much defined by this list proposal discussion and the way it blossomed into a full consideration of our purpose as it is intertwined with the expectations the world has set for ODf.

IMHO, phase three will culminate in the ratification of ODf 1.2. The work that is now taking place in the three sub committees will become the lasting mark this group will leave on ODf. Accessibility, Open Formula and Metadata RDF/XML sub committees will change forever the issues of application interoperability. There is no doubt in my ind that this effort is so far reaching and dramatic a leap for ODf flexibility, that the way people think about XML will itself be changed.

No doubt my brevity does an injustice to the volumes of hard work and innovation that took place during these three phases, but i think the point is nevertheless made. There is a continuity of purpose and intent that demands consideration as we push forward.

Phase one work was very concerned about building that bridge to existing documents, information systems, and business processes; fully provisioning the migration demands of moving the world's legacy documents and business processes into ODf XML.

Phase two work was all about responding with immediacy to real world needs.

Phase three is all about chasing down the holy grail of application interoperability, which sits like a giant umbrella over all previous issues. Is it possible to rush ODf documents through unknown document processing chains, where applications of all sorts will work the information and route it on to the application service that an embedded intelligence says is next? And do this preserving perfectly the “content” along many variations of document presentations, all of which are correct under certain circumstances? I say yes. But it will take years of market uptake and developer innovation before we see the full blossom of the ODf 1.2 promise. Nevertheless, the promise is there. And there in spades.

No matter the outcome of this vote on list proposals, this is a great moment for us. The essential reasons why the world can and should trust their information to ODf took over this process and prevailed. We are worthy of the trust that has been placed upon ODf, and this list proposal process proves it.

+1 the ODf consensus process. No matter how contentious, impassioned and difficult it might get.

Thanks to all for your incredible contributions and dedication to the best interests of mankind.
~ge~