The recent bomb in the ODF world from Gary Edward’s claims that Sun successfully blocked the addition of features to ODF that would be needed for full interchange with Office are explosive not only because they demonstrate how ODF was (properly, in my view) developed to cope with the particular features of the participants, not really as a universal format, but also because the prop up Microsoft’s position that Open XML is required because it exposes particular features that ISO ODF is not capable of exposing. Both because ODF is still in progress and because sometimes the features are simply incompatible in the details.
Group items tagged
Can a file be ODF and Open XML at the same time? (and HTML? and a Java servlet? and a P... - 0 views
-
-
Actually, ODF is about to get a new manifest along with the new metadata stuff. Because we base that on RDF, the manifest will also be RDF-based. It gives us the extensibility we want to provide (extension developers, for example, can add extra metadata they may need), without having to worry about breaking compatibility. The primary addition we've made is a mechanism to bind a stable URI to in-document content node ids and files. This is conceptually not all that different than what I see in OPC; it's just that the unique IDs are in fact URIs. Among other things, in the RDF context that allows further statements to be bound to those URIs. Bruce D'Arcus | July 29, 2007 01:02 PM
-
What Bruce doesn't explain in this highlighted clip is that Sun decided to limit the "extra metadata" developer might need to just a handful of elements Sun and IBM needed to use in OpenOffice. The original OpenDocument Foundation metadata proposal was to open up the use of metadata to the extent that metadata could be used for all aspects of presentation (formatting AND layout!).
-
This vendor specific - application specific limiting ended the last hope we had for ODF interoperability and backwards compatibility with the billions of "in-process" MSOffice documents known to be populating business processes the world over. In fact, the problem ODF adoption faces is primarily that of MSOffice bound business processes, reflected in these billions of workgroup-workflow documents.
-
Proposal to have a standard packaging for combining application specific XML formats, Open HTML, and PDF. Great comments. This July 2007 article links to a January 2009 article: http://broadcast.oreilly.com/2009/01/packaging-formats-of-famous-ap.html
IBM undeterred by setbacks to ODF adoption | InfoWorld | News | 2007-06-08 | By China M... - 0 views
-
You might think the steady defeat of bills in several U.S. states to mandate the use of free interoperable file formats might dampen the spirits of IBM, one of the prime supporters of ODF (OpenDocument Format). Far from it, said IBM's Bob Sutor, who sees the recent news as par for the course in the evolution of any open standard.
-
Thus spoke the little Dutch Boy, his finger in the dike, his confidence large. Meanwhile, people with half a brain were heading for the high ground. California, Texas, Massachusetts and the EU IDABC come to mind. Hello bob! Can you say ODEF?
Mass. Set to Mix Office With ODF - 0 views
-
Massachusetts last week officially confirmed that its executive agencies for now will continue using Microsoft Office instead of switching to alternative desktop applications. But by Jan. 1, in keeping with a controversial policy announced last year, the state plans to start adding plug-in software that will let its Office users create and save files in the industry-standard OpenDocument format.
-
The August 28th, 2006 article about Massachusetts decision to use addon plugins. ComputerWorld - Caarol Sliwa
GullFOSS - 0 views
-
When such new features that enhance the interoperability require enhancements to the Open Document file format we will propose the necessary changes to the OASIS Open Document TC. This way not only OpenOffice.org but also Open Document benefits from our efforts. Florian Reuter, who now works for Novell, lists some of the changes we have in mind in his blog . So there are a lot of common ideas how we can improve the interoperability between OpenOffice.org and Microsoft Word documents and I hope we can work together with Florian here.
-
The chuckleheads at Sun's StarOffice/OpenOffice Hamburg office respond to Florian's comprehensive lis tof suggestions to greatly improve ODF interoperability.
EU-IDABC ODEF Workshop 2007 in Berlin - Documentation - presentations - 0 views
-
As information exchange in and with public administrations is very often bound to documents, editing, archiving and exchange possibilities for documents are crucial for the optimum function of administrations, both in terms of practicality and cost. Initiatives such as the PEGSCO Recommendations on Open Document Formats published by the IDABC Management Committee, demonstrate public administrations preference for "open" document exchange and storage formats that are subject to formal standardisation via international standardisation procedures. The primary objectives of the Berlin event, held at the German Federal Ministry of the Interior (BMI), were to: compile further input from Member State public administrations on their experiences and strategies on ODEF gather industry viewpoints on the initiatives relating to ODEF standardization and information on future standardisation developments provide a platform for exchange between stakeholders in public administrations and main industry players The program of the workshop included, among other: ODEF Strategies: Examples from European Administration Practical Experiences with the implementation of ODEF Report on ODEF-Standardisation activities 4 parallel sessions with participants A panel discussion with stakeholders
-
IDABC ODEF Workshop 2007 in Berlin
-
ODF officially died on February 28, 2007, at the Advanced eGovernment Conference in Berlin. Hellow ODEF
Microsoft Watch Finally Gets it - It's the Business Applications!- Obla De OBA Da - 1 views
-
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
-
-
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 en
-
-
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 i
-
- ...6 more annotations...
-
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. <br
File-Format Fistfight | Redmond Developer News - 0 views
-
Gary Edwards, president of the OpenDocument Foundation, flatly stated to me that any effort to "peel away the politics" in this debate was doomed to fail. Another very prominent member of the open source development community refused to comment on the record due to the sheer acrimony he's faced in this debate. And my newsletter articles, which have been generally critical of Microsoft's stance in this area, have drawn a significant amount of ire.
-
More great stuff from Michael Desmond
The X Factor: ODF, OOXML, CDF | Redmond Developer News - 0 views
-
XML expert, consultant and Microsoft MVP Don Demsak argues that both technologies share a fundamental flaw-they're not really striving to be standards at all. "I think this whole OOXML versus ODF thing is a non-issue. Both formats are just serialization formats for the object models they're associated with, and are not designed as impartial, interoperable formats," Demsak writes in an e-mail. Gary Edwards, president of the OpenDocument Foundation, which drives ODF development, believes codified document standards should not carry forward old flaws and application nuances. "The world is not a clean slate, but it's going to somehow make that transition of existing documents, applications and processes to XML," he says in an e-mail. "To us, that is an open XML file format consistent with the continuing work of the W3C that also meets the following criteria: open, unencumbered, universally interoperable, totally application-platform-vendor independent, with an acceptable citizen-driven governance," Edwards writes.
-
Being XML, it should be easy to convert between the two formats."
-
UH, excuse me. ODF and OOXML might be XML, but they are both application specific XML. Converting between the two means somehow being able to reconcile the different application models for handling basic document sturctures such as lists, fields, tables, sections, and page dynamics. The problem is that the two file formats are irreconcilable on these issues. What's needed is a move towards a basic generic elements/attribute model able to layer these application specific nuances into a more flexible attibute descriptive. Or, we could just move to XML/RDF and never look back :)
-
-
Now you're talking!
Tim Anderson's ITWriting - Tech writing blog » Microsoft's Jean Paoli on the ... - 0 views
-
What’s distinctive about the goals of OOXML? Primarily, to have full fidelity with pre-existing binary documents created in Microsoft Office. “What people want is to make sure that their billions of important documents can be saved in a format where they don’t lose any information. As a design goal, we said that those formats have to represent all the information that enables high-fidelity migration from the binary formats”, says Paoli. He mentions work with institutions including the British Library and the US Library of Congress, concerned to preserve the information in their electronic archive. I asked Paoli if such users could get equally good fidelity by converting their documents to ODF. “Absolutely not,” he says. “I am very clear on that. Those two formats are done for different reasons.” What can go wrong? Paoli gives as an example the myriad ways borders can be drawn round tables in Microsoft Office and all its legacy versions. “There are 100 ways to draw the lines around a table,” he says. “The Open XML format has them all, but ODF which has not been designed for backward compatibility, does not have them. It’s really the tip of the iceberg. So if someone translates a binary document with a table to ODF, you will lose the framing details. That is just a very small example.”
-
“Open Document Format and Office Open XML have very different goals”, says Paoli, responding to the claim that the world needs only one standard XML format for office documents. “Both of them are formats for documents … both are good.”
-
The door should have been slammed shut on OOXML near five years ago when, on December 14th, 2006, at the very first OASIS ODF TC meeting, Stellent's Phil Boutros proposed that the charter include, "compatibility with existing file formats and interoperability with existing applications" as a priority objective.
-
-
Another benefit Paoli claims for OOXML is performance. “A lot of things are designed differently because we believe it will work faster. The spreadsheet format has been designed for very big spreadsheets because we know our users, especially in the finance industry, use very large spreadsheets.
-
Wrong. The da Vinci plug-in prototype we demonstrated to Massachusetts on June 19th, 2006 proved that there is little or no difference in spreadsheet performance between a OOXML file, and an ODF file.
In fact, ODF version of the extremely large test file beat the OOXML load by 12 seconds.
Where the performance difference comes in is at the application level. MS Excel can load a OOXML version of a large spreadsheet faster than OpenOffice can load an ODF version of that same spreadsheet.
If you eliminate the application differential, and load the OOXML file and the ODF version of that same spreadsheet into a plug-in enabled Excel, the performance differences are negligible.
The reason for this is that the OOXML plug-in for Excel has a conversion overhead identical to the da Vinci plug-in for Excel. It has nothing to do with the file format, and everythign to do with the application.
~ge~
-
- ...5 more annotations...
-
Tim Anderson interviews Microsoft's Jean Paoli about MOOXML and ODF. Jean Paoli of course has the predictable set of answers. But Tim anderson provides us with some interesting insights and comments of his own. There is also a gem of a comment from Stephane Rodriquez, the reknown spreadsheet expert.
The bottom line for Microsoft has not changed. MOOXML exists because of the need for an XML file format compatible with the legacy of existing MSOffic ebinary documents. He claims that ODF is not compatible, and offers the "page borders" issue as an example.
Page borders? What's that got to do with the ODF file format? These are application specific, application bound proprietary graphics that can not be ported to any other application - like OpenOffice. The reason has nothign whatsoever to do with ODF and everything to do with the fact that the page border library is bound to MSOffice and not available to other applications like OpenOffice.
So here is an application specific feature tha tJean Paoli claims can not be expressed in ODF, but can in MOOXML. But when are running the da Vinci ODF plugin in MSWord, there is no problem whatsoever in capturing the page borders in ODF!!!!!!!!!!!!!!!!!!!!!!!!!!! No problem!!!!!!!!!!
The problem is opening up that same da Vinci MSWord document in OpenOffice. That's where the page borders are dropped. The issue is based entirely on the fact that OpenOffice is unable to render these MSWord specific graphics bound to an MSOffice only library.
If however we take that same page border loaded da Vinci MSWord document, and send it half way across the world to another MSWord desktop running da Vinci, the da Vinci plugin easily loads the ODF document into MSWord where it is perfectly rendered, page borders and all!!!!!!!!
Now i will admit that this is one very difficult issue to understand. If not f -
Great interview. Tim can obviously run circles around poor Jean Paoli.
Q&A: Calif. CIO Steers Clear of Ideology on File Formats - 0 views
-
We’re trying to view it as a straight business decision. What are the costs associated with one approach over another? Does it serve all of our business needs? If it doesn’t serve a business need, how do we satisfy that business need? We’re trying to view this just as a plain-vanilla, nonpartisan, nonideological issue.
-
A mus tread. Carol Sliwa of ComputerWorld intervies Clark Kelso, California CIO. ODF is the main issue, with clark casting all his answers in the context of business decisions. Carol o fcourse is asking the best questions of any journalist alive.
Keep in mind that ComputerWorld and the Boston globe filed for the Freedom of Information Act to be invoked in Massachusetts. They got access to all the eMail, documnetation, and conferencing notes concerning ODF and Microsoft. Carol's interview with Louis Gutierrez last week was filled with the same hard questions Clark Kelso fielded so deftly.
The "committee" Clark Kelso has set up to look at these issues is headed by Bill Welty, the CIO of the California Air Resources Board. Bill is a long time opensource - Linux guy, but will be the firs tto admit that Microsoft is the only vendor providing a means of getting everything inot XML. And that's the heart of any SOA strategy, "First, get everything into XML".
With a 500 million MSOffice desktop bound business process headstart, Microsoft has the extreme advantage in this much needed migration to XML.
They now have their own proprietary application and platform bound version of XML; MOOXML (Microsoft OfficeOpenXML) heading for international standardization at ISO.
They now have their XML Hub in place; the Exchange4/SharePoint Hub. This is also an essential part of any SOA strategy. You've got to have an XML Hub where the XML information streams and service connection to legacy black box systems can be piped into, managed and resolved. The XML must also provide an end user interface to these information flows. One that converges and integrates information, documents, data, and workflows into an easy to manage and participate in interface. The E/S Hub excells at this because it covers the fundamentals of eMail, messaging, portal, calendar, scheduling, c
ODF Civil War: Bulll Run - Suggested Changes on the Metadata proposal - OASIS ODF - 0 views
-
From our perspective it would be better to aim for doing the job in ODF 1.2, even if that requires delay. We will oppose ODF 1.2 at ISO unless the interoperability warts are cleaned up. What the market requires is no longer in doubt. See the slides linked above and further presentations linked from this page, < http://ec.europa.eu/idabc/en/document/6474/5935>. Substantial progress toward those goals would seem to be mandatory to maintain Europe's preference for a harmonized set of file formats that uses ODF to provide the common functionality. Delaying commencement of such work enhances the likelihood that governments will tire of waiting for ODF to become interoperable with MS Office and simply go with MOOXML. We may not be able to force Microsoft to participate in the harmonization work, but we will be in a far better position if we have done everything we can in aid of that interoperability without Microsoft's assistance. As the situation stands, we have what is known in the U.S. as a "Mexican stand-off," where neither side has taken a solitary step toward what Europe has requested. We have decided to do that work via a fork of ODF; it is up to this TC whether it wishes to cooperate in that effort.
-
This is the famous marbux response to Sun regarding Sun's attempt to partially implement ODF 1.2 XML-RDF metadata. It's a treasure.
There is one problem with marbux's statement though. We had decided long ago not to fork ODF even if the five iX "interoperability enhancement" proposals were refused by the OASIS ODF TC. This assurance was provided to Massachusetts CIO Louis Gutierrez witht he the first ODF iX proposal submitted on July 12th, 2006. Louis ended up signing off on three iX proposals before his resignation October 4th, 2006.
The ODF iX enhancements were essential to saving ODF in Massachusetts. Without them, there was no way our da Vinci plug-in could convert existing MSOffice documents and processes to ODF with the needed round trip fidelity.
For nearly a year we tried to push through some semblance of the needed iX enhancements. We also tried to push through a much needed Interoperability Framework, which will be critical to any ISO approval of ODF 1.2.
Our critics are correct in that every iX effort was defeated, with Sun providing the primary opposition.
Still rather than fork ODF, we are simply going to move on.
On October 4th, 2006, all work on ODF da Vinci ended - not to be resumed unless and until we had the ODF iX enhancements we needed to crack the MSOffice bound workgroup-workflow business process barrier.
In April of 2007, with our OASIS membership officially shredded by OASIS management, bleeding from the List Enhancement Proposal doonybrook, and totally defeated with our hope - the metadata XML-RDF work, we threw in the towel.
Since then we've moved on to CDF, the W3C Compound Document format. Incredibly, CDF is able to do what ODF can not. With CDF we can solve the three primary problems confronting governments and MSOffice bound workgroups everywhere.
The challenge for these g
InfoWorld Tech Watch | InfoWorld | Messaging standard OK'd for Web services | June 21, ... - 0 views
-
OASIS considers WS-ReliableMessaging critical for SOA, in that it can handle a variety of SOA requirements. WS-ReliableMessaging can be extended to enable integration with capabilities such as security. SOAP binding for interoperability is included. WS-ReliableMessaging is part of a series of Web services specifications dubbed WS-* that have been championed by companies such as Microsoft.
-
Check out the comments below this article. There are links to Ian Foster of Globus and to the Marbux license disseration posted with the OpenDocument Foundation's NO VOTE at OASIS.
Choice - 0 views
-
With ISO/IEC having standardized Open Document Format (ODF) 1.0 and considering standardizing Ecma Office Open XML (Open XML), there is a lot of public discussion about document formats and whether the world should begin to focus on only one format or continue to see multiple formats developed and used over time. Microsoft believes that users should be able to choose among formats and pick the one that best meets their needs. We also believe in encouraging the continued evolution of computing and data formats. And we support the ratification of Open XML in ISO/IEC. There are several reasons for these views:
-
This the infamous Microsoft letter that many have misconstrued as an announcement of support for OpenDocument. Only in a Microsoft universe can the statement, "We're not going to attack ODF" be taken as Micrsoft support for ODF.
Microsoft Will Support ODF! But Only If ISO Doesn't 'Restrict Choice Among Formats' - 0 views
-
By Marbux posted Jun 19, 2007 - 3:16 PM Asellus sez: "I will not say OOXML is easy to implement, but saying ODF is easier to implement just by looking at the ISO specification is a fallacy." I shouldn't respond to trolls, but I will this time. Asellus is simply wrong. Large hunks of Ecma 376 are simply undocumented. And what's more, absolutely no vendor has a featureful app that writes to that format. Not even Microsoft. There's a myth that Ecma 376 is the same as the Office Open XML used by Microsoft. It is not. I've spend a few hundred hours comparing the Ecma 376 specification (the version of OOXML being considered at ISO) to the information about the undocumented APIs used by MS Office 2007 that recently sprung loose in litigation. See http://www.groklaw.net/p...Rpt_Andrew_Schulman.pdf Each of those APIs *should* have corresponding metadata in the formats, but are not in the Ecma 376 specification.
-
Incredible comment by Marbux! With one swipe he takes out both Ecma 376 and ODF.
Microsoft has written a letter claiming that they will support ODF in MSOffice, but only if ISO approves Ecma 376 as a second office suite XML file format standard. ODF was approved by ISO nearly a year ago.
Criticizing Ecma 376 is easy. It was designed to meet the needs of a proprietary application, MSOffice, and, to meet the needs of the emerging MS Vista Stack of applications that spans desktop to server to device to web platforms. It's filled with MS platform dependencies that make it impossibly non interoperable with anything not fully compliant with Microsoft owned API's.
Criticizing ODF however is another matter entirely. Marbux points to the extremely poor ODF interoperability record. If MOOXML (not Ecma 376 - since that is a read only file format) is tied to vendor-application specific MSOffice, then ODF is similarly tied to the many vendor versions of OpenOffice/StarOffice.
The "many vendor" aspect of OpenOffice is somewhat of a scam. The interoperability that ODF shares across Novell Office, StarOffice, IBM WorkPlace, Red Office, and NeoOffice is entirely based on the fact that these iterations of OpenOffice are based on a single code base controlled 100% by Sun. Which is exactly the case with MSOffice. With this important exception - MOOXML (not Ecma 376) is interoperable across the entire Vista Stack!
The Vista Stack is comprised of Exchange/SharePoint, MS Live, MS Dynamics, MS SQL Server, MS Internet Server, MS Grove, MS Collaboration Server, and MS Active Directory. Behind these applications sits a an important foundation of shared assets: MOOXML, Smart Documents, XAML and .NET 3.0. All of which can be worked into third party, Stack dependent applications through the Visual Studio .NET IDE.
Here are some thoughts i wou
Commercializing Interoperability -- gary_edwards's comment on "Linux leaders plot count... - 0 views
-
Is Microsoft commercializing "interoperability"? Is interoperability through privileged access to the interop API's now a strategic asset to be traded with partners in crime?
-
The first post in the ZDNet series discussing the many deals Microsoft is cutting with prominent LiNUX vendors. My point is that interoperability plays a prominent role in each of these deals, and, the deals also involve partners supporting Microsoft directed interop between OpenOfficeXML and OpenDocument. Coincidence?
I think not!
Billions of Legacy Binary Documents -- gary_edwards's comment on "Linux leaders pl... - 0 views
-
The point is that ODF has to be flexible enough so that the demand side of the equation can successfully convert their MSOffice documents to ODF. More important than simple one-way conversion is the need for high fidelity round trip conversion.
-
This is a follow up comment to a question cocerning my previous post, "commercialization of interoperability". The question from "mosborne" is as follows:
A different viewI'm not on the ODF TC, but I have followed its evolution through the information publicly available at Oasis.
My outside view of some of the various interoperability discussions you mention is different than yours. I saw a resistance to adoption of features if the sole reason was because OOXML did it that way. The dissenting members wanted a more substantial reason, not simply to add OOXML "features" to ODF.
If the goal is to simply make ODF like OOXML, then what is the point? You would have conceded all control to Microsoft since they have effective control of OOXML.It's an interesting question, but not well informed. The threads at OASIS ODF having to do with interoperability are focused on efforts to have our cake and eat it too.
The List Enhancement Proposal thread played out over a six month period. And yes, it is true that Sun fought the Novell proposal because they felt new and innovative features for OpenOffice/StarOffice were more important than the interoperability CIO's and IT departments are demanding. But that misses the more important point that Novell was able to craft their interoperability proposal exactly so that the precious advanced feature sets of applications that command les sthan 1% marketshare would be accommodated.
What Sun and most others on the ODF TC don't get is that the markets have no use for these new and innovative feature sets unless and until they can transition their documents and business processes out of MSOffice. If workgroup bound end users can't do that first, it won't matter how
PlexNex: Achieving Openness - 0 views
-
"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.
-
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.
Between a rock and a hard place: ODF & CIO's - Where's the Love? - 0 views
-
So I'm disappointed. And not just on behalf of open documents, but on behalf of the CIOs of this country, who are now caught between a rock and a hard place, without a paddle to defend themselves with if they won't to do anything new, innovative and necessary, if a major vendor's ox might be gored in consequence. After the impressive lobbying assault mounted over the past six months against open document format legislation, I expect you won't be hearing of many state IT departments taking the baton back from their legislators. And who can blame them? If they tried, it wouldn't be likely to be anything as harmless as an open document format that would bite them in the butt.
-
Andy Updegrove weighs in on the wave of ODF legislative failures first decribed by Eric Lai and Gregg Keizer compiled the grim data in a story they posted at ComputerWorld last week titled Microsoft trounces pro-ODF forces in state battles over open document formats.
Andy believes that it is the failure of state legislators to do their job that accounts for these failures. He provides three reasons for this being a a failure of legislative duty. The most interesting of which is claim that legislators should be protecting CIO's from the ravages of aggressve vendors.
The sad truth is that state CIO's are not going to put their careers on the line for a file format after what happened in Massachusetts.
Andy puts it this way, "
And second, in a situation like this, it is a cop out for legislatures to claim that they should defer to their IT departments to make decisions on open formats. You don't have to have that good a memory to recall why these bills were introduced in the first place: not because state IT departments aren't a good place to make such decisions, but because successive State CIOs in Massachusetts had been so roughly handled in trying to make these very decisions that no state CIO in his or her right mind was likely to volunteer to be the next sacrificial victim.
As both Peter Quinn and Louis Gutierrez both found out, trying to make responsible standards-related decisions whe
State's move to open document formats still not a mass migration - 0 views
-
Only a tiny fraction of the PCs at Massachusetts government agencies are able to use the Open Document Format (ODF) for Office Applications, despite an initial deadline of this month for making sure that all state agencies could handle the file format.
-
Eric Lai keesp pokign at that Massachusetts hornets nest. One of these days he's going to crack it open, and it will be back to square one for the ODF Community. Still missing from his research is the infoamous 300 page pilot study and accompanying web site where comments and professional observations document a year long study concernign the difficulties of implementing ODF solutions and making the migration. <br><br>
The study was focused on OpenOffice, StarOffice, Novell Office, and a IBM WorkPlace prototype.<br><br>
The results of the year long pilot have never seen the public light of day. But ComputerWorld is one of the media orgs that successfully filed a court action to invoke the freedom of information act in Massachusetts. How come they can't find the Pilot Study?<br><br>
At the end of the pilot study period, Massachusetts issued their infamous RFi; the request for information regarding the possiblity of a ODF plugin for MSOffice! Meaning, the Pilot Study did not go well for the heroes of ODF - OpenOffice, StarOffice, Novell Office and WorkPlace. Instead, Massachusetts sought an ODF plugin that would no doubt extend the life of MSOffice for years to come. No rip out and replace here folks!<br><br>
~ge~
« First
‹ Previous
81 - 100 of 181
Next ›
Last »
Showing 20▼ items per page