Group items tagged

A "Yes with comments" is a yes for the ISO approval of MS-OOMXL. If ISO approves MS-OOXML, it won't matter what Bosak's "comments" strategy is. Microsoft and the Vista Stack will be off to the races. The full disclosure of the MS binary document secret blueprint won't matter much at that point.

There you go Geir!

Sun and Bosak have held the door open for MS-OOXML since 2002, when Sun blocked an effort to write the ODF Charter to include as a priority, "compatibility with existing file formats". This of course would include the billions of legacy MS binary documents.

The thing is that those who work in the conversion-translation field will tell you that it is currently impossible to pipe converted legacy binary documents and OOXMl docs for that matter into ODF. Just as Microsoft claims, ODF in it's current state is insufficient and unable to handle the rich feature set of the MSOffice developers platform.

The problem could of course be easily fixed by the inclusion in ODF of five structural generics. In the past year, there have been no less than five iX "interoperability enhancement" proposals submitted to the OASIS ODF TC for discussion and consideration. As uber universal interop expert Florian Reuter points out in his blog, these iX proposals did not fare so well.

What Florian doesn't point out is that it was Sun who opposed any and all efforts to improve compatibility with existing Microsoft binary and OOXML documents. Just as they have done for nearly five years now.

Sort of puts the Sun-Bosak support for ISO approval of MS-OOXML in a different light. ~ge~

Forget ISO approval of OOXML. I would rather see ISO enforce the current directive that ODF be brought into compliance with existing ISO Interoperability requirements. Then and only then should ISO then consider OOXML.
The reason for this approach? If ODF wiere compliant with existing ISO Interop Requirements, there would probably be some hope of harmonizing ODF and OOXML. Until ODF is stripped of it's application specific settings, and fully documented, we can hardly beging the process of figuring out harmonization.
ODF 1.0 has four gapping holes that must be tended to before ISO proceeds any furhter with either ODF or OOXML. The holes are that ODF numbered lists, formulas and the presentation layer (styles) are woefully underspecified. The fourth problem is that ODF is seriously lacking an interoperability framework.
These ODF problems can of course be traced back to the fact that ODF is application specific and bound to the "semantics and capabilities" of OpenOffice. That creates all kinds of problems. OOXML on the other hand is even worse. OOXML is application, platform and vendor specific!!!! If ODF were brought up to snuff, we could reasonably start work on harmonization. Thereby eliminating the need to standardize two file formats for the same purposes. Until ODF is fixed, what's the world to do?
~ge~

Brauer well knows that he speaks of "the level of interoperability and choice of products" that Sun wants, not what Sun customers want. See e.g., the IDABC ODEF Conference proceedings. ODF is not designed for interoperability and interoperability may only be achieved by all persons involved in the interchange of ODF documents standardizing on a particular editing implementation and version. In practical terms, that means everyone uses a particular version of OpenOffice.org or a clone of that version's code base.

Hold on there Oliver. You've got the cart before the horse here. You say that, "standards need to be ready to support these two objectives". The objectives you sight are that of applications being desinged for interop (exchange) and collaboration. This observation is consistent with the vendor mantra coming out of Microsoft, Sun, and IBM: that interoperability is an application problem - not a standards issue. My view is that the only way we will have interoperability is if we design standards as totally application, platform and vendor independent. This demands a clean room approach, even to the extent of not allowing application vendors participation. At least not direct particpation where vendor business objectives might influence the standard. The first law of the Internet is that Interoperability rules. Interop must trump innovation. And innovation must be within the boundaries of the interoperability framework. Meaning, innovate on top of interop, but don't break that interop. Ever! This is exactly the opposite of how applications want to operate. They want innovation first, with interop as secondary feature based entirely on dooperative deals between vendors. That's not good enough for me or anyone else who believes that a universal fiel format is possible. The W3C approach is to focus entirely on the standards use requirements, completely shutting out application demands. With formats, this comes down to focusing on the basic document structures carried over from a few hundred years of document publication experience. The only proven formula for interop is to first write and establish the base standard. Then, let the applications adapt. Let the applications compete on how well they implement interoeprability standards, and build innovative features without disrupting or compromising that interop.

Ouch!

aha! Ulterior motives!