Group items tagged

It was a performance that saw Hovsepian call Microsoft a reality the community must work with

Skimming over the details of Microsoft's support, Hovespian said such deals are critical if Linux is going to give customers running mixed environments what they need, by delivering interoperability in the data center and on the desktop.

Most (quality) specifications provide clear instructions using those magic words SHALL, SHALL NOT, and MAY where those words have a defined meaning for an implementor. Paragraphs are clearly identified as either normative or informative. That way an implementor knows what they must and may implement to claim conformance against a specification. This approach has been well established over time as a sensible way for spec writers and implementors to work

Most (quality) specifications provide clear instructions using those magic words SHALL, SHALL NOT, and MAY where those words have a defined meaning for an implementor. Paragraphs are clearly identified as either normative or informative. That way an implementor knows what they must and may implement to claim conformance against a specification. This approach has been well established over time as a sensible way for spec writers and implementors to work That is the way quality specifications are written. For example, ISO/IEC's JTC 1 Directives (link to PDF) requires that international standards designed for interoperability "specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." With that clarity, conformance is testable and can provide confidence of interoperability. A suite of tests may be developed and applied to an implementation to determine which tests pass, which fail, and hence arrive at an objective pronouncement on conformance of an implementation against the entirety of the specification.

In a quality specification, it should be feasible to select a normative paragraph, identify a conformance test for it, and make a clear statement that this test proves that an implementation meets (or fails to meet) that requirement. Call it a test plan: define the tests (test specification), define the expected set of results, and define what constitutes a "pass" of each test that establishes conformance. The plan then provides the matrix of test spec against requirement. Simple.

Fine; I hope that you also will specify the citation metadata then. Using unspecified metadata for *relevant* parts of the document in OOo can be the starting signal to kill ODF. I'm not sure if citation data is a "relevant part of the document" but without further investigation I assume it to be that.

I had read the essay by Jon Bosak (SUN Microsystems) on why SUN voted as it did in the US. He lays out a very different strategy. His view is that the battle is lost to completely reject OOXML as an ISO standard. ISO can only reject it with comments, and that is equivalent to giving Microsoft a todo-list on how to fix the draft so as to get it approved. Microsoft has sufficient manpower to easily tackle that. Most of us had missed what Mr. Bosak saw: OOXML promises interoperability with earlier closed binary formats (the Word Doc, older Excel file formats etc.). But it doesn’t deliver. How on earth could someone be able to convert old binary files to the new format without having the specification of the old formats and a mapping to OOXML. If you are to translate some text from Chinese to English, it doesn’t much help to only know English.

“Ah c’mon Bosak, you are chickening out, we must stop this dead in the track”

+1 gary.edwards - 11/16/07 Thanks for the consideration Anton. You might want to follow an emerging discussion now taking place at the OpenDocument Fellowship: Interop between multiple standards and multiple applications Check on the follow up post and understand that this is the same problem the da Vinci group tried to overcome in Massachusetts, when ODF hung by a thread in the summer of 2006; with the sole hope being a plug-in conversion process capable of very high "round trip" fidelity. To assist Massachusetts and the da Vinci Group, the OpenDocument Foundation introduced to the OASIS ODF TC a series of discussions and proposals collectively known as the ODF iX interoperability enhancements. A total of six comprehensive iX enhancements were introduced between July of 2006 and March of 2007. The first three sets of iX enhancements were signed off on by CIO Louis Gutierrez, with the full knowledge and awareness of IBM (they participated directly in those discussions and i do have the emails and conference schedules to verify this . Also, if you're interested in other issues surrounding the da Vinci groups use of CDF WICD Full as an in-process conversion target for MSOffice documents, there is a series of recent responses posted in the comments section of this blog, "Going to Bed (without my supper). One last note; I do have a response to AlphaDog sitting in the blog que, where i try to put the MSOffice to CDF WICD Full conversion, and the OpenOffice ODF to CDF WICD Full conversion into the larger context of the web platform and universal interoperability. This post will also briefly explain the events immediately preceding the decision to shut the Foundation down. Hope this helps, ~ge~

'A diversion from the real end game – the taking of the internet' Gary Edwards of the Open Document Foundation has a fascinating post on the important of Microsoft Office compatibility to the success of the ISO-approved Open Document formats. It is in places a rare voice of sanity: People continue to insist that if only Microsoft would implement ODF natively in MSOffice, we could all hop on down the yellow brick road, hand in hand, singing kumbaya to beat the band. Sadly, life doesn’t work that way. Wish it did. Sure, Microsoft could implement ODF - but only with the addition of application specific extensions to the current ODF specification … Sun has already made it clear at the OASIS ODF TC that they are not going to compromise (or degrade) the new and innovative features and implementation model of OpenOffice just to be compatible with the existing 550 million MSOffice desktops.

Oh, my. Both IBM and Sun voted for the proposal that broke the Foundation's plugin that was going to add full-fidelity native ODF file support to Microsoft Office. So it's sounding to me like at least two of the TC members who voted for the Sun/KOffice proposal didn't check in with the ECIS lawyer before they broke interoperability with Microsoft Office. Do you think Microsoft won't use this evidence in the DG Competition antitrust proceeding, Michael? Let's see, you guys are prosecuting Microsoft for not supporting ODF in Microsoft Office while you block Microsoft Office from supporting ODF. Yeah, I think DG Competition is going to hear about this one from Microsoft. They'll probably hear about what you said about compatibility being a trade off too. Oh, yeah. Microsoft's lawyers are going to love this. Look at the ECIS public statement about interoperability's importance.

Regarding section 1.5 itself: The Open Office TC decided to use the term MAY rather than MUST (or will) at the mentioned location, because it wanted to ensure that the OpenDocument specification can be used by as many implementations as possible. This means that the format should also be usable by applications that only support a very small subset of the specification, as long as the information that these applications store can be represented using the OpenDocument format. A requirement that all foreign elements and attributes must be preserved actually would mean that some applications may not use the format, although the format itself would be suitable. Therefor, we leave it up to the implementations, which elements and attributes of the specification they support, and whether they preserve foreign element and attributes. Some more information about this can be found in appendix D of the specification.

this TC does not have the final word on what goes into the ODF 1.2 spec. There is still the OASIS vote, the JTC-1 vote, and the ISO final ballot, with a few other stops along the way. There is also the market's response to what this TC does. Given that no one on this TC has objected to my considerable efforts to raise public concerns with Microsoft's ISO submission and some on this TC have lambasted Microsoft for creating interoperability barriers, why should this TC's members consider themselves exempt from warnings that they have just fallen into precisely the kind of behavior we routinely criticize when it's Microsoft that creates the interoperability barriers. Especially when it's the end users who will pay the price of the non-interoperability?

Unless we add conformance requirements for the preservation of metadata and processing instructions, the less featureful apps will never  be able to round-trip documents with the more featureful apps. Our language should require that. Personally, I believe that the software-as-an-end-point client-side office suites are dinosaurs at the end of their era. They are being finished off by a thousand cuts as users spend less and less time using them and more and more time using other apps, such as web apps. ODF either develops methods for interoperability among all apps or it will die along with the office suites. E.g., Microsoft knows this and is busily migrating its Office development budget across the Sharepoint/Exchange server hubs to the network. Meanwhile, this TC fiddles with preserving the 1995 software-as-an-endpoint vision.

Microsoft was invited, and did join the OASIS Open Office XML File Format TC as a founding member with observer status. Although the name of the TC was changed in September of 2004 (at the request of the EU) to "OpenDocument", Microsoft remains a member with observer status. All that need be done to convert their status from observer to voting member is to notify the TC Chairman of your intentions, show up for two consecutive phone conferences, and you are a voting member. It's that simple.

just played a little with other ODF applications. Looks like Lotus Symphony can handle input fields with paragraphs breaks in it. The XML it produces is:

In e-mailed comments, Heintzman said his criticisms about the situation have been made openly. "We think that Open Office has quite a bit of potential and would love to see it move to the independent foundation that was promised in the press release back when Sun originally announced OpenOffice," he said. "We think that there are plenty of existing models of communities, [such as] Apache and Eclipse, that we can look to as models of open governance, copyright aggregation and licensing regimes that would make the code much more relevant to a much larger set of potential contributors and implementers of the technology.... "Obviously, by joining we do believe that the organization is important and has potential," he wrote. "I think that new voices at the table, including IBM's, will help the organization become more efficient and relevant to a greater audience.... Our primary reason for joining was to contribute to the community and leverage the work that the community produces.... I think it is true there are many areas worthy of improvement and I sincerely hope we can work on those.... I hope the story coming out of Barcelona isn't a dysfunctional community story, but rather a [story about a] potentially significant and meaningful community with considerable potential that has lots of room for improvement...."

The Case for Harmonization (that IBM will vote against anyway) In my recent post, I discussed the case for harmonization, mainly due to trying to portray a more kindly, conciliatory face in the “standards krieg” that I was enjoying so much. I have been forced to take a different tack, in light of being hung out to dry by my more business-focused IBM comrades and the work that the enemy has done in sprucing up the spec. However, as my closest friends know, for me, there are no half-victories, so you can rest assured that I will not settle for this weak “harmonization” compromise. I set out my (and IBM’s) stall some time ago on this, and as those on the Open Document Foundation know, any attempt at harmonization shall be met with swift and final retribution.  They were ejected from the odf-coven just days after their impudence. I have baited my trap, inviting this “harmonization” in my lair (the OASIS ODF TC) where I can bog them down in a morass of incompetence, bickering and politicking, so no new standard is ever ratified.  I have already been practicing for this, as you can see, by the ODF 1.1 and 1.2 specs.

SUMMARY: The OpenDocument Foundation proposes that the OASIS Office TC begin now to create an interoperability framework for inclusion in OpenDocument v. 1.2. This document, one of a series of planned proposals, proposes first steps towards a comprehensive interoperability framework and OpenDocument conformance requirements.  This proposal is designed to bring ODF v. 1.2 into compliance with current ISO Interoperability Requirements.

Field enhancement proof-of-concept finished.