OpenDocument's feed | Diigo Group

Word of recognition from an unexpected side: ODF editor Patrick Durusau supports OOXML - ISO effort

Thu, 07 Feb 2008 19:04:16 -0000

Highlights and Sticky Notes:

The OpenXML project has made a large amount of progress in terms of the openness of its evelopment. Objections that do not recognize that are focusing on what they want to see and not what is actually happening with OpenXML

Tags: brm durusau iso oasis odf officeopenxml ooxml opendocument openxml

Posted by: garyedwards

The Future is CDF | Metaphorical Web - Kurt Cagle

Mon, 03 Dec 2007 20:27:17 -0000

Highlights and Sticky Notes:

As editing increasingly moves onto the web, its safe to say that the document of choice will be neither ODF nor OOXML, both of which gain their power on the basis of supporting legacy word processing systems. Instead, what seems to be emerging from the W3C is something that is not an office suite because it didn’t evolve from one, but that nonetheless is capable of most if not all of the same functions that office suite documents pose.

Tags: cdf ms-ooxml odf officeopenxml opendocument wicd

Posted by: garyedwards

Sun-Bosak "Yes" Vote on ISO approval of MS OOXML

Sat, 03 Nov 2007 23:15:32 -0000

Highlights and Sticky Notes:

We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents.

Read it and weep! Sun agrees that ODF was not designed for and is unable to meet these important market requirements posted by garyedwards

Tags: bosak ecma iso microsoft oasis odf officeopenxml ooxml opendocument openxml

Posted by: garyedwards

INTERVIEW: Craig Mundie -- Microsoft's technology chief, taking over from Bill Gates

Sat, 15 Sep 2007 16:35:51 -0000

Comments:

Great inteview, i'll comment as i make my way down the page. Hopefully others will do the same.
posted by garyedwards

Highlights and Sticky Notes:

In this exclusive interview with APC, Mundie says the notion of all software delivered entirely through the web browser is now widely recognised as being 'popular mythology'. He also stakes the claim that Google's existence and success was contingent on Microsoft creating Windows. He talks about what's coming down the pipeline for future versions of Windows, and his belief that Windows can get still more market share than it has today. He also discusses the issues around the recent controversy over the Office Open XML file format.

So Vista is in its diffusion cycle and until there is enough of it out there, you won't really see the developer community come across.

Uh, the diffusion we really should be focused on involves the OOXML plug-in for MSOffice, IE 7.0, MSOffice 2007, and the Exchange/SharePoint Hub.

The Exchange/SahrePoint juggernaught is now at 65% marketshare, with Apache servers in noticeable decline.

So it seems the improtant "diffusion" is going forward nicely. The exploitation of the E/S Hub has also started, and here the Microsoft deelopers have an uncahllenged advantage. Most of the business processes being migrated to the E/S Hub are coming off the MSOffice bound desktop. Outsiders to the MS Stack do not have the requisite access to the internals that drive these MSOffice bound business processes, so they have little hope of getting into the "exploitation" cycle.

This aspect was on full display at the recent Office 2.0 Conference in San Francisco. The only way a O2 provider can position their service as a collaborative addon to existing business processes is to have some higher level of interop-integration into those processes beyond basic conversion to HTML.

Most O2 operatives struggle to convince the market that an existing business process can be enhanced by stepping outside the process and putting the collaboration value elsewhere. While this approach is disruptive and unfriendly, it tends to work until a more integrated, more interoperable coolaboration value becomes available.

And that's the problem with O2. Everyone is excited over the new collaboration possibilities, but the money is with the integration of collaborative computing into existing business processes. This is a near impossible barrier for non Microsoft shops and would be competitors. If you're Microsoft though, and you control existing formats, applications and processes, the collaboration stuff is simple value added on. It's all low hanging fruit that Microsoft can get paid to deliver while O2 players struggle to figure out business models based on someone other than the end user paying.

posted by garyedwards

So far, we have delivered about 60 million copies. That would represent about six per cent of the global Windows install base. So it has probably got to get up another few percentage points before you will start to see a big migration of the developer community.

What is he talking about? Does a developer write to Vista? Or do they write to MS Stack ready .NET - OOXML-Smart Documents, XAML, Silverlight stuff? posted by garyedwards

Rather, what will happen is that you'll have, a seamless integration of locally running software in increasingly powerful client devices (not just desktops) and a set of services that work in conjunction with that.

A lot of what we are doing with the Live platform not only allows us to provide the service component for our parts, but also gives the abilities for the developer community to perfect their composite applications and get them deployed at scale.

Bear in mind that these "service components" are proprietary, and represent the only way to connect MS clients to the rest of the MS STack of applications. posted by garyedwards

Microsoft's business is not to control the platform per se, but in fact to allow it to be exploited by the world's developers. The fact that we have it out there gives us a good business, but in some ways it doesn't give us an advantage over any of the other developers in terms of being able to utilise it.

Oh right! The anti trust restrictions will not be lifted until November. Have to be careful here. But how is it Craig that non Microsoft devlopers and service providers will be albe to access and interoperate with important "service components"? posted by garyedwards

Tags: cdf odf officeopenxml ooxml opendocument

Posted by: garyedwards

Frankly Speaking: Microsoft's Cynicism - Flock

Thu, 13 Sep 2007 13:00:35 -0000

Comments:

Good commentary from Frank Hayes of Computerworld concerning a very serious problem. Even if ISO somehow manages to approve MS-OOXML, Microsoft has reserved the right to implement whatever extension of Ecma-OOXML they feel like implementing. The whole purpose of this standardization exercise was to bring interoperability, document exchange and long term archive capability to digital information by separating the file formats from the traditions of application, platform and vendor dependence.

If Microsoft is determined to produce a variation of OOXML that meets the needs of their proprietary application-platform stack, including proprietary bindings and dependencies, any illusions we might have about open standards and interoeprability will be shattered. By 2008, Microsoft is expected to have over a billion MS-OOXML ready systems intertwined with their proprietary MS Stack of desktop, server, device and web applications.

How are we to interoperate/integrate non Microsoft applications and services into that MS Stack if the portable document/data/media transport is off limits? If you thought the MS Desktop monopoly posed an impossible barrier, wait until the world gets a load of the MS Stack!

Good article Frank.

~ge~

posted by garyedwards

Highlights and Sticky Notes:

In July, Jones was asked on his blog whether Microsoft would actually commit to conform to an officially standardized OOXML. His response:

“It’s hard for Microsoft to commit to what comes out of Ecma [the European standards group that has already OK’d OOXML] in the coming years, because we don’t know what direction they will take the formats. We’ll of course stay active and propose changes based on where we want to go with Office 14. At the end of the day, though, the other Ecma members could decide to take the spec in a completely different direction. ... Since it’s not guaranteed, it would be hard for us to make any sort of official statement.”

Then why is Microsoft dragging us through this standardization nonsense? Is this nothing more than thinly veiled assault on open standards in general? posted by garyedwards

To at least some people at Microsoft, this isn’t about meeting the needs of customers who want a stable, solid, vendor-neutral format for storing and managing documents. It’s just another skirmish with the open-source crowd and rivals like IBM, and all that matters is winning.

The battle between OOXML and ODF is very much about two groups of big vendor alliances. Interestingly, both groups seek to limit ODF interoperability, but for different reasons.

See: The Plot To Limit ODF Interop posted by garyedwards

Tags: cdf iso odf officeopenxml ooxml opendocument

Posted by: garyedwards

Indecision in Redmond as Web apps charge : Office 2.0 and Google Apps

Wed, 12 Sep 2007 22:11:40 -0000

Comments:

Great quote from Eric Knorr. He hits the nail on the head here, pointing out the problem Office 2.0 Web Apps and SaaS apps face: If these Web wonders have interoperability and high fidelity document exchange with MSOffice, their collaborative features are value added wonders for existing business processes and workgroup-workflow scenarios. If, on the other hand they lack this level of interop - integration with MSOffice documents and processes, the value add becomes a problematic split in a business process. The only way to overcome that kind of a split is to take the entire process. Which is difficult for lightweight mashup happy web wonders to do.

Which leaves each and every one of these Office 2.0 - Web 2.0 - Saas Apps vulnerable to Microsoft. As long as Micrsoft owns the interop-integration keys to MSOffice, the web wonders live a precarious life. At any time Microsoft can swoop in and take it all.

Today, the MSOffice OOXML file format displays perfectly in a browser. It's 100% web ready, but only the MS Stack of applications gets to play. Web wonders are not likely to recieve a Redmond invite now or ever.

Which brings us to the issue of the da Vinci plug-in for MSOffice. da Vinci is a clone of the OOXML plug-in for MSOffice, and fully leverages the same internal conversion process that OOXML enjoys. It can achieve the same high fidelity "round trip" conversion that OOXML is capable of. Maybe even better.

The problem for da Vinci isn't conversion fidlelity. Nor is it capturing business process important VBa scripts, macros, OLE, and security settings. da Vinci can do that just fine. The problem is that da Vinci cannot pipe MSOffice developer platform documents into ODF!! For the love of five generic eXtensions, called the iX "interoperability enhancements", which the OASIS ODF TC blew off, ODF failed in Massachusetts.

Without these iX "interoperability enhancements", it's impossible to implement ODF anywhere there are MSOffice bound workgroups and business processes. Which is just about everywhere.

So what now?

For the past four months we have been converting da Vinci to pipe into a recent W3C release of HTML+. It's difficult, but we now are certain it can be done with the same high fidelity "round trip" conversion Microsoft achieves with the OOXML plug-in.

The significance of this discovery and proof is that there is a web ready alternative to MS-OOXML and the MS Stack. An alternative that should provide Office 2.0 - Web 2.0 and SaaS apps the same measure of interop - integration with existing documents, applications and processes that Microsoft now enjoys.

The consumer is caught between a rock and a hard place. Waiting for either the ODF or the OOXML gangs of big vendors to blink is a non starter. And even if they did want to harmonize or converge, that in itself may well be a technical impossiblity. The differences between how MSOffice works and how OpenOffice works are directly and "perfectly" reflected in the file formats. And never the twain shall meet.

So here it is. The world is not a clean slate. There are MSoffice workgroups everywhere. Meaning, in real world terms ODF is impossible to implement. Besides that, ODF is a desktop office suite only file format. It was not designed for the Internet, and can only be useful in that capacity through a lossy conversion. OOXML was designed to cover the full expanse of desktop, server, device and web. Only, it's to be a 100% Microsoft dominated and controlled expanse. Which leaves us with one alternative: HTML+

Time to get back to work :)

~ge~

Ref: "Why Can't We All Just Get Along?"

posted by garyedwards

Highlights and Sticky Notes:

the fact is that Redmond could own this new space if it wanted to. All it would need to do is push interoperability and integration between lightweight Web versions of Office applications and its desktop fatware. Advanced features would be absent from the lightweight versions, but the company could ensure any Office doc would load on the Web -- whatever new desktop service packs and upgrades might appear -- and online document management could be integrated with Windows for offline access.

Tags: cdf html odf officeopenxml ooxml opendocument

Posted by: garyedwards

Microsoft Loses Bid in Europe For Office Standard - WSJ.com

Tue, 04 Sep 2007 16:37:53 -0000

Tags: cdf iso odf officeopenxml ooxml opendocument

Posted by: garyedwards

Once More unto the Breach: Office Open XML Conformance (A Lesson in Claiming Standards Conformance)

Mon, 03 Sep 2007 14:21:08 -0000

Comments:

unfortunately the MS argument that support for OOXML equals "conformance" is also the same argument used by OpenDocument supporters to prove multi vendor, multi platform, multi application support.

posted by garyedwards

Highlights and Sticky Notes:

Presentation fidelity and round tripping? Looks like someone has been attention to what happened in Massachusetts. posted by garyedwards

As far as I can tell in the Massachusetts poster-child case, ODF has simply come to mean whatever OpenOffice.org does

Keep in mind orchmid that it is the OpenOffice code base that ODF is bound to. There are many instances of the OOo code base pushed by various vendors. Sun provides OpenOffice.org and StarOffice versions of the code base. Novell Open Office is the same code base. Same with Red Hat Office and IBM WorkPlace. Outside this common code base, ODF has near ZERO interoperability. posted by garyedwards

Tags: cdf msxml odf officeopenxml ooxml opendocument

Posted by: garyedwards

OOXML in Norway: The haywire process | Geir Isene : Straight talk on IT

Tue, 28 Aug 2007 10:58:57 -0000

Comments:

see the sticky notes on this one posted by garyedwards

Highlights and Sticky Notes:

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.

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. posted by garyedwards

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

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~ posted by garyedwards

Tags: interoperability iso odf officeopenxml ooxml opendocument

Posted by: garyedwards

Microsoft bashed in OOXML shens (and comparing loos) - Computerworld Blogs

Tue, 28 Aug 2007 10:03:13 -0000

Comments:

Collection of clips from the blogosphere concerning the pending Sep 2nd ISO vote on MS OOXML posted by garyedwards

Tags: cdf interoperability odf officeopenxml ooxml opendocument

Posted by: garyedwards

Open Sources | InfoWorld | While you were sleeping... (The Sharepoint Trojan Horse) | April 24, 2007 05:17 AM | By Matt Asay

Mon, 27 Aug 2007 10:40:08 -0000

Comments:

Matt Asay's commentary pointing out that the Microsoft monopoly is moving from the desktop to the SharePoint Server. Matt's cites a recent Wall Street Journal article as his reference. And both have it right except that i would have called this the Exchange/SharePoint Hub juggernaut.

The idea is to migrate existing MSOffice bound business processes to the E/S Hub. From there, end user documents, collaboration and workflow interfaces are wired into Microsoft backends and web fronts (MS SQL Server, MS IIS, MS Active Directory, MS Dynamics, MS Communications Server, etc.) posted by garyedwards

Tags: cdf interoperability odf officeopenxml ooxml opendocument sharepoint

Posted by: garyedwards

Slamming the door shut on MS OOXML

Fri, 24 Aug 2007 13:10:34 -0000

Comments:

Marbux on metadata and the language of universal interoperability: Few people are aware of the raging debate that has pushed ODF to the edge. The OASIS ODF TC is split between those who support Universal Interoperability, and those who insist on continuing with limited ODF interoperability.

ODF (OpenDocument), formally known as Open Office XML, began it's standards life in the fall of 2002 when Sun submitted the OpenOffice file format to OASIS for consideration as a office suite XML fiel format standard. The work on ODF did not start off as a clean slate in that there were near 600 pages of application specific specification from day one of the standards work. The forces of universal interop have sought for years to separate ODF from the application specific features and implementation model of OpenOffice that began with those early specification volumes, and continues through the undue influence Sun continues to have over the ODF specification work. Many mistakenly believed that submission of ODF to ISO and subsequent approval as an international standard would provide an effective separation, putting ODF on the track of a truly universal file format.

Marbux is one of those Universal Interop soldiers who has dug in his heels, cried to the heavens that enough is enough, and demanded the necessary changes to ODF interoperability language.

This post he recently submitted to the OASIS ODF Metadata SC is a devastating rebuttal to the arguments of those who support the status quo of limited interoperability.

In prior posts, marbux argues that ISO directives demand without compromise universal interoperability. This demand is also shared by the World Trade Organization directives regarding international trade laws and agreements. Here he brings those arguments together with the technical issues for achieving universal interop.

It's a devastating argument.

The OpenDocument Foundation has worked with the OASIS ODF TC since it's inception with one goal in mind. We believed that ODF could be that elusive Universal File Format. Today we know full well the difficulty of transitioning ODF away from it's application specific roots and the control of Sun. It's not that universal interop is difficult. It's actually simple. It's that OpenOffice would have to change and be re written to properly implement an ODF that is truly universal.

In the past year there were no less than five ODF iX "interoperability enhancement" proposals submitted to ODF TC members for discussion and consideration. Three of these iX proposals were vital to the success of ODF in Massachusetts and California, and were actually signed off on by Massachusetts ITD. The iX discussions did not go well though, as you can see in this status update recently posed by uber universal interop expert, Florian Reuter. (Page down to see the full report).

The iX interoperability enhancements are only part of the story though. There is still the need to fix the language of limited ODF interop that marbux so ably references. And then there is the need to fix and/or fully document the many application specific configuration-compatibility setting used by OpenOffice.

Institute the language of universal interop, embrace and implement the iX interoperability enhancement proposals, and fully document the application specific configuration - compatibility settings used by OpenOffice is a tall order for Sun. This is clearly a challenge for OpenOffice developers. But it has to be done if ODF is to achieve the universal interoperability the world expects and ISO directives demand.

As we approach the September 2nd, 2007 date of the ISO vote on MS OOXML, the world's attention is on the nonsense of OOXML. There is no possible way OOXML should be considered for any kind of standardization, yet here we are. IMHO, there is one and only one reason the world has been brought to the brink of this tragic consideration; and that reason is the limited interoperability of ODF!!

Even Sun has expressed their approval of ISO OOXML (DIS 29500), with this official comment:

“We wish to make it completely clear that we support DIS 29500 becoming an ISO Standard and are in complete agreement with its stated purposes of enabling interoperability among different implementations and providing interoperable access to the legacy of Microsoft Office documents.”

This statement happens to coincide with Microsoft's oft stated reason as to why they could not support ODF and HAD TO create OOXML! Microsoft argues that ODF is insufficient and unable to handle the richness of MSOffice features and the high fidelity conversion of billions of legacy binary documents. They argue that ODF was not designed to meet the needs of existing MS documents, applications and processes. Which is true. ODF was not designed for the conversion of most of the worlds existing documents, applications and processes to ODF.

And this is where the arguments for universal interoperability come into play. The ISO Directives and WTO Trade Requirements insist that ODF be designed exactly to e compatible with existing file formats, including MS binaries, and, interoperable with existing applications, including MS applications.

Sun and many of the current OASIS ODF TC membership argue that this compliance-interoperability with existing Microsoft bound proprietary documents and applications is out of scope, outside the charter, and perhaps even impossible without Microsoft's direct participation and support..

The "impossible to do without Microsoft support" argument is no doubt persuasive. The "out of scope - outside the charter" arguments are ridiculous and can easily be used by Microsoft to justify their non participation.

It's up to the governments of the world to force Microsoft into compliance, participation and support of ODF. The only thing we can do is to make certain that there is no technical barrier standing between ODF and the perfect implementation of ODF by Microsoft applications. So the question is, "Have we done all we could to remove the technical barriers?"

Once again, it's all about universal interoperabilityversus limited ODF interoperability. The language of universal interop and the iX interoperability enhancement proposals are designed to remove any technical barriers to the perfect conversion of existing documents, applications and processes to ODF, and back - (the infamous "round tripping" requirement demanded by MSOffice bound workgroups).

The truth is that if ISO shoots down OOXML - as they MUST if they hope to save whatever's left of public confidence in the international standards process, there is still the problem of converting existing documents, applications and processes to ODF. Without the transition of ODF from limited interop to universal interop, this conversion is impossibly costly and disruptive to try. And because of this, the world will end up implementing OOXML simply because there is no other way to get to XML - as has already been demonstrated by Massachusetts, California, Denmark. and Belgium. More will follow no matter what the vote at ISO simply because ODF is impossible to implement under the circumstances of years of documents, workgroups and workflows being bound to MSOffice.

The ODF iX "interoperability enhancement" proposals were designed to meet needs which we consider vital to universal interoperability.

The universal interop characteristics so noticeably missing from ODf fall into these three categories:

*Compatibility - file format level interop -
::: backwards compatibility / compatibility with existing file formats, including the legacy of billions of binary Microsoft documents

*Interoperability - application level interop-
:::::: application interoperability including interop with all Microsoft applications

*Convergence - cross platform interop:
::::::::: the portable XML document promise of being able to move content/data/media rich document packages across desktop - server - device and Web information systems. Another way of expressing this would be the exchange of portable XML documents with data bindings across desktop productivity environments, enterprise publication-content-archive management systems, SaaS, SOA and Web 2.0

Organizations the world over are at an important inflection point. They need to move existing documents, applications and processes to XML. Once there, the explosively rich digital civilization emerging around Web based collaborative computing is within reach. The big enchilada being SaaS, SOA and the Web 2.0 AJAX-REST mashup interop that promises to shatter all the traditional restrictions of application vendor controlled "interop".

There are only two file formats that could possibly meet the needs of universal interoperability; ODF iX and CDF (the W3C's Compound Document Format).

CDF is unique in that it can meet all three of the above requirements. (Yes, CDF can handle the perfect conversion of existing MS documents, applications and processes to CDF, and back).

ODF on the other hand needs work. For sure it needs the iX "Interoperability enhancement" proposals. Otherwise we can't perfect the conversion of existing documents, apps and processes. For sure ODF needs to implement the language of universal interop, and amend the charter accordingly. A process marbux is not likely to let go of. And for sure, the charter of ODF must also be amended support ISO-WTO directives. Which would be for the charter to include "compatibility with existing file formats and interoperability with existing applications".

Then and only then can we kiss MS OOXML good-bye and good riddance. Thanks marbux. Well done!
~ge~ posted by garyedwards

Highlights and Sticky Notes:

So your goal is a networked world where metadata is routinely trashed by apps developed by those who are too dumb or otherwise disabled to preserve metadata and only the big boys get to do interoperability, right? So if I send you a document for your editing, I can't count on getting it back with xml:id attributes intact.

No thanks, Patrick. That sounds way too much like how things have worked ever since office productivity software first came on the market. In your world, interoperability belongs only to those who can map features 1:1 with the most featureful apps. And that is precisely why OpenDocument never should have been approved as a standard. Your kind of interoperability makes ODF a de facto Sun Microsystems standard wearing the clothing of a de jure standard. Why not just standardize the whole world on Microsoft apps and be done with it? Are two monopolies maintained by an interoperability barrier between them better than one?

Fortunately, we don't have to debate the issue because the Directives resolve the issue. You lose under the rules of the game.

Tags: cdf interoperability iso odf odf-tc officeopenxml ooxml opendocument xml

Posted by: garyedwards

Not Even Close? OOXML Vote Tally for INCITSLB2341

Fri, 24 Aug 2007 13:07:01 -0000

Comments:

Wow. The USA votes ISO approval of MS OOXML (DIS 29500) with only three no votes being cast out of 16 members! It's not even close. posted by garyedwards

Tags: odf officeopenxml ooxml opendocument

Posted by: garyedwards

India Rejects Microsoft Control of Information

Thu, 23 Aug 2007 15:51:38 -0000

Tags: odf officeopenxml ooxml opendocument

Posted by: garyedwards

Compound Document Formats (CDF)

Mon, 06 Aug 2007 01:13:04 -0000

Comments:

heh heh heh. You where asking about that universal file format? drool away amigo! drool away posted by garyedwards

Tags: odef odf officeopenxml ooxml opendocument xhtml

Posted by: garyedwards

Microsoft Watch Finally Gets it - It's the Business Applications!- Obla De OBA Da

Fri, 13 Jul 2007 13:56:15 -0000

Comments:

Great article series from eWeek. A must read. But it all comes down to interoperability across two stack models: The Microsoft Vista Stack, and an alternative Open Stack model that does not yet exist!

Incompatible formats become a nightmare for the kind of integration any kind of SOA implementation depends on, let alone the Web 2.0 AJAX MashUps this article focuses on.

I wonder why eWEEK didn't include the Joe Wilcox Micrsoft Watch Article, "Obla De OBA Da". Joe hit hard on the connection between OOXML and the Vista Stack. He missed the implications this will have on MS SOA solutions. Open Source SOA solutions will be locked out of the Vista Stack. And with 98% or more of existing desktop business processes bound to MSOffice, the transition of these business processes to the Vista Stack will no doubt have a dramatic impact on the marketplace. Before the year is out, we'll see Redmond let loose with a torrent of MS SOA solutions. The only reason they've held back is that they need to first have all the Vista Stack pieces in place.

I don't think Microsoft is being held back by OOXML approval at ISO either. ISO approval might have made a difference in Europe in 2006, but even there, the EU IDABC has dropped the ISO requirement. For sure ISO approval means nothing in the US, as California and Massachusetts have demonstrated.

All that matters to State CIO's is that they can migrate exisiting docuemnts and business processes to XML. The only question is, "Which XML? OOXML, ODF or XHTML+".

The high fidelity conversion ratio and non disruptive OOXML plugin for MSOffice has certainly provided OOXML with the edge in this process.

Because of ODF vendor in fighting in Massachusetts, and the subsequent failure of ODF, the hapless file format arrived in California and other states with a hardened reprutation as "great file format, but impossible to implement".

The next question people have to start askign is what impact will OOXML and the Vista Stack have on SOA? Will open source and non Micrsoft vendor SOA solutions be locked out of the Vista STack?

Of course. If ever there was a no brainer this is it. Microsoft is goign to eXtend their desktop monopoly to servers, devices and the web using the highly proprietary Vista STack to lock in business process customers for years to come.

~ge~
posted by garyedwards

Highlights and Sticky Notes:

To be fair, Microsoft seeks to solve real world problems with respect to helping customers glean more value from their information. But the approach depends on enterprises adopting an end-to-end Microsoft stack—vertically from desktop to server and horizontally across desktop and server products. The development glue is .NET Framework, while the informational glue is OOXML.

OOXML is the transport - a portable XML document model where the "document" is the interface into content/data/ and media streaming.

The binding model for OOXML is "Smart Documents", and it is proprietary!

Smart Documents is how data, streaming media, scripting-routing-workflow intelligence and metadata is added to any document object.

Think of the ODF binding model using XForms, XML/RDF and RDFA metadata. One could even use Jabber XMP as a binding model, which is how we did the Comcast SOA based Sales and Inventory Management System prototype.

Interestingly, Smart Documents is based on pre written widgets that can simply be dragged, dropped and bound to any document object. The Infopath applicaiton provides a highly visual means for end users to build intelligent self routing forms. But Visual Studio .NET, which was released with MSOffice 2007 in December of 2006. makes it very easy for application and line of business integration developers to implement very advanced data binding using the Smart Document widgets.

I would also go as far to say that what separates MSOOXML from Ecma 376 is going to be primarily Smart Documents.

Yes, there are .NET Framework Libraries and Vista Stack dependencies like XAML that will also provide a proprietary "Vista Stack" only barrier to interoperability, but Smart Documents is a killer.

One company that will be particularly hurt by Smart Documents is Google. The reason is that the business value of Google Search is based on using advanced and closely held proprietary algorithms to provide metadata structure for unstrucutred documents.

This was great for a world awash in unstructured documents. By moving the "XML" structuring of documents down to the author - workgroup - workflow application level though, the world will soon enough be awash in highly structured documents that have end user metadata defining document objects and document pages. And who better to apply specific ontologies and metadata information than the actual knowledge workers themselves?

Can the authors and workgroup experts beat the famed Google algorithms? Of course. Given the right tools, end users will be able to do this.

The thing is, the "right tools" for MSOffice bound business processes is going to be based on binary Smart Document widgets and components! Google will not be able to touch this layer of advanced metadata strucuturing!

Up till now Google has fought the W3C Semantic Web proposals for RDF XML/RDF and RDFa. With good reason. Google obviously has figured out that much of their value will disipate if the world moves to highly structured metadata rich documents with advanced data binding methods. No need for those precious algorithms.

So the Vista Stack model that is now emerging is actually a two prong strategy. On the one hand Microsoft is extending their desktop monopoly to take over the entire business stack, as Joe so abley points out. On the other hand, this is an assault on the open Internet, with OOXML-Smart Docs rapidly positioning to replace unstructured HTML as the premier transport of a potent information and data package. posted by garyedwards

Microsoft seeks to create sales pull along the vertical stack between the desktop and server.

The vertical stack is actually desktop - server - device - web based. The idea of a portable XML document is that it must be able to transition across the converged application space of this sweeping stack model.

Note that ODF is intentionally limited to the desktop by it's OASIS Charter statement. One of the primary failings of ODF is that it is not able to be fully implemented in this converged space. OOXML on the other hand was created exactly for this purpose!

So ODF is limited to the desktop, and remains tightly bound to OpenOffice feature sets. OOXML differs in that it is tightly bound to the Vista Stack.

So where is an Open Stack model to turn to?

Good question, and one that will come to haunt us for years to come. Because ODF cannot move into the converged space of desktop to server to device to the web information systems connected through portable docuemnt/data transport, it is unfit as a candidate for Universal File Format.

OOXML is unfi as a UFF becuase it is application - platform and vendor bound.

For those of us who believe in an open and unencumbered universal file format, it's back to the drawing board.

XHTML (XHTML CSS3 RDF) is looking very good. The challenge is proving that we can build plugins for MSOffice and OpenOffice that can fully implement XHTML . Can we conver the billions of binary legacy documents and existing MSOffice bound business processes to XHTML ?

I think so. But we can't be sure until the da Vinci proves this conclusively.

One thign to keep in mind though. The internal plugins have already shown that it is possible to do multiple file formats. OOXML, ODF, and XML encoded RTF all have been shown to work, and do so with a level of two way conversion fidelity demanded by existing business processes.

So why not try it with XHTML , or ODEF (the eXtended version of ODF enhanced for true universal interoperability)?
posted by garyedwards

Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats.

This backwards compatibility with the existing binary file formats isn't the big deal Micrsoft makes it out to be. ODF 1.0 includes a "Conformance Clause", (Section 1.5) that was designed and included in the specification exactly so that the billions of binary legacy documents could be converted into ODF XML.

The problem with the ODF Conformance Clause is that the leading ODF application, OpenOffice, does not fully support and implement the Conformance Clause.

The only foreign elements supported by OpenOffice are paragraphs and text spans. Critically important structural document characteristics such as lists, fields, tables, sections and page breaks are not supported!

This leads to a serious drop in conversion fidelity wherever MS binaries are converted to OpenOffice ODF.

Note that OpenOffice ODF is very different from MSOffice ODF, as implemented by internal conversion plugins like da Vinci. KOffice ODF and Googel Docs ODF are all different ODF implementations. Because there are so many different ways to implement ODF, and still have "conforming" ODF documents, there is much truth to the statement that ODF has zero interoperabiltiy.

It's also true that OOXML has optional implementation areas. With ODF we call these "optional" implementation areas "interoperabiltiy break points" because this is exactly where the document exchange presentation fidelity breaks down, leaving the dominant market ODF applicaiton as the only means of sustaining interoperabiltiy.

With OOXML, the entire Vista Stack - Win32 dependency layer is "optional". No doubt, all MSOffice - Exchange/SharePoint Hub applications will implement the full sweep of proprietary dependencies. This includes the legacy Win32 API dependencies (like VML, EMF, EMF ), and the emerging Vista Stack dependencies that include Smart Documents, XAML, .NET 3.0 Libraries, and DrawingML.

MSOffice 2007 is extremely unique as an application in that it's able to import legacy documents and preserve their Win32 dependencies. Yet, if you were to re create those same documents "natively" in MSOffice 2007, the dependencies would all be Vista Stack types.

Here's a kicker. If you attach an MSOffice legacy binary to an eMail, and send that eMail to any Exchange/SharePoint Hub application (like OWL), the attachment will automatically be converted to MS OOXML - complete with Vista Stack dependencies! Unl,ike MSOffic e2007, the E/S Hub does not offer that dual backwards compatibiltiy model.

Because of this dual model, MSOffice is one of the most unique applications Microsoft has ever put on the market. The traditionnal MS application only proivedes for one way backwards compatibility. You can read in a legacy document, but are unable to effectively wirte out to the legacy binary format. MSOffice 2007 steps soff the forced upgrade treadmill, and offers a dual mode two way form of backwards compatibiltiy. It' will be tricky for end users to avoid the upgrade trap of writing new documents and thinking they can be inserted into a MSOffic ebound workgroup tha tincludes legacy MSOffice versions. But it can be done.

The traditional forced march upgrade treadmill strategy has been moved to the Exchange/SharePoint Hub. This is also where next generation line of business integration apps will be written - replacing the desktop platform as everything is migrated to Microsoft's XML.
posted by garyedwards

Microsoft's backwards compatibility priority means the company made XML-based format decisions that compromise the open objectives of XML. Open Office XML is neither open nor XML.

True, but a tricky statement given that the proprietary OOXML implementation is "optional". It is theoretically possible to implement Ecma 376 without the prorpietary dependencies of MSOffice - Exchange/SharePoint Hub - Vista Stack "OOXML".

In fact, this was first demonstrated by the legendary document processing - plugin architecture expert, Florian Reuter.

Florian has the unique distinction of being the primary architect for two major plugins: the da Vinci ODF plugin for MSOffice, and, the Novell OOXML Translator plugin for OpenOffice!

It is the Novell OOXML Translator Plugin for OpenOffice that first demonstrated that Ecma 376 could be cleanly implemented without the MSOffice application-platform-vendor specific dependencies we find in every MSOffice OOXML document.

So while Joe is technically correct here, that OOXML is neither open nor XML, there is a caveat. For 95% of all desktops and near 100% of all desktops in a workgroup, Joe's statment holds true. For all practical concerns, that's enough. For Microsoft's vaunted marketing spin machine though, they will make it sound as though OOXML is actually open and application-platform-vendor independent.

posted by garyedwards

Microsoft got there first to protect Office.

No. I disagree. Microsoft needs to move to XML structured documents regardless of what others are doing. The binary document model is simply unable to be useful to any desktop- to server- to device- to the web- transport!

Many wonder what Microsoft's SOA strategy is. Well, it's this: the Vista Stack based on OOXML-Smart Documents-.NET.

The thing is, Microsoft could not afford to market a SOA solution until all the proprietary solutions of the Vista Stack were in place.

The Vista Stack looks like this:

..... The core :: MSOffice <> OOXML <> IE <> The Exchange/SharePoint Hub

..... The services :: E/S HUb <> MS SQL Server <> MS Dynamics <> MS Live <> MS Active Directory Server <> MSOffice RC Front End

The key to the stack is the OOXML-Smart Documents capture of EXISTING MSOffice bound business processes and documents.

The trick for Microsoft is to migrate these existing business processes and documents to the E/S Hub where line of business developers can re engineer aging desktop LOB apps.

The productivity gains that can be had through this migration to the E/S Hub are extraordinary.

A little over a year ago an E/S Hub verticle market application called "Agent Achieve" came out for the real estate industry. AA competed against a legacy of twenty years of contact management based - MLS data connected desktop shrinkware applications. (MLS-Multiple Listing Service)

These traditional desktop client/server productivity apps defined the real estate business process as far as it could be said to be "digital". For the most part, the real estate transaction industry remains a paper driven process. The desktop stuff was only useful for managing clients and lead prospecting. No one could crack the electronic documents - electonic business transaction model. This will no doubt change with the emerging dominance of E/S Hub solutions.

The desktop stuff also was very brittle, requiring constant adminsistration, training and hand holding.

Within weeks of Agent Achieve coming out, Outlook desktops were being replaced over night. Although AA was a broker owner system (not individual), there was a sudden rush by independent agents to work where AA systems were available. That wave pushed ever more brokerages towards AA.

As this second wave set in, the desktop applications began to offer their own E/S Hub alternatives. Within 9 months the entire desktop productivity market had been replaced by E/S Hub based applications. It went quick.

This is a prelude to the SOA onslaught soon to come out of Redmond. Once the Vista Stack is in place, and open source SOA components effectively locked out, Microsoft SOA will sweep the business sector.

Without OOXML high fidelity compatibilty, and Smart Documents capability, open source SOA inititives will fall by the way side. Microsoft will successfully leverage their desktop MSOffice bound monoploy over business processes into a proprietary killer SOA solution. The only thing that might stop them is if open source providers wake up and understand that OOXML-Smart Documents is the whole ball game. And that there is no comparable ODF alternative ready to challenge the looming juggernaut.

posted by garyedwards

By adapting XML

The requirements of these E/S Hub systems are XP, XP MSOffice 2003 Professional, Exchange Server with OWL (Outlook on the Web) , SharePoint Server, Active Directory Server, and at least four MS SQL Servers!

In Arpil of 2006, Microsoft issued a harsh and sudden End-of-Life for all Windows 2000 - MSOffice 2000 systems in the real estate industry (although many industries were similarly impacted). What happened is that on a Friday afternoon, just prior to a big open house weekend, Microsoft issued a security patch for all Exchange systems. Once the patch was installed, end users needed IE 7.0 to connect to the Exchange Server Systems.

Since there is no IE 7.0 made for Windows 2000, those users relying on E/S Hub applications, which was the entire industry, suddenly found themselves disconnected and near out of business.

Amazingly, not a single user complained! Rather than getting pissed at Microsoft for the sudden and very disruptive EOL, the real estate users simply ran out to buy new XP-MSOffice 2003 systems. It was all done under the rational that to be competitive, you have to keep up with technology systems.

Amazing. But it also goes to show how powerfully productive the E/S Hub applications can be. This wouldn't have happened if the E/S Hub applications didn't have a very high productivity value.

When we visited Massachusetts in June of 2006, to demonstrate and test the da Vinci ODF plugin for MSOffice, we found them purchasing en mass E/S Hubs! These are ODF killers! Yet Microsoft sales people had convinced Massachusetts ITD that Exchange/SahrePoint was a simple to use eMail-calendar-portal system. Not a threat to anyone!

The truth is that in the E/S Hub ecosystem, OOXML is THE TRANSPORT. ODF is a poor, second class attachment of no use at the application - document processing chain level.

Even if Massachusetts had mandated ODF, they were only one E/S Hub Court Dockett Management System away from approving OOXML.

The odd thing for us was understanding why Microsoft wasn't trumpeting their SOA slam dunk in real estate? posted by garyedwards

Microsoft can offer businesses many of the informational sharing and mining benefits associated with the markup language while leveraging Office and supporting desktop and server products as the primary consumption conduit.

Okay, now Joe has the Micrsoft SOA bull by the horns. Why doesn't he wrestle the monster down?
posted by garyedwards

Microsoft will vie for the whole business software stack, a strategy that I believe will be indisputable by early 2009 at the latest.

Finally, someone who understands the grand strategy of levergaing the desktop monopoly into the converged space of server, device and web information systems.

What Joe isn't watching is the way the Exchange/SharePoint Server connects to MS SQL Server, Active Directory Server, MS LIve and MS Dynamics.

Also, Joe does not see the connection between OOXML as the portable XML document/data transport, and the insidiously proprietary Smart Documents metadata - data binding system that totally separates MSOOXML from Ecma 376 OOXML!
posted by garyedwards

I'm convinced that Office as a platform is an eventual dead end. But Microsoft is going to lead lots of customers and partners down that platform path.

Yes, but the new platform for busines process development is that of MSOffice <> Exchange/SharePoint Hub.

The OOXML-Smart Docs transport replaces the old binary document with OLE and VBA Scripts and Macros functionality. Which, for the sake of brevity we can call the lead Win32 API dependencies.

One substantial difference is that OOXML-Smart Docs is Vista Stack ready, while the Win32 API dependencies were desktop bound.

Another way of looking at this is to see that the old MSOffice platform was great for desktop application integration. As long as the complete Win32 API was available (Windows MSOffice VBA run times), this platform was great for workgroups. The Line of Business integrated apps were among the most brittle of all client/server efforts, bu they were the best for that generation.

The Internet offers everyone a new way of integrating data, content and streaming media. Web applications are capable of loosly coupled serving and consuming of other application services. Back end systems can serve up data in a number of ways: web services as SOAP, web services as AJAX/REST, or XML data streams as in HTTPXMLRequest or Jabber P2P model.

On the web services consumption side, it looks like AJAX/REST will be the block buster choice, if the governance and security issues can be managed.

Into this SOA mash Microsoft will push with a sweeping integrated stack model. Since the Smart Docs part of the OOXML-Samrt Docs transport equation is totally proprietary, but used throughout the Vista Stack, it will provide Microsoft with an effective customer lockin - OSS lockout point.

posted by garyedwards

Tags: odef odf officeopenxml ooxml opendocument vista-stack

Posted by: garyedwards

2. WordprocessingML Reference Material - OOXML-Wiki

Wed, 11 Jul 2007 01:01:00 -0000

Comments:

I promise that within a few minutes of reading this OOXML Wiki you will be wondering if this is in fact an ODF Wiki! This is incredible.

Fast forward to the section called, "Interoperability between ODF and OOXML", and enjoy. They cite the problem and make an interop recommendation for each entry. And what a recommendation it is. Speaks volumes.

There is definately something going on in Europe. The EU IDABC has rejected ODF, OOXML, OASIS, Ecma and ISO! And are now trying to write their own highly interoperable XML file format, ODEF. an effort we will fully support with our da Vinci plugin for MSOffice.

Well, not only will we support ODEF, we'll write it for them if they really want to cut to the chase and get the kind of vendor independent interoperability the world hungers for.

The British Standards Institute (BSi) is responsible for the massive research that went into this OOXML Wiki. They have hunted down and defined the interoperability problem areas between ODF and OOXML. Surprise surprise. They be many.

The interesting part is that the BSi researchers have found massive, indeed overwhelming fault with OOXML! Yet, instead of recommending that Ecma make the needed changes to OOXML, they instead recommend that ISO ODF make the changes!

Not OASIS ODF! Not Ecma OOXML.

ISO ODf!

The difference is all the difference in the world. Sun does not control ISO ODF the way they control OASIS ODF. And at ISO, all the binding of ODF to OpenOffice/StarOffice that accounts for the zero interoperability of ODF applications can be broken as needed.

This is indeed good stuff.

You can't read this research without thinking that the BSi is going to advise the British ISO NB contingent to vote against OOXML. But they aren't about to let ODF sit idle either. The only way they see to fix interoperability between OOXML and ODF is to identify the problems in OOXML, and FIX ODF to accomodate those problems!

Not OOXML. Yet all the fault they identify lies with OOXML.

Amazing.

Clearly the BSi recognizes that OOXML is a plugin bound to the MSOffice application series. Changing OOXML would require changes at the application level - changes in MSOffice.

Changing the application layer for 95% of all workgroup - workflow bound business processes would be a disaster. So they correctly see that the way forward is to change ODF, and tell Sun to do whatever it takes to adapt the OpenOffice/StarOffice applications that bind ODF. At less than 2% marketshare, this approach sound reasonable to me. But i'm not Sun. And i don't have a 2004 controlled interoperability-patent-market allocation-sweet sweet hardware deal with Microsoft either.

We've been working for more than a year on a set of ODF Interoperability Enhancements that would greatly benefit anyone working the converter - plugin - transformation interop sector. These proposals have been met with vicious vehemence at OASIS ODF - see the recent List Enhancement Proposal donnybrook as an example. So much so that we see no use in further proposals or our continued participation. And that after near five years of work on OASIS ODF.

We fully believe that our insistence on interoperability enhancements to ODF that would improve interop with Microsoft documents and applications is the reason why OASIS booted the OpenDocument Foundation. Pushing for interop with existing file formats and application is that bad. Opposing Sun is worth the wrath of big vendor toady OASIS.

But i have to wonder, how do these BSi guys know this? Obviously they have figured out that the only way to get true interoperability is to neutralize the big vendors influence and control of the standards process. Same as with the EU IDABC.

Must be something in the water. Drink up world. You actually can get everything you want. Including perfect interoperability.

~ge~
posted by garyedwards

Highlights and Sticky Notes:

It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following features:

It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: image can be positioned absolutely within a frame

Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

Include support for this feature in ISO ODF is another way of saying to hell with Ecma, OASIS and the big vendors driving the ODF-OOXML bus, Micrsoft and Sun. This is delicious beyond belief. It's also the only way the world is going to get the interoperability they are demanding. The big vendors must be neutralized. The file formats must be completely independent of applications, platforms and the control of big vendors who routinely make exclussionary interoperabilty deals with each other whenever and wherever profitable. posted by garyedwards

Tags: odef odf officeopenxml ooxml open-document-exchange-format opendocument

Posted by: garyedwards

Is It Game Over? - ODF Advocate Andy UpDegrove is Worried. Very Worried

Fri, 29 Jun 2007 16:16:51 -0000

Comments:

Andy UpDegrove takes on the issue of Microsoft submitting their proprietary "XML alternative to PDF" proposal to Ecma for consideration as an international standard. MS XML-PDF will compliment ECMA 376 (OOXML - OfficeOpenXML) which is scheduled for ISO vote in September of 2007. Just a bit over 60 days from today.

Andy points out some interesting things; such as the "Charter" similarities between MS XML-PDF and MS OOXML submisssions to Ecma:
MS XML-PDF Scope:

The goal of the Technical Committee is to produce a formal standard for office productivity applications within the Ecma International standards process which is fully compatible with the Office Open XML Formats. The aim is to enable the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems. The Technical Committee will also be responsible for the ongoing maintenance and evolution of the standard.
Programme of Work: Produce a formal standard for an XML-based electronic paper format and XML-based page description language which is consistent with existing implementations of the format called the XML Paper Specification,…[in each case, emphasis added]

If that sounds familiar, it should, because it echoes the absolute directive of the original OOXML technical committee charter, which constrained the TC as follows:

The goal of the Technical Committee is to produce a formal standard for office productivity applications within the Ecma International standards process which is fully compatible with the Office Open XML Formats. The aim is to enable the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems. The Technical Committee will also be responsible for the ongoing maintenance and evolution of the standard.[emphasis added]

Notice that the target in both charters is that of fostering interoperability across office productivity applications and with line-of-business systems.

It's beyond important that perople understand the nature of the MSOffice lock-in barriers that ODF and PDF must overcome. If our only problem was that of converting legacy MSOffice binary docuemnts to ODF or PDF, we would have broken the monopolist grip years ago.

What people have to realize is that it is the MSOffice bound workgroup-workflow business process barrier that is near impossible to overcome!

Let's go one step further and admit that Micrsoft's plugin approach for installing OOXML and XML-PDF in MSOffice is the only way to "realistically" overcome this business process barrier.

Which means there is an interesting corrollary for ODF. Only the internal ODF-PDF plugins for MSOffice will be able to similarly overcome the business process barrier. Rip out and replace approaches are too costly and disruptive. So much so that even in governments like Massachusetts, where they had mandated ODF, it has proved impossible to implement ODF.

One way of looking at this problem is to take the OASIS ODF big vendor blinders off and see clearly that the way Microsoft deals with the problem of converting existing documents and bound business processes to XML, is to provide their own OOXML :: XML-PDF plugin for existing MSOffice desktops.

Note well one other phenomenon confirming the efficacy of the plugin approach. The Microsoft - Novell deal resulted in a OOXML plugin for OpenOffice! Subsequent Micrsoft deals feature this highly controlled and directed version of "interoperability" through agreements with prominent LiNUX vendors tha tthey distribute the Novell OpenOffice version with the OOXML plugin set as the default file format!

The same ODF vendors who opposed an internal ODF Plugin for MSOffice, are now shipping an OpenOffice with the OOXML plugin set as default.

(With Sun is not far behind - from the document, "Interoperability Wars", we have this collection of gems:

.... Yes, Sun will, but not as a return favor. Sun is cooperating with Novell on the OfficeOpenXML Translator plugin for OpenOffice, even though they virulently opposed Novell's much needed "Interoperability Enhancement" proposals on the OpenDocument Technical Committee. Sun will focus on a high fidelity import of OfficeOpenXML into OpenOffice, but most likely will put little if any effort into export. The old one-way street trap that helped Microsoft to fame and fortune. Novell is working on OOo export to OOXML.
- Importing the beast...
- Office Open XML Import Filter for Spreadsheets
- OpenOffice Development at a Glance - Weekly Update & Schedule CW25 ....(notice all the scheduled work going into MS OfficeOpenXML import)
- Roundtrip to Shanghai via Tokyo :: The Sun - Novell Joint Effort Import of OfficeOpenXML
- New MS Word Filter for Writer (Milestone 1) :: Sun Beta of the OfficeOpenXML filter for OpenOffice
The OpenDocument Foundation's da Vinci pllugin for MSOffice is simply a clone of the Microsoft OOXML plugin (which is also called the XML Compatibility Kit :).

Interstingly, when Massachusetts was evaluating da Vinci, one of the priorities they asked for was that we focus on the PDF-ODF digital signature package. This is a design concept we presented to Massachusetts to include in da Vinci a PDF conversion. But not just any PDF conversion. What we proposed was to embed the ODF markup with the PDF file, implementing a digital signature to protect the ODF markup.

The PDF-ODF file could be opened in any Acrobat reader. This is a "static" view of the content. Or, if one had access to the digitally signed ODF markup, one could "interactively" access the contents using an ODF application. Including any da Vinci converted MSOffice workgroup-workflow bound desktop.

Now it appears that Microsoft is about to do the same thing with their OOXML :: XML-PDF plugin. Very cool, and much needed. But not something that can't also be done in ODF.

One area in his commentary where Andy makes a grave mistake is where he states:
^#1This seems to me to be a turning point for the creation of global standards. Microsoft was invited to be part of the original ODF Technical Committee in OASIS, and chose to stand aside. That committee tried to do its best to make the standard work well with Office, but was naturally limited in that endeavor by Microsoft's unwillingness to cooperate. This, of course, made it easier for Microsoft to later claim a need for OOXML to be adopted as a standard, in order to "better serve its customers." The refusal by an incumbent to participate in an open standards process is certainly its right, but it is hardly conduct that should be rewarded by a global standards body charged with watching out for the best interests of all.

This statement is absolutely true of the original OASIS ODF TC (Technical Committee) that first met in December of 2002. In fact, it was true throughout the first fifteen months of ODF TC activity. Everyone on that first TC group supported full interoperability with Microsoft applications and documents, except for one company - Sun.

There are three areas of "interoperability" that Sun opposed then, and continues to oppose today. The only difference being that after their 2004 deal with Microsoft, Sun has been uncompromisingly determined to block the interoperability the marketplace demands.

Prior to the 2004 deal, there is much evidence of interop flexibility that made it's way past Sun and into the ODF specification. It's not without good reason that the ODF 1.0 Conformance Section is also called the "universal generic".

The problem is that these interop holes in the ODF spec are "optional", and subsequently not supported or implemented by Sun's OpenOffice/StarOffice code base. In fact, almost anywhere you find "optional" implementation choices in ODF, most likely your starring at an interoperability break point.

Since the 2004 deal, the binding of ODF to Sun's OpenOffice/StarOffice feature set has hardened. So much so that after the failure of ODF in Massachusetts, CIO's across the nation started refering to ODF as having zero interop; a nice XML format that is impossible to implement in real world situations. A real world filled with situations dominated by MSOffice bound workgroup-workflow business processes.

Today the OASIS ODF TC is completly 180 degrees opposite the one that met in December of 2002.

There are three categories that define the "interoperability" problem:
- Compatibility with existing file formats and documents
- Interoperability at the Application layer
- Convergence - the portability of an XML document across desktop, server, device and web information systems
The CIO's who must deal with 15 years of MSOffice line of business development, need XML document solutions that can meet all three of the above interope criteria. The over riding problem for CIO's is that of migrating their documents and business processes to XML. The only question is, "Which XML, ODF or OOXML?

So far ODF has been a no show. The only thing big ODF vendors have to offer is rip out and replace desktop alternatives to MSOffice. These are too costly and disruptive in terms of the bound business proceses to ever be considered, as evidenced by a year long ODF Pilot Study conducted by the Commonwealth of Massachusetts. A study that resulted in the Massachusetts Request for Information about the possibility of an ODF plugin for MSOffice. The Pilot Study was such a disaster for ODF that it was burried forever, never to see the light of day.

That leaves the entire future of ODF with the internal ODF plugins for MSOffice. An approach the big ODF do not support in either the marketplace, or, perhaps most importantly, at the level of the OASIS ODF TC - where "compatibility, interoperability and convergence" capabilites either go into the spec, or not.

Since 2004, it's been 100% NOT!

The proof of this can be seen in any number of OASIS ODF TC proposals and discussions. The most recent examples being threads having to deal with List Enhancement Proposals and Metadata XML/RDF.

The current membership of the OASIS ODF TC is clearly and unequivocably on record as opposed to the interoperability the marketplace is screaming for. The issues of "compatibility, interoperability, and convergence", as described above have been called by current TC members: "out of bounds", "out of scope", "not our problem", "let the converters and transformers deal with it", and "talk to Microsoft".

If Micrsoft were to join the OASIS ODF TC today, seeking to adapt ODF to meet the legacy document-MSOffice features-line of business integration needs of their monopoly base, the TC would have to deal with the exact same issues as they have summarily rejected with current compatibility-interoeprability-convergence disussions!

There is no possible way anyone can claim that today's OASIS ODF TC would welcome Microsoft and make accomodating changes to the specification! No way! And the proof of this hostility can be seen in the actual disussions and rejections of Micrsoft specific interoperability proposals.

Andy is out of touch and clearly drinking the kool-aid.

~ge~
posted by garyedwards

Highlights and Sticky Notes:

This seems to me to be a turning point for the creation of global standards. Microsoft was invited to be part of the original ODF Technical Committee in OASIS, and chose to stand aside. That committee tried to do its best to make the standard work well with Office, but was naturally limited in that endeavor by Microsoft's unwillingness to cooperate. This, of course, made it easier for Microsoft to later claim a need for OOXML to be adopted as a standard, in order to "better serve its customers." The refusal by an incumbent to participate in an open standards process is certainly its right, but it is hardly conduct that should be rewarded by a global standards body charged with watching out for the best interests of all.

Tags: iso oasis odf officeopenxml ooxml opendocument xml

Posted by: garyedwards

BetaNews | Microsoft Will Support ODF If It Doesn't 'Restrict Choice Among Formats'

Sat, 23 Jun 2007 12:51:00 -0000

Highlights and Sticky Notes:

None of this is to say that OpenDocument is perfect. Far from it. OpenDocument at present is crippled from an interoperability standpoint. I'm a member of the OASIS OpenDocument Technical Committee and I think the resistance of the big vendors to fixing the interoperability warts is simply outrageous, particularly because they are fairly trivial changes.

But the advancement of software users' interests are not advanced by painting OOXML as other than deeply flawed. It is vendor-specific and far from "open." The lesser of the two evils is clearly OpenDocument, which is at least open even if not yet interoperable.

The sooner folks can start discussing practical methods of convergence, the better. See e.g., http://ec.europa.eu/idabc/servlets/Doc?id=27956

That set of slides summarizing a conference of some 20 European national governments' IT types says a lot more about the future of office document formats than Mr. Asellus has to offer.

Marbux hits a homerun! Right ON! posted by garyedwards

Tags: ecma376 odf officeopenxml ooxml opendocument

Posted by: garyedwards

PlexNex: Achieving Openness

Tue, 19 Jun 2007 15:02:29 -0000

Comments:

Whoa, Stepen Rodriguez knocks this one out of the park. What an impressive dissembling of MS OfficeOpenXML and it's poor sister subset, Ecma 376. Incredible.
posted by garyedwards

Highlights and Sticky Notes:

"ECMA 376" is a set of file formats subject to ECMA and now to ISO.

"Office 2007" is a set of file formats which extend "ECMA 376" file formats.

Office 2007 file formats are undocumented per se. ECMA 376 are.

ECMA 376 file formats are documented but only at a syntactic level. To realize the true meaning of every single attribute is to realize that the documentation is more like 600,000 pages, not 6,000. Of particular difficulty is to keep some kind of control over the virtually infinite combinations of such attributes.

Quick analysis of the underlying schemas reveals that simple concepts such as text formatting is expressed in no less than 6 different and incompatible ways. This leads to thinking that the file formats were only designed to comply with existing legacy formats that themselves are the result of 15 years of inside/outside library aggregation (some of the libraries were bought from non-Microsoft vendors). In fact, the truth is, ask any reverse engineer third-party who worked with legacy formats, they'll tell you Microsoft essentially added angle brackets around the binary serialization in legacy formats. This makes for a very cool XML-based file format, not an international standard.

Tags: ecma-376 iso microsoft odf officeopenxml ooxml opendocument xml

Posted by: garyedwards