I know Patrick fairly well. And having worked with him on the OASIS ODF TC for the first five years of development, i have the utmost respect for his integrity. He is also a renown and respected expert regarding the standards process and the specification contenders. His public support of OOXML, coming as it did just prior to the Geneva BRM, has to be sourced in something of extraordinary substance and concern.
He knows full well that ISO approval of OOXML is the end of ODF. It's that simple.
He also knows that ODF has serious interoperability problems. In May of 2006, an ISO directive was issued insisting that ODF be brought into compliance with existing ISO Interoperability Requirements. Yet nothing to date has been done. Like OOXML, ODF is seriously lacking an interoperability framework compliant with ISO Interop Requirements. ODF 1.2 should have been out in December of 2007, but continues to languish. The OpenOffice source code consortia of vendors driving ODF (IBM, Sun, Novell and Google) show no signs whatsoever of fixing the interop problems that allow them to claim compliance in spite of the continued and unlimited use of undocumented eXtensions and application settings.
This has to be very disappointing to Patrick. The larger problem he faces though is that he can't vote against OOXML after allowing - supporting ISO approval of an ODF specification that refuses to conform with ISO Interoperability Requirements. The interop compliance problems with ODF had to be fixed BEFORE OOXML came up for vote.
So he is caught between a rock and a hard place. The ODF source code vendor consortia refuses to fix ODF interop because that would impact their use of undocumented and often proprietary eXtensions. Although Microsoft is reluctant to publicly discuss this ODF issue, no doubt they are quick to point this out to Patrick.
Here's the thing. ODF can be fixed at ISO. OOXML can not.
It is entirely possible for Patrick to use his ISO JTC-1 editors position to craft an interoperability framework that would bring ODF into compliance with ISO Interop Requirements, which are themselves required by GATT and WTO International Trade Agreements (among others:). If he really wanted too, Patrick is in a position to ram interop down the ODF vendor source code consortia throats.
OOXML on the other hand presents ISO with a very different situation. Because of the way the OOXML - Ecma charter is worded, i don't see how ISO JTC-1 could ever fix the OOXML interoperability problems. ISO approval of OOXML would include acceptance of a charter that defines and limits OOXML interoperability to whatever MSOffice determines it to be. If Patrick and the JTC-1 tried to bring OOXML into compliance with existing ISO Interoperability Requirements, they would have to somehow amend a charter duly approved.
Given that the JTC-1 has yet to address a two year old ISO directive regarding ODF interop compliance, what are the odds they will dare to amend an approved charter? Not good i think.
ISO approval of OOXML is a tragedy for all of us. For sure it's the end of ODF. It's perhaps the end of ISO as a respected standards organization. The issue of open standards itself will become a joke, with the reality of standards by corporation having us all wringing our hands in despair.
More importantly though, ISO approval of OOXML will break the Web. Microsoft will use OOXML to break from advancing W3C standards such as XHTML-2, CSS-3, SVG, XForms and RDF. These technologies are critical to the transition of complex documents to interactive web use. The MSOffice SDK beta demonstrates an easy to implement OOXML XAML converter. ISO approval of OOXML would establish MSOffice as a standards compliant "editor" for a proprietary MS Cloud of collaborative computing technologies driven by WPF specific XAML (fixed/flow), WPF, Silverlight, Winforms, XPS, and Smart Tags. All of which are proprietary replacements for W3C XHTML, CSS, SVG, XForms, CDF and RD
Maybe. I spent five years working with Patrick on OASIS OpenOffice ODF and have the utmost respect for his honesty. His integrity is beyond reproach. His wisdom and expertise much appreciated by all who worked with him on ODF.
Having said that though, it's also true that Patrick is a long term guy who fully believes that we can harmonize ODF and OOXML through a one to one mapping. He believes that complete documentation fully describing both the syntax and semantics will enable this mapping.
He also thinks that the way to beat the undo influence and control of big vendors and the consortia they forge is to outlast them. Market facing vendors will always value their right to innovate over the interoperability of standards. They limit interoperability to protect their market driven innovation needs. Patrick recognizes this inherent tension and believes that you can't fight it, but you can outlast the forces that value innovation over interop.
I disagree. Patrick compromised on ODF interoperability many a time, the ODF metadata "XML ID" issue being the final straw for me. Allowing Sun's OpenOffice/StarOffice team to determine which ODF elements can have "metadata" and which cannot is a bit much. And i see no evidence whatsoever that ODF interop can somehow be fixed in the future. The ODF source code consortia of Sun, IBM, Novel and Google (all vested in some version of the OOo source code) are not going to change what is for them a good thing.
ODF does not have an interoperability framework and there is little hope that anyone will be able to fix the hapless compliance clause that enables unlimited use of undocumented extensions. In such situations, interoperability is only possible where specific applications come to agreement.
For those who might doubt these statements, consider that KOffice has been a participating member of the OASIS OpenOffice ODF TC for over five years, and they still can't exchange documents with OpenOffice.
MSOOXML is similarly lacking an interoperability framework that has some compliance teeth. That MSOffice 2003 Compatibility Pack OOXML differs from MSOffice 2007 OOXML should not come as a surprise. Ecma and OASIS are both vendor consortia groups, where innovation trumps interoperability by design.
ISO is bound to the business of "interoperability", and has very strict guidelines for interoperability requirements, that are themselves tied to international trade agreements and legal conventions. In this context, it is beyond surprising that ISO allows the "OASIS PAS" and "Ecma Fast Track" channels to remain open, with specification work remaining under the controlling influence of the vendors.
IMHO, the change in Patrick's position is entirely due to the realization that it is impossible to map between OOXML and ODF. I don't know this for sure, but when i read the German Standards Group (DIN) report on harmonization, authorized by the EU-IDABC and provided to ISO, i couldn't help but wonder how Patrick would react. The report definitively ends his OOXML ODF mapping dream.
Many wonder why mapping is impossible. I had more than a few discussions with Patrick on this. His point was that a schema is a schema. As long as the syntax and semantics are fully documented, no problemo. My point is that both ODF and OOXML are application specific; and, both are woefully lacking in "semantic" documentation. Add to this problem that both ODF and OOXML lack an interoperability framework with any semblance of compliance teeth, and the whole mapping issue becomes an impossible solution. Especially if interop is the goal.
The sad truth is that ODF began life as an XML encoding of the OpenOffice/StarOffice in-memory-binary-representation. OOXML is a bit more complicated in that it is a combined XML encoding of many MSOffice versions binary dump. The salient point however is that both are XML encodings of an application specific binary dump. From there the "theoretical" challenge is to fully document the structural syntax,
Check out the MSOffice SDK beta and you'll find a nifty conversion component that can be called with a few lines of code. The component perfects a high fidelity conversion of OOXML documents to XAML (fixed/flow).
XAML is a proprietary WPF format that is a web ready alternative to W3C XHTML - CSS. Combined with Silverlight (check out TextGlow) and Smart Tags, XAML represents a proprietary challenge to W3C XHTML, CSS-3, SVG, RDF, CDF and/or RIA Adobe PDF - Flash/Flex/AIR.
Now note that IE-8 does not support XHTML, SVG, XForms or RDF. CSS support is limited to CSS 2.1.
Consider the integration advantage the MS Web Server Stack (Exchange/SharePoint/MS SQL Server) juggernaut has with some 500 million MSOffice-Outlook desktops, many of which anchor the client side of more than a few business processes.
Sadly, ISO approval of OOXML will stamp MSOffice as a standards compliant editor for the proprietary Microsoft cloud, setting the stage for a massive migration of existing desktop bound business processes to the MS Web Server Stack.
Interestingly, IE-8 will force W3C compliant web sights to dumb their documents down (HTML 5- CSS 2.1), reserving for Microsoft the realm of complex data rich business documents transitioning from legacy client/server information systems to an exclusive MS Web-Cloud business process management system of global collaborative computing reach.
Good thing Windows can't do cloud computing! But maybe the acquisition of Yahoo! will combine with the Viridian-on-Solaris Data Centers to cover that embarrassment?
The real threat to Microsoft has always been HTML. In the Iowa antitrust case there was discovered this interesting 1998 memo from Chairman Bill to the MSOffice development team:
"One thing we have got to change in our strategy - allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities."
"Anything else is suicide for our platform. This is a case where Office has to avoid doing something to destroy Windows."
"I would be glad to explain at greater length."
"Likewise, this love of DAV in Office/Exchange is a huge problem. I would also like to make sure people understand this as well."
The challenge for Microsoft is that of transitioning their monopoly base to the Web without losing control. This meant developing IE, Exchange, SharePoint, Windows Server, and MS SQL Server while fully protecting the integration channel to MSOffice/Outlook. At the heart of this strategy though is the dilemma of limiting HTML to consumer only web applications until such time as the business process management systems were ready.
Of course, there is also that little problem with continuing anti trust oversight. At the core of the Sherman Anti Trust Act is the issue of leveraging an existing monopoly into other markets.
Actually, we've recently finished our analysis and testing of CDF, the W3C's Compound Document Format, and it's a winner. We believe that we can fully convert all Microsoft bound documents, applications and processes to CDF using our da Vinci plugin.
da Vinci can convert MS docs, apps and processes to ODF 1.0, but only through a heavy reliance on the infamous Section 1.5 Conformance Clause - or wha tis otherwise known as the universal generic. This clause was put into ODF 1.0 expressly for the purpose of conversion of existing documents to ODF, and interoperability with existing applications. Microsoft documents and applications to be exact.
The problem is that OpenOffice.org and all of it's many offshoots, only partially implement the Conformance Clause (paragraphs and text spans only). So while we can say that ODF 1.0 is fully capable of handling anything MSOffice and the legacy of billions of binary documents can throw at it, there is zero interoperability with most other ODF ready applications. Which is not quite what the public expects.
After submitting our first version of da Vinci to Massachusetts on June 19th, 2006, we got to see up and close and personal why ODF was hanging by a thread in the great Commonwealth. Massachusetts had completed a year long Pilot Study involving the many variations of OpenOffice as a means of implementing the "mandated" ODF. The Pilot revealed the workgroup-workflow problem. And also that "rip out and replace" was not an acceptable solution.
To solve the Massachusetts problem, and save ODF, we had to do three things. The first of which was impossible. We had to hit a level of conversion fidelity that had never been achieved before. Incredibly, we did that - as demonstrated by the ACME 376 plugin. The ACME plugin is actually a demonstration of the internal da Vinci conversion process that was developed to meet the incredibly high fidelity needs of Massachusetts.
The next thing that had to be done was to establish an effective interoperability with OpenOffice; a workgroup - workflow business process integration that would fully enable OpenOffice desktops to participate in MSOffice bound business processes. To do this we would need OpenOffice to implement a set of interoperability eXtensions known as the iX" proposal.
Third, we had to get the iX proposal approved by the OASIS ODF TC.
We were able to overcome the first challenge, as demonstrated by ACME 376. We failed entirely on the second and third challenges.
Between July 13th and February 27th, a total of five comprehensive iX proposals were submitted to the OASIS ODF groups for discussion. Three variations of iX were submitted by the Foundation between mid July and early August of 2006. Massachusetts ITD signed off on all three.
The November 2006 and February 2007 comprehensive iX proposals were submitted by Novell, mostly to augment their work on the OOXML plugin for OpenOffice.
Although the interoperability eXtensions were vital to the success of ODF in Massachusetts, California, Denmark and Belgium, they failed to get any traction at the OASIS ODF TC. Issues of compatibility with existing Microsoft documents and interoperability with existing Microsoft applications are for the most part considered at OASIS to be outside the charter and beyond the scope of the ODF specification. In other words, it's a problem for Microsoft, and the converter - translator crowd, but not an OASIS ODF TC problem.
All development on da Vinci stopped on October 4th, 2006; the day Louis Gutierrez resigned. For all practical purposes, ODF was dead. And not just in Massachusetts. The entire world of government CIO's was watching. The failure to successfully implement ODF in Massachusetts was certain to have a world wide impact. And it did.
The important thing is this: governments are going to migrate their existing documents, applications and processes to XML. The only question is which XML? OOXML or ODF?
Regarding the traditional features of an Office Productivity Suite, with version 2.0 OpenOffice.org has, for the most part, reached parity with MS Office XP and MS Office System 12. Where they definitely part ways though is with how they are positioning to implement next generation Open Internet collaborative computing features and services.
The most important difference is that OOo faithfully implements open interfaces, protocols, and methods based on Open Standards and Open XML technologies. As a community, OOo is just as determined to keep the Internet open as Microsoft is to close it off by making assertions of ownership over key Internet protocols and methods. The favored business practice of "embrace, extend, and extinguish" is alive and well in Redmond. Chairman Bill has figured out that XML is the next generation API for the Internet. And while he can't "own" XML, he is trying to patent every possible way of using XML. Embrace and extend.
IMHO, the first battleground where OOo and MS Office Systems split concerns the use of Open Internet XML forms. Forms are the most basic unit of business information, and while electronic forms have been around a long time, there is nothing in the previous decades of electronic forms participation that approaches the collaborative explosion cooking with shared business process XML schemas and XForms.
XForms is of course the W3C Open XML standard. OOo v2.0 faithfully implements the XForms model, providing users with an interactive forms interface enabling the binding of any object on the form to such things as web services, XML data and content streams, Jabber XML router and P2P connections, data sources, content sources, DOM hierarchy elements, scripting and workflow routing controls, graphics and multi media, etc.
MS Office Systems "Professional" ships with InfoPath, which enables users to do pretty much the same thing as OOo XForms. Where they part ways is that the Microsoft forms model not only does not conform with the W3C Open XForms standard, but MS has bound all variations of MSXML with platform specific binary dependencies and the restrictive, patent encumbered MS XML Reference License. This license was designed to prevent file format interoperability with Open Source - Open Standards based efforts.
And then there is the troublesome issue of platform complexity, where all MS Office Systems initiatives get bound up in the transition from WinForms to the WinFS-XAML-MSXML model. Recently while at the JavaONE Conference, the vastness of this complexity of platform hardened integrated dependencies hit me.
I was watching another one of those very slick Ajax IDE demonstrations, and two MS guys come by, boldly announcing themselves, claiming credit for having invented Ajax, and of course demanding to see how this particular peon rich client implementation worked. As the young developer, "Charles" went through his demo, patiently breaking his routine wherever and answering all the MS questions, beads of sweat began to drip from his forehead. He kept his cool though, even as the condescension heated up. Finally he got to the really good stuff, dragging widgets onto the forms canvas, easily building real world interfaces and bindings, with perfect XML popping line after line in a second window.
The MS guys were increasingly conversing to each other, "Can we do that? Yeah, we can do that but..." When Charles knew he had them, he hit them with his coup de grace, "And this code will run in all the major browsers without any...."
When one of the MS guys responded that they can do that too, Charles asked him how? The answer was a qualified one, saying MS could do this as long as the entire.NET framework is present. On hearing this, the crowd of about fifteen people who had gathered to watch this showdown spontaneously broke out in laughter. The MS guys quickly thanked Charles and wished his company good luck, as they unceremoniously walked away.
I have a hard time accepting any other interpretation of Mr. Kriss' recent comments as anything but a compromise of his original intentions. He tried to explain the compromise in terms of extending the original policy mandate based on Open Standards and consideration of Open Source alternatives, to now include Open File Formats. But it just doesn't wash. The dark clouds from Redmond are moving, and there must be a ton of money raining down on Bean Town.
This part of the quote is troubling:
"....it is our expectation that the next iteration of the Open Format standard will include some Microsoft proprietary formats. These formats, like DOC files, will be deemed to be Open Formats because they will no longer have restrictions on their use....."
What "Open Format Standard" is he talking about? Clearly he's not referring to the OASIS/ISO OpenDocument. It's more likely that Mr. Kriss is about to declare Microsoft's proprietary file formats "open enough" to qualify as a Massachusetts only open format standard.
This is a very sad turn of events. The money must be flowing, and although Mr. Kriss made a valiant stand, given the political attacks underway there's little doubt he must be facing a flood of political corruption.
It seems to me that one of the mistakes Mr. Kriss made was in overlooking the powerful influence of open XML technologies. It's instructive that the EU Valoris Report effort recommended early on that the best way to meet the EU objectives of using open standards requirements to spawn a more competitive marketplace of information technologies, was to require a combination of open standards and open XML technologies. Especially concerning the file formats -the digital containers of computationally ready information.
The XML mandate is noticeably missing from the Massachusetts open standards - open source policy. So much so that it's hard to believe they are discussing the MS applications formats (.doc) instead of the MSXML option that was the issue in Europe.
With their focus on open XML technologies, in mid November of 2004 the EU was able to force a major concession from Microsoft, who no doubt was feeling the impact of being locked out of the current purchase cycle. Microsoft promised that "future versions" of their proprietary XML formats, and the MS XML Reference License that governs access and use of these formats, would meet the open standards - open XML requirements. They also promised the EU that they would work with Sun and other selected partners to provide "filters" enabling MS Office users to quickly transform from MS proprietary formats into the OASIS/ISO OpenDocument XML file format. (The only available file format specification that meets the EU requirements of open standard and open XML). Sun has promised that these filters will be open and accessible to all users and application providers.
I appreciate the fact that Mr. Kriss is so acutely aware of the need to have public information in a file format that will still be useful and accessible 200 years from now. But he seems to have missed some important points about how to get there.
One important point is that of truly separating the file format from the commanding application, and any platform dependencies that rule those applications. The Win32 API comes to mind. The OASIS/ISO OpenDocument standard goes far beyond the needs of inter application information exchange. The specification is for that of a truly portable file format, able to run with applications spanning across many platforms, including all of those in a future of collaborative computing that we can now only hardly imagine.
Another point is that we need to consider how best to pass our information into this future with the least amount of demands that would compromise the computational advances that take place on a daily basis. We've had 25 years of the costly compromising that comes from pl
There are no "StarOfficeisms" in the OASIS XML Open Document file format specification. Least ways not any we know of. By December of 2004, when the OASIS TC submitted the XML file format specification to ISO, all known references and anachronisms that might be called starisms were changed. Neutralizing changes were even made to such things as the file format extensions and mime type registrations. We even changed the name from OASIS Open Office to OASIS/ISO Open Document.
Separating the file format from any particular application or applications suite is a big deal. Especially if there is a rising demand from enterprise level end users for an applications independent universal structured file format solution. tty. Separating the file format from any particular application or applications suite is a big deal. Especially if there is a rising demand from enterprise level end users for an applications independent universal structured file format solution.
So the OASIS/ISO TC chose to keep that most powerful of technology terms, the word "Open", but lose the direct reference and/or suggestion to OpenOffice.org.
The second reason for changing the name to "OASIS Open Document" is far more interesting, and directly relates to the European Union "TAC/IDA" task force recommendations based on the infamous Valoris Report. You will recall that by September of 2004, the EU had evaluated responses from both Sun and Microsoft regarding the Valoris recommendation that all EU information system purchases be required to support an open standards based XML file format specification.
Microsoft's open XML proposal was determined by the EU to be "not open enough". This criticism was in the original Valoris Report, and not altered by subsequent Microsoft arguments. After much squealing, squawking, finger pointing, complaining and outrageous misrepresentation, in mid November of 2004 Microsoft finally conceded and agreed to meet EU requirements. More about this in a moment, but for now the important thing to note is that the EU held firm. A remarkable feat even though there is currently a range of cross platform alternative solutions that meet EU requirements, including the open and free OpenOffice.org, Sun's StarOffice, IBM's WorkPlace, and Novell's Open Office. And if Microsoft had not sold their share in Corel to a vulture investor outfit for pennies on the dollar, an investor who then proceeded to cut XML out of Corel, WordPerfect Office would also be OASIS/ISO XML compliant.
Meanwhile, the EU was also not entirely satisfied with the OASIS XML specification as explained in Sun's response to the EU requirements recommendation. Three things in particular concerned the EU.
First, that OASIS submit the file format specification to ISO. In September of 2004, OASIS management and the OASIS TC came to agreement with ISO that the file format specification would be submitted to ISO before years end, but maintenance and improvement would remain with the current OASIS TC. Hence the combo moniker "OASIS/ISO".
Second, there was a great deal of concern about "custom-defined schemas". Sometimes this issue is also referred to as "user-defined schemas". Others just call it a "forms" or "template" issue. Basically it refers to an applications ability to load (or consume) an externally defined schema template that might include specific user interfaces (forms), business - workgroup logic (routing), meta data interfaces, and other things related to the emerging world of collaborative computing.
Microsoft of course champions the auxiliary Office productivity application, InfoPath. However, in September of 2004, the OASIS TC finished work on extending the specification to include XForms, SVG, and SMiL. Current OOo -v.2 builds fully demonstrate the powerful capabilities of these extensions, including the binding of web services and data to graphical objects and forms/template widgets. Move over InfoPath. Hello OASIS UBL!
Damn those guys in Redmond are clever! Unethical, but oh so clever!
The facts are that Microsoft's entire product line was developed for a personal computing architecture. Clearly they are having problems moving from the vision of their early roots to that of a networked world. Microsoft systems are inherently insecure the moment they connect to any kind of network because they were designed for a different purpose. Maybe when all the talking about Longhorn ends, and the new architecture is finally released, Microsoft will be able to transition the user base to a truly network platform. But that's a ways off. And there are so many quarterly reports to be filed in the meantime.
The truth of this dilemma proves itself on a near weekly basis at incredible cost to the great monopolized herd of Windows users.
So if they can't "fix" the fundamental design flaws of their pc oriented architecture, the marketing masters of Redmond had to come up with perception fix. With this strategic leak of source code, Microsoft can now shift the "blame" to open source evil doers. It's brilliant!
Instead of the great herd blaming Microsoft for selling them shoddy products, that they are unable (or unwilling) to "fix", Microsoft can now point at evil robbers who have no respect for intellectual property (i.e. shoddy, half baked, woefully insecure and hap hazardly constructed software products that should never be connected to a network without the cover of a enormously precautious shell).
We all know Microsoft has two very big problems. One is security. The other is convincing an angry user base of over 450 million users to upgrade to the next generation of profitable products. When it comes to basic product features, the great herd is quite satisfied with the applications and systems they've already paid for. Except for one thing - security! They're mad that the products Microsoft sold them are so susceptible to misuse and abuse of all sorts. Susceptible the moment they connect to other computers.
So the challenge for Microsoft is to get out from under taking the heat, er, responsibility for their products, while shifting the blame to the only meaningful competition left standing. And do it in a way where the great herd finally accepts the bottom line engorging argument that the only way to resolve the security problems of end of life Windows systems is to upgrade enmass.
Of course Microsoft will officially downplay the "security" concerns about the released code, while putting the blame on open source evil doers who have no respect for intellectual property rights. The tech press has already taken the bait. We are guaranteed that from this day forward there will never, ever, be a MyDoom type story in the press that doesn't reference the release of this code. Security pundits and techsperts of all sorts are already preparing their power points and bulletin templates with this soon to be boilerplate message.
It's brilliant. The strategic release of this code paves the way for moving the installed base. It is exactly the woeful insecurity of those 450 million plus legacy Windows systems that will provide the impetus for force marching the great herd to the tightly bolted Windows XP Stack, rife with patent restricted interfaces, and yearly subscription licenses. A whole new generation of lock in, perfected at the expense of the only meaningful competition left standing - open source communities.
Recently, in a move that could eventually put SVG in mainstream usage, the OASIS Open Office XML File Format TC voted to "merge" the office suite file specification with the W3C SVG spec.
Based on the OpenOffice.org XML file specification, the current spec includes svg as used within the context of compound documents. "Merging" OOo XML with W3C SVG would mean a consistent model for naming elements, attributes, and actions, as the two specifications forge ahead into the future.
So why is this important? For SVG to reach critical mass it needs to be broadly "used". Gone are the days when any corporate entity, other than Microsoft, can reasonably expect to reach critical mass with a proprietary format. What Macromedia did with Flash is unlikely to happen again. It was the Flash plugin to Netscape that opened up the mass svg consumption channel, which is what was needed for Macromedia to corral and focus a new generation of graphical web developers. And even though Macromedia has met the new market realities of open source and open standards by opening swf and cloning JavaScript, an iron grip on the Flash core fla format absolutely guarantees the invasion of SVG into the graphical web application space. A deal with Microsoft could change things. Rumors abound. But Chairman Bill is holding all the cards. He can choose to ride the SVG wave, picking and choosing the date and time when Adobe, Corel, and Macromedia will be put to rest. Or, he can financially embrace the fla format, and change the rules of the game tomorrow. Either way though, the game of graphical web applications seems destined to turn on whichever contender reaches mass user "engagement" at the lowest level.
There's much to be said for creating next generation rich client side environments that collaborative web application developers can target. But for any rich client environment proposal to garner a critical mass of developers, there must be the certainty of promise that a critical mass of users hosting the basic components of a rich client side environment exists.
For sure there are many early pioneers, like Altio and Curl, trying to get some traction in this emerging market space. They at least have gotten enough attention that the big guys, those with considerable "deployment", and proven client side relationships, have joined the chase. Macromedia has it's "collaborative" graphical web proposal based on some 350 million Flash players sitting in rich client environments. Adobe is charging forward with a PDF based Acrobat model promising to make the full Adobe suite of graphical applications an integrated environment. Sun is finally getting serious about putting a rich target Java environment down on the desktop, the problems with swing not withstanding. Corel is pouring everything they've got into open standards, hoping to ride the fourth wave back to prominence. Microsoft has an incredibly rich environment brewing in the XP Stack and.NET juggernaut, but it's not likely to be either cross platform, inter operable, or integration friendly. Which is like saying the Microsoft collaborative environment will be fundamentally Internet adverse, only working within the boundaries of the XP Stack.
The OOo community vehemently argues that OOo.org and Mozilla.org create an environment as rich a graphical developers target as is out there. They take the challenge of the XP Stack model so seriously that recently both a server side component (OpenGroupware.org) and a client side Outlook alternative (the Glow Project) were introduced. It's not enough for OOo.org to challenge Microsoft as an office productivity suite. All aspects of the XP stack model must be countered by an Open Stack alternative if users are to truly have a choice regarding the next generation of collaborative computing.
The OOo UNO universal network object interface model has been optimized for both Java and Python. Can XUL be far behind?
Putting SVG at the core of the Open Office XML file format offers SVG d
Slashdot Mirror
I know Patrick fairly well. And having worked with him on the OASIS ODF TC for the first five years of development, i have the utmost respect for his integrity. He is also a renown and respected expert regarding the standards process and the specification contenders. His public support of OOXML, coming as it did just prior to the Geneva BRM, has to be sourced in something of extraordinary substance and concern.
:). If he really wanted too, Patrick is in a position to ram interop down the ODF vendor source code consortia throats.
He knows full well that ISO approval of OOXML is the end of ODF. It's that simple.
He also knows that ODF has serious interoperability problems. In May of 2006, an ISO directive was issued insisting that ODF be brought into compliance with existing ISO Interoperability Requirements. Yet nothing to date has been done. Like OOXML, ODF is seriously lacking an interoperability framework compliant with ISO Interop Requirements. ODF 1.2 should have been out in December of 2007, but continues to languish. The OpenOffice source code consortia of vendors driving ODF (IBM, Sun, Novell and Google) show no signs whatsoever of fixing the interop problems that allow them to claim compliance in spite of the continued and unlimited use of undocumented eXtensions and application settings.
This has to be very disappointing to Patrick. The larger problem he faces though is that he can't vote against OOXML after allowing - supporting ISO approval of an ODF specification that refuses to conform with ISO Interoperability Requirements. The interop compliance problems with ODF had to be fixed BEFORE OOXML came up for vote.
So he is caught between a rock and a hard place. The ODF source code vendor consortia refuses to fix ODF interop because that would impact their use of undocumented and often proprietary eXtensions. Although Microsoft is reluctant to publicly discuss this ODF issue, no doubt they are quick to point this out to Patrick.
Here's the thing. ODF can be fixed at ISO. OOXML can not.
It is entirely possible for Patrick to use his ISO JTC-1 editors position to craft an interoperability framework that would bring ODF into compliance with ISO Interop Requirements, which are themselves required by GATT and WTO International Trade Agreements (among others
OOXML on the other hand presents ISO with a very different situation. Because of the way the OOXML - Ecma charter is worded, i don't see how ISO JTC-1 could ever fix the OOXML interoperability problems. ISO approval of OOXML would include acceptance of a charter that defines and limits OOXML interoperability to whatever MSOffice determines it to be. If Patrick and the JTC-1 tried to bring OOXML into compliance with existing ISO Interoperability Requirements, they would have to somehow amend a charter duly approved.
Given that the JTC-1 has yet to address a two year old ISO directive regarding ODF interop compliance, what are the odds they will dare to amend an approved charter? Not good i think.
ISO approval of OOXML is a tragedy for all of us. For sure it's the end of ODF. It's perhaps the end of ISO as a respected standards organization. The issue of open standards itself will become a joke, with the reality of standards by corporation having us all wringing our hands in despair.
More importantly though, ISO approval of OOXML will break the Web. Microsoft will use OOXML to break from advancing W3C standards such as XHTML-2, CSS-3, SVG, XForms and RDF. These technologies are critical to the transition of complex documents to interactive web use. The MSOffice SDK beta demonstrates an easy to implement OOXML XAML converter. ISO approval of OOXML would establish MSOffice as a standards compliant "editor" for a proprietary MS Cloud of collaborative computing technologies driven by WPF specific XAML (fixed/flow), WPF, Silverlight, Winforms, XPS, and Smart Tags. All of which are proprietary replacements for W3C XHTML, CSS, SVG, XForms, CDF and RD
Maybe. I spent five years working with Patrick on OASIS OpenOffice ODF and have the utmost respect for his honesty. His integrity is beyond reproach. His wisdom and expertise much appreciated by all who worked with him on ODF.
Having said that though, it's also true that Patrick is a long term guy who fully believes that we can harmonize ODF and OOXML through a one to one mapping. He believes that complete documentation fully describing both the syntax and semantics will enable this mapping.
He also thinks that the way to beat the undo influence and control of big vendors and the consortia they forge is to outlast them. Market facing vendors will always value their right to innovate over the interoperability of standards. They limit interoperability to protect their market driven innovation needs. Patrick recognizes this inherent tension and believes that you can't fight it, but you can outlast the forces that value innovation over interop.
I disagree. Patrick compromised on ODF interoperability many a time, the ODF metadata "XML ID" issue being the final straw for me. Allowing Sun's OpenOffice/StarOffice team to determine which ODF elements can have "metadata" and which cannot is a bit much. And i see no evidence whatsoever that ODF interop can somehow be fixed in the future. The ODF source code consortia of Sun, IBM, Novel and Google (all vested in some version of the OOo source code) are not going to change what is for them a good thing.
ODF does not have an interoperability framework and there is little hope that anyone will be able to fix the hapless compliance clause that enables unlimited use of undocumented extensions. In such situations, interoperability is only possible where specific applications come to agreement.
For those who might doubt these statements, consider that KOffice has been a participating member of the OASIS OpenOffice ODF TC for over five years, and they still can't exchange documents with OpenOffice.
MSOOXML is similarly lacking an interoperability framework that has some compliance teeth. That MSOffice 2003 Compatibility Pack OOXML differs from MSOffice 2007 OOXML should not come as a surprise. Ecma and OASIS are both vendor consortia groups, where innovation trumps interoperability by design.
ISO is bound to the business of "interoperability", and has very strict guidelines for interoperability requirements, that are themselves tied to international trade agreements and legal conventions. In this context, it is beyond surprising that ISO allows the "OASIS PAS" and "Ecma Fast Track" channels to remain open, with specification work remaining under the controlling influence of the vendors.
IMHO, the change in Patrick's position is entirely due to the realization that it is impossible to map between OOXML and ODF. I don't know this for sure, but when i read the German Standards Group (DIN) report on harmonization, authorized by the EU-IDABC and provided to ISO, i couldn't help but wonder how Patrick would react. The report definitively ends his OOXML ODF mapping dream.
Many wonder why mapping is impossible. I had more than a few discussions with Patrick on this. His point was that a schema is a schema. As long as the syntax and semantics are fully documented, no problemo. My point is that both ODF and OOXML are application specific; and, both are woefully lacking in "semantic" documentation. Add to this problem that both ODF and OOXML lack an interoperability framework with any semblance of compliance teeth, and the whole mapping issue becomes an impossible solution. Especially if interop is the goal.
The sad truth is that ODF began life as an XML encoding of the OpenOffice/StarOffice in-memory-binary-representation. OOXML is a bit more complicated in that it is a combined XML encoding of many MSOffice versions binary dump. The salient point however is that both are XML encodings of an application specific binary dump. From there the "theoretical" challenge is to fully document the structural syntax,
Au Contraire Mon Ami. It's all about the Web.
Check out the MSOffice SDK beta and you'll find a nifty conversion component that can be called with a few lines of code. The component perfects a high fidelity conversion of OOXML documents to XAML (fixed/flow).
XAML is a proprietary WPF format that is a web ready alternative to W3C XHTML - CSS. Combined with Silverlight (check out TextGlow) and Smart Tags, XAML represents a proprietary challenge to W3C XHTML, CSS-3, SVG, RDF, CDF and/or RIA Adobe PDF - Flash/Flex/AIR.
Now note that IE-8 does not support XHTML, SVG, XForms or RDF. CSS support is limited to CSS 2.1.
Consider the integration advantage the MS Web Server Stack (Exchange/SharePoint/MS SQL Server) juggernaut has with some 500 million MSOffice-Outlook desktops, many of which anchor the client side of more than a few business processes.
Sadly, ISO approval of OOXML will stamp MSOffice as a standards compliant editor for the proprietary Microsoft cloud, setting the stage for a massive migration of existing desktop bound business processes to the MS Web Server Stack.
Interestingly, IE-8 will force W3C compliant web sights to dumb their documents down (HTML 5- CSS 2.1), reserving for Microsoft the realm of complex data rich business documents transitioning from legacy client/server information systems to an exclusive MS Web-Cloud business process management system of global collaborative computing reach.
Good thing Windows can't do cloud computing! But maybe the acquisition of Yahoo! will combine with the Viridian-on-Solaris Data Centers to cover that embarrassment?
The real threat to Microsoft has always been HTML. In the Iowa antitrust case there was discovered this interesting 1998 memo from Chairman Bill to the MSOffice development team:
The challenge for Microsoft is that of transitioning their monopoly base to the Web without losing control. This meant developing IE, Exchange, SharePoint, Windows Server, and MS SQL Server while fully protecting the integration channel to MSOffice/Outlook. At the heart of this strategy though is the dilemma of limiting HTML to consumer only web applications until such time as the business process management systems were ready.
Of course, there is also that little problem with continuing anti trust oversight. At the core of the Sherman Anti Trust Act is the issue of leveraging an existing monopoly into other markets.
Hope this helps,
~ge~All i have to do is look at the Windows Update button and my computer starts screaming,
"DON'T TASE ME, BRO.....DON'T TASE ME!"
~ge~
Actually, we've recently finished our analysis and testing of CDF, the W3C's Compound Document Format, and it's a winner. We believe that we can fully convert all Microsoft bound documents, applications and processes to CDF using our da Vinci plugin.
da Vinci can convert MS docs, apps and processes to ODF 1.0, but only through a heavy reliance on the infamous Section 1.5 Conformance Clause - or wha tis otherwise known as the universal generic. This clause was put into ODF 1.0 expressly for the purpose of conversion of existing documents to ODF, and interoperability with existing applications. Microsoft documents and applications to be exact.
The problem is that OpenOffice.org and all of it's many offshoots, only partially implement the Conformance Clause (paragraphs and text spans only). So while we can say that ODF 1.0 is fully capable of handling anything MSOffice and the legacy of billions of binary documents can throw at it, there is zero interoperability with most other ODF ready applications. Which is not quite what the public expects.
After submitting our first version of da Vinci to Massachusetts on June 19th, 2006, we got to see up and close and personal why ODF was hanging by a thread in the great Commonwealth. Massachusetts had completed a year long Pilot Study involving the many variations of OpenOffice as a means of implementing the "mandated" ODF. The Pilot revealed the workgroup-workflow problem. And also that "rip out and replace" was not an acceptable solution.
To solve the Massachusetts problem, and save ODF, we had to do three things. The first of which was impossible. We had to hit a level of conversion fidelity that had never been achieved before. Incredibly, we did that - as demonstrated by the ACME 376 plugin. The ACME plugin is actually a demonstration of the internal da Vinci conversion process that was developed to meet the incredibly high fidelity needs of Massachusetts.
The next thing that had to be done was to establish an effective interoperability with OpenOffice; a workgroup - workflow business process integration that would fully enable OpenOffice desktops to participate in MSOffice bound business processes. To do this we would need OpenOffice to implement a set of interoperability eXtensions known as the iX" proposal.
Third, we had to get the iX proposal approved by the OASIS ODF TC.
We were able to overcome the first challenge, as demonstrated by ACME 376. We failed entirely on the second and third challenges.
Between July 13th and February 27th, a total of five comprehensive iX proposals were submitted to the OASIS ODF groups for discussion. Three variations of iX were submitted by the Foundation between mid July and early August of 2006. Massachusetts ITD signed off on all three.
The November 2006 and February 2007 comprehensive iX proposals were submitted by Novell, mostly to augment their work on the OOXML plugin for OpenOffice.
Although the interoperability eXtensions were vital to the success of ODF in Massachusetts, California, Denmark and Belgium, they failed to get any traction at the OASIS ODF TC. Issues of compatibility with existing Microsoft documents and interoperability with existing Microsoft applications are for the most part considered at OASIS to be outside the charter and beyond the scope of the ODF specification. In other words, it's a problem for Microsoft, and the converter - translator crowd, but not an OASIS ODF TC problem.
All development on da Vinci stopped on October 4th, 2006; the day Louis Gutierrez resigned. For all practical purposes, ODF was dead. And not just in Massachusetts. The entire world of government CIO's was watching. The failure to successfully implement ODF in Massachusetts was certain to have a world wide impact. And it did.
The important thing is this: governments are going to migrate their existing documents, applications and processes to XML. The only question is which XML? OOXML or ODF?
Microsoft provides a high fidelity O
Regarding the traditional features of an Office Productivity Suite, with version 2.0 OpenOffice.org has, for the most part, reached parity with MS Office XP and MS Office System 12. Where they definitely part ways though is with how they are positioning to implement next generation Open Internet collaborative computing features and services.
...."
.NET framework is present. On hearing this, the crowd of about fifteen people who had gathered to watch this showdown spontaneously broke out in laughter. The MS guys quickly thanked Charles and wished his company good luck, as they unceremoniously walked away.
The most important difference is that OOo faithfully implements open interfaces, protocols, and methods based on Open Standards and Open XML technologies. As a community, OOo is just as determined to keep the Internet open as Microsoft is to close it off by making assertions of ownership over key Internet protocols and methods. The favored business practice of "embrace, extend, and extinguish" is alive and well in Redmond. Chairman Bill has figured out that XML is the next generation API for the Internet. And while he can't "own" XML, he is trying to patent every possible way of using XML. Embrace and extend.
IMHO, the first battleground where OOo and MS Office Systems split concerns the use of Open Internet XML forms. Forms are the most basic unit of business information, and while electronic forms have been around a long time, there is nothing in the previous decades of electronic forms participation that approaches the collaborative explosion cooking with shared business process XML schemas and XForms.
XForms is of course the W3C Open XML standard. OOo v2.0 faithfully implements the XForms model, providing users with an interactive forms interface enabling the binding of any object on the form to such things as web services, XML data and content streams, Jabber XML router and P2P connections, data sources, content sources, DOM hierarchy elements, scripting and workflow routing controls, graphics and multi media, etc.
MS Office Systems "Professional" ships with InfoPath, which enables users to do pretty much the same thing as OOo XForms. Where they part ways is that the Microsoft forms model not only does not conform with the W3C Open XForms standard, but MS has bound all variations of MSXML with platform specific binary dependencies and the restrictive, patent encumbered MS XML Reference License. This license was designed to prevent file format interoperability with Open Source - Open Standards based efforts.
And then there is the troublesome issue of platform complexity, where all MS Office Systems initiatives get bound up in the transition from WinForms to the WinFS-XAML-MSXML model. Recently while at the JavaONE Conference, the vastness of this complexity of platform hardened integrated dependencies hit me.
I was watching another one of those very slick Ajax IDE demonstrations, and two MS guys come by, boldly announcing themselves, claiming credit for having invented Ajax, and of course demanding to see how this particular peon rich client implementation worked. As the young developer, "Charles" went through his demo, patiently breaking his routine wherever and answering all the MS questions, beads of sweat began to drip from his forehead. He kept his cool though, even as the condescension heated up. Finally he got to the really good stuff, dragging widgets onto the forms canvas, easily building real world interfaces and bindings, with perfect XML popping line after line in a second window.
The MS guys were increasingly conversing to each other, "Can we do that? Yeah, we can do that but..." When Charles knew he had them, he hit them with his coup de grace, "And this code will run in all the major browsers without any
When one of the MS guys responded that they can do that too, Charles asked him how? The answer was a qualified one, saying MS could do this as long as the entire
Earlier this year IBM
I have a hard time accepting any other interpretation of Mr. Kriss' recent comments as anything but a compromise of his original intentions. He tried to explain the compromise in terms of extending the original policy mandate based on Open Standards and consideration of Open Source alternatives, to now include Open File Formats. But it just doesn't wash. The dark clouds from Redmond are moving, and there must be a ton of money raining down on Bean Town.
This part of the quote is troubling: "....it is our expectation that the next iteration of the Open Format standard will include some Microsoft proprietary formats. These formats, like DOC files, will be deemed to be Open Formats because they will no longer have restrictions on their use....."
What "Open Format Standard" is he talking about? Clearly he's not referring to the OASIS/ISO OpenDocument. It's more likely that Mr. Kriss is about to declare Microsoft's proprietary file formats "open enough" to qualify as a Massachusetts only open format standard.
This is a very sad turn of events. The money must be flowing, and although Mr. Kriss made a valiant stand, given the political attacks underway there's little doubt he must be facing a flood of political corruption.
It seems to me that one of the mistakes Mr. Kriss made was in overlooking the powerful influence of open XML technologies. It's instructive that the EU Valoris Report effort recommended early on that the best way to meet the EU objectives of using open standards requirements to spawn a more competitive marketplace of information technologies, was to require a combination of open standards and open XML technologies. Especially concerning the file formats -the digital containers of computationally ready information.
The XML mandate is noticeably missing from the Massachusetts open standards - open source policy. So much so that it's hard to believe they are discussing the MS applications formats (.doc) instead of the MSXML option that was the issue in Europe.
With their focus on open XML technologies, in mid November of 2004 the EU was able to force a major concession from Microsoft, who no doubt was feeling the impact of being locked out of the current purchase cycle. Microsoft promised that "future versions" of their proprietary XML formats, and the MS XML Reference License that governs access and use of these formats, would meet the open standards - open XML requirements. They also promised the EU that they would work with Sun and other selected partners to provide "filters" enabling MS Office users to quickly transform from MS proprietary formats into the OASIS/ISO OpenDocument XML file format. (The only available file format specification that meets the EU requirements of open standard and open XML). Sun has promised that these filters will be open and accessible to all users and application providers.
I appreciate the fact that Mr. Kriss is so acutely aware of the need to have public information in a file format that will still be useful and accessible 200 years from now. But he seems to have missed some important points about how to get there.
One important point is that of truly separating the file format from the commanding application, and any platform dependencies that rule those applications. The Win32 API comes to mind. The OASIS/ISO OpenDocument standard goes far beyond the needs of inter application information exchange. The specification is for that of a truly portable file format, able to run with applications spanning across many platforms, including all of those in a future of collaborative computing that we can now only hardly imagine.
Another point is that we need to consider how best to pass our information into this future with the least amount of demands that would compromise the computational advances that take place on a daily basis. We've had 25 years of the costly compromising that comes from pl
There are no "StarOfficeisms" in the OASIS XML Open Document file format specification. Least ways not any we know of. By December of 2004, when the OASIS TC submitted the XML file format specification to ISO, all known references and anachronisms that might be called starisms were changed. Neutralizing changes were even made to such things as the file format extensions and mime type registrations. We even changed the name from OASIS Open Office to OASIS/ISO Open Document.
Separating the file format from any particular application or applications suite is a big deal. Especially if there is a rising demand from enterprise level end users for an applications independent universal structured file format solution. tty. Separating the file format from any particular application or applications suite is a big deal. Especially if there is a rising demand from enterprise level end users for an applications independent universal structured file format solution.
So the OASIS/ISO TC chose to keep that most powerful of technology terms, the word "Open", but lose the direct reference and/or suggestion to OpenOffice.org.
The second reason for changing the name to "OASIS Open Document" is far more interesting, and directly relates to the European Union "TAC/IDA" task force recommendations based on the infamous Valoris Report. You will recall that by September of 2004, the EU had evaluated responses from both Sun and Microsoft regarding the Valoris recommendation that all EU information system purchases be required to support an open standards based XML file format specification.
Microsoft's open XML proposal was determined by the EU to be "not open enough". This criticism was in the original Valoris Report, and not altered by subsequent Microsoft arguments. After much squealing, squawking, finger pointing, complaining and outrageous misrepresentation, in mid November of 2004 Microsoft finally conceded and agreed to meet EU requirements. More about this in a moment, but for now the important thing to note is that the EU held firm. A remarkable feat even though there is currently a range of cross platform alternative solutions that meet EU requirements, including the open and free OpenOffice.org, Sun's StarOffice, IBM's WorkPlace, and Novell's Open Office. And if Microsoft had not sold their share in Corel to a vulture investor outfit for pennies on the dollar, an investor who then proceeded to cut XML out of Corel, WordPerfect Office would also be OASIS/ISO XML compliant.
Meanwhile, the EU was also not entirely satisfied with the OASIS XML specification as explained in Sun's response to the EU requirements recommendation. Three things in particular concerned the EU.
First, that OASIS submit the file format specification to ISO. In September of 2004, OASIS management and the OASIS TC came to agreement with ISO that the file format specification would be submitted to ISO before years end, but maintenance and improvement would remain with the current OASIS TC. Hence the combo moniker "OASIS/ISO".
Second, there was a great deal of concern about "custom-defined schemas". Sometimes this issue is also referred to as "user-defined schemas". Others just call it a "forms" or "template" issue. Basically it refers to an applications ability to load (or consume) an externally defined schema template that might include specific user interfaces (forms), business - workgroup logic (routing), meta data interfaces, and other things related to the emerging world of collaborative computing.
Microsoft of course champions the auxiliary Office productivity application, InfoPath. However, in September of 2004, the OASIS TC finished work on extending the specification to include XForms, SVG, and SMiL. Current OOo -v.2 builds fully demonstrate the powerful capabilities of these extensions, including the binding of web services and data to graphical objects and forms/template widgets. Move over InfoPath. Hello OASIS UBL!
The third issue involves EU concerns fo
Damn those guys in Redmond are clever! Unethical, but oh so clever!
The facts are that Microsoft's entire product line was developed for a personal computing architecture. Clearly they are having problems moving from the vision of their early roots to that of a networked world. Microsoft systems are inherently insecure the moment they connect to any kind of network because they were designed for a different purpose. Maybe when all the talking about Longhorn ends, and the new architecture is finally released, Microsoft will be able to transition the user base to a truly network platform. But that's a ways off. And there are so many quarterly reports to be filed in the meantime.
The truth of this dilemma proves itself on a near weekly basis at incredible cost to the great monopolized herd of Windows users.
So if they can't "fix" the fundamental design flaws of their pc oriented architecture, the marketing masters of Redmond had to come up with perception fix. With this strategic leak of source code, Microsoft can now shift the "blame" to open source evil doers. It's brilliant!
Instead of the great herd blaming Microsoft for selling them shoddy products, that they are unable (or unwilling) to "fix", Microsoft can now point at evil robbers who have no respect for intellectual property (i.e. shoddy, half baked, woefully insecure and hap hazardly constructed software products that should never be connected to a network without the cover of a enormously precautious shell).
We all know Microsoft has two very big problems. One is security. The other is convincing an angry user base of over 450 million users to upgrade to the next generation of profitable products. When it comes to basic product features, the great herd is quite satisfied with the applications and systems they've already paid for. Except for one thing - security! They're mad that the products Microsoft sold them are so susceptible to misuse and abuse of all sorts. Susceptible the moment they connect to other computers.
So the challenge for Microsoft is to get out from under taking the heat, er, responsibility for their products, while shifting the blame to the only meaningful competition left standing. And do it in a way where the great herd finally accepts the bottom line engorging argument that the only way to resolve the security problems of end of life Windows systems is to upgrade enmass.
Of course Microsoft will officially downplay the "security" concerns about the released code, while putting the blame on open source evil doers who have no respect for intellectual property rights. The tech press has already taken the bait. We are guaranteed that from this day forward there will never, ever, be a MyDoom type story in the press that doesn't reference the release of this code. Security pundits and techsperts of all sorts are already preparing their power points and bulletin templates with this soon to be boilerplate message.
It's brilliant. The strategic release of this code paves the way for moving the installed base. It is exactly the woeful insecurity of those 450 million plus legacy Windows systems that will provide the impetus for force marching the great herd to the tightly bolted Windows XP Stack, rife with patent restricted interfaces, and yearly subscription licenses. A whole new generation of lock in, perfected at the expense of the only meaningful competition left standing - open source communities.
It's brilliant! It's end game.
~ge~
Recently, in a move that could eventually put SVG in mainstream usage, the OASIS Open Office XML File Format TC voted to "merge" the office suite file specification with the W3C SVG spec.
.NET juggernaut, but it's not likely to be either cross platform, inter operable, or integration friendly. Which is like saying the Microsoft collaborative environment will be fundamentally Internet adverse, only working within the boundaries of the XP Stack.
Based on the OpenOffice.org XML file specification, the current spec includes svg as used within the context of compound documents. "Merging" OOo XML with W3C SVG would mean a consistent model for naming elements, attributes, and actions, as the two specifications forge ahead into the future.
So why is this important? For SVG to reach critical mass it needs to be broadly "used". Gone are the days when any corporate entity, other than Microsoft, can reasonably expect to reach critical mass with a proprietary format. What Macromedia did with Flash is unlikely to happen again. It was the Flash plugin to Netscape that opened up the mass svg consumption channel, which is what was needed for Macromedia to corral and focus a new generation of graphical web developers. And even though Macromedia has met the new market realities of open source and open standards by opening swf and cloning JavaScript, an iron grip on the Flash core fla format absolutely guarantees the invasion of SVG into the graphical web application space. A deal with Microsoft could change things. Rumors abound. But Chairman Bill is holding all the cards. He can choose to ride the SVG wave, picking and choosing the date and time when Adobe, Corel, and Macromedia will be put to rest. Or, he can financially embrace the fla format, and change the rules of the game tomorrow. Either way though, the game of graphical web applications seems destined to turn on whichever contender reaches mass user "engagement" at the lowest level.
There's much to be said for creating next generation rich client side environments that collaborative web application developers can target. But for any rich client environment proposal to garner a critical mass of developers, there must be the certainty of promise that a critical mass of users hosting the basic components of a rich client side environment exists.
For sure there are many early pioneers, like Altio and Curl, trying to get some traction in this emerging market space. They at least have gotten enough attention that the big guys, those with considerable "deployment", and proven client side relationships, have joined the chase. Macromedia has it's "collaborative" graphical web proposal based on some 350 million Flash players sitting in rich client environments. Adobe is charging forward with a PDF based Acrobat model promising to make the full Adobe suite of graphical applications an integrated environment. Sun is finally getting serious about putting a rich target Java environment down on the desktop, the problems with swing not withstanding. Corel is pouring everything they've got into open standards, hoping to ride the fourth wave back to prominence. Microsoft has an incredibly rich environment brewing in the XP Stack and
The OOo community vehemently argues that OOo.org and Mozilla.org create an environment as rich a graphical developers target as is out there. They take the challenge of the XP Stack model so seriously that recently both a server side component (OpenGroupware.org) and a client side Outlook alternative (the Glow Project) were introduced. It's not enough for OOo.org to challenge Microsoft as an office productivity suite. All aspects of the XP stack model must be countered by an Open Stack alternative if users are to truly have a choice regarding the next generation of collaborative computing.
The OOo UNO universal network object interface model has been optimized for both Java and Python. Can XUL be far behind?
Putting SVG at the core of the Open Office XML file format offers SVG d