Skip to main content

Home/ Document Wars/ Group items tagged Office-Interop

Rss Feed Group items tagged

Gary Edwards

ODF and OOXML must converge!! AFNOR, the French Standards Body, announces proposals for... - 0 views

  • AFNOR has recommended to ISO adopting an approach enabling it to guarantee – using ISO processes – mid-term convergence between Open Document Format (ODF) and OfficeOpen XML (OOXML), as well as the stabilisation of OOXML on a short-term basis.
  • Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions. Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality. Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years.   Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players.
    • Gary Edwards
       
      Here's the meat of the French convergence proposal.
  •  
    French experts have determined that it is technically possible to converge ODF and MS-OOXML, into a single, revisable document format standard?

    The plan has four parts:

    "Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions."

    "Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality."

    "Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years."

    Fourth, "Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players."




    So there you go.  A solution that removes ODF and OOXML from the clam
Gary Edwards

LibreOffice 4.3 boosts document compatibility | InfoWorld - 0 views

  •  
    "Version 4.3 of LibreOffice, the free and open source productivity suite developed by the Document Foundation and derived from the OpenOffice.org project, was released today. Aside from the usual array of bug fixes and new features designed to make it more cross-compatible with Microsoft Office, version 4.3 has features that give files from legacy Macintosh productivity software a new lease on life. Take control! 30 essential OS X command-line tips Go beyond the graphical user interface and take full advantage of Mac OS X at the command line READ NOW Most of the improvements around file handling in 4.3 involve better support for various aspects of the Office Open XML (OOXML) format used by Microsoft for its productivity software. LibreOffice users have often complained of opening Word 2010 or Word 2013 documents and finding that the formatting had been mangled or features like annotations hadn't survive being resaved in LibreOffice. Version 4.3 preserves many more of the attributes used in OOXML documents, such as style attributes for text and images. Also new to this edition of LibreOffice is import support for document formats created by a slew of legacy Macintosh applications: BeagleWorks, ClarisWorks, Claris Resolve, GreatWorks, MacWorks, SuperPaint, and Wingz. Likewise, Microsoft Works spreadsheets and databases -- not just word processing documents -- can now also be imported into LibreOffice. Another change, which might not directly affect many users but hints at how the refactoring of LibreOffice's code is reaching many legacy issues, involves the lengths of paragraphs. Previously, paragraphs in a LibreOffice document couldn't exceed 65,000 characters due to a bug in the underlying OpenOffice.org code that had persisted for over a decade and remained unclosed. Other changes include comments that can now be "printed in the document margin, formatted in a better way, and imported and exported," according to the Document Foundation; better behaviors for sp
Gary Edwards

Microsoft Hit By U.S. DOT Ban On Windows Vista, Explorer 7, and Office 2007 - Technolog... - 0 views

  • »  E-Mail »  Print »  Discuss »  Write To Editor late last year -- can be resolved. "We have more confidence in Microsoft than we would have 10 years ago," says Schmidt. "But it always makes sense to look at the security implications, the value back to the customer, and those kind of issues." The DOT's ban on Vista, Internet Explorer 7, and Office 2007 applies to 15,000 computer users at DOT proper who are currently running the Windows XP Professional operating system. The memo indicates that a similar ban is in effect at the Federal Aviation Administration, which has 45,000 desktop users. Compatibility with existing applications appears to be the Transportation Department's major concern. According to a separate memo, a number of key software applications and utilities in use in various branches of the department aren't Vista compatible. Among them are Aspen 2.8.1, ISS 2.11, ProVu 3.1.1, and Capri 6.5, according to a memo issued by staffers at the DOT's Federal Motor Carrier Safety Administration. Any prolonged ban on new Microsoft technologies by the federal government could have a significant impact on the software maker's bottom line, as Microsoft sells millions of dollars in software to the feds annually. http://as.cmpnet.com/event.ng/Type=count&ClientType=2&AdID=125682&FlightID=75634&TargetID=2625&SiteID=222&AffiliateID=283&EntityDefResetFlag=0&Segments=1411,3108,3448,11291,12119&Targets=2625,2878,7904,8579&Values=34,46,51,63,77,87,91,102,140,222,227,283,442,646,656,1184,1255,1311,1405,1431,1716,1767,1785,1798,1925,1945,1970,2217,2299,2310,2326,2352,2678,2727,2767,2862,2942,3140,3347,3632,3636,3638,3890,3904,4080,448
    • Gary Edwards
       
      DOT chief technology officer Tim Schmidt DOT's CIO Daniel Mintz Federal Department of Transportation
  •  
    Whoa, those government desktops add up quickly.  This Vista ban will immediately effect over 50,000 desktops, with tens of thousands more possibly impacted by the IE 7.0 ban.  The MS Exchange/SharePoint Hub juggernaut is based on IE 7.0, which is not available for Windows 2000 - MSOffice 2000 desktops.

    Lack of Vista Stack compatibility with non Microsoft application is given as the reason for the ban.  But notice the "alternatives" to Vista mentioned; Novel SuSE and Apple Mac.  What kind of interop - compatibility do they offer?  My guess is ZERO!

    The reality is that the DOT is trapped.  My advice would be stay exactly where they are, keeping the current MSOffice desktop installs running.  Then, install the Foundation's daVinci ODF plugin for MSOffice. 

    This will insure that Windows OS and  MSOffice bound business processes can continue to function without disruption.  Win32 APi based applications like those mentioned in the article can continue.  Critical day to day business processes, workgroup and workflow related activities can continue without disruption or costly re engineering demanded by a cross platform port.

    What daVinci doe sdo is move the iron triangle that binds Windows-MSOffice applications to business processes and documents, to an ODF footing.  Once on a ODF footing, the government can push forward with the same kind of workgroup - workflow - intelligent docuemnt - collaborative computing advnaces that the Vista Stack was designed to deliver.  Only this push will involve the highly competitive "the customer is sovereign" environment of ODF ready desktop, server, device and Web 2.0 systems.  End of Redmond lock-in.  End of the costly iron triangle and the force march upgrade treadmill that so enriches Microsoft.

    So what's not to like?  We can do this.
    ~ge~

    http://docs.google.com/View?docID=dghfk5w9_20d2x6rf&revi
Gary Edwards

The End of ODF & OpenXML - Hello ODEF! - 0 views

  •  
    Short slide deck of Barbara Held's February 28th, 2007 EU IDABC presentation. She introduces ODEF, the "Open Document Exchange Format" which is designed to replace both ODF and OpenOfficeXML. ComputerWorld recently ran a story about the end of ODF, as they covered the failure of six "legislative" initiatives designed to mandate ODF as the official file format. While the political treachery surrounding these initiatives is a story in and of itself, the larger story, the one that has world wide reverberations, wasn't mentioned. The larger ODF story is that ODF vendors are losing the political battles because they are unable to provide government CIO's with real world solutions. Here are three quotes from the California discussion that really say it all: "Interoperability isn't just a feature. It's the basic requirement for getting your XML file format and applications considered"..... "The challenge is that of migrating our existing documents and business processes to XML. The question is which XML? OpenDocument or OpenXML?" ....... "Under those conditions, is it even possible to implement OpenDocument?" ....... Bill Welty, CIO California Air Resource Board wondering if there was a way to support California legislative proposal AB-1668. This is hardly the first time the compatibility-interoperability issue has challenged ODf. Massachusetts spent a full year on a pilot study testing the top tier of ODF solutions: OpenOffice, StarOffice, Novell Office and IBM's WorkPlace (prototype). The results were a disaster for ODF. So much so that the 300 page pilot study report and accompanying comments wiki have never seen the light of day. In response to the disastrous pilot study, Massachusetts issued their now infamous RFi; a "request for information" about whether it's possible or not to write an ODF plugin for MSOffice applications. The OpenDocument Foundation responded to the RFi with our da Vinci plugin. The quick descriptio
Gary Edwards

Cutting corners - the realpolitik of ODF standardisation? - The Wayback Machine Roars R... - 0 views

  •  
    From Notes2Self 2006 post we discover once again that ODF Interop problems are not new. Back in early February 2005, top ranking OASIS Executive James Clark made a comment to the OASIS OpenDocument technical Committee about the lack of interoperability for spreadsheet documents:

    ".... I really hope I'm missing something, because, frankly, I'm speechless.  You cannot be serious. You have virtually zero interoperability for spreadsheet documents. OpenDocument has the potential to be extraodinarily valuable and important standard. I urge you not to throw away a huge part of that potential by leaving such a gaping hole in your specification...". Claus Agerskov further commented that this provided a means of creating lock-in (my emphasis)

    "OpenDocument doesn't specify the formulars used in spreadsheets so every spreadsheet vendor can implement formulars in their own way without being an open standard. This way a vendor can create lock-in to their spreadsheets"
Gary Edwards

Microsoft Closer on \'Office Open\' Blessing - 0 views

  • Opponents to OOXML, which include IBM (Quote) and the Open Document Foundation, have argued that Microsoft's specifications are unwieldy and that the standard application is redundant with the Open Document Format (ODF), which already exists. Microsoft has countered that the OOXML format is valuable because it is closer to Office 2007 and is backwards-compatible with older versions of Office. "Although both ODF and Open XML are document formats, they are designed to address different needs in the marketplace," the company wrote in an open letter published earlier this month.
  •  
    Internet News is reporting that Ecma has submitted to the ISO/IEC JTC1 their repsonsess to the 20 "fast track" for Ecma 376 (OOXML) objections.  Nothing but blue skies and steady breeze at their back for our friends at Redmond, according to Ecma's rubber stamper in chief, Jan van den Beld.

    Once again there is that ever present drum beat from Microsoft that ODF can't handle MSOffice and legacy MSOffice features - including but not mentioned the conversion to XML of those infamous billions of binary documents:
    "Microsoft has countered that the OOXML format is valuable because it is closer to Office 2007 and is backwards-compatible with older versions of Office. "Although both ODF and Open XML are document formats, they are designed to address diffe
Gary Edwards

GullFOSS: It's our way or the highway. So what if new cool features = Zero Interop? D... - 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. 
  •  
    Make no mistake about it. Microsoft is absolutely right about three things: .... Compatibility with existing file formats is not an ODF concern. .... Sun controls the OASIS ODF TC. .... Sun makes certain that ODF is bound tightly to the OpenOffice feature set. Sun's view of interoperability is that of a one way street. Documents can be converted into ODF-OOo/SO, but they are guaranteed to break during any kind of document routing or round tripping. This is also the reason why the Sun "external" plugin for MSOffice fails. One way conversion simply isn't enough to crack the hold MSOffice has on critical day to day business processes. The only way to that is with a conversion process able to maintain high level fidelity while round tripping. As the EU IDABC has figured out, the ODF-OOo/SO specification is loaded with interoperability break points. That's why they are turning to ODEF, which can be seen as a version of ODF that is truly application independent and optimized for interoperability. ~ge~
Gary Edwards

5 Things Microsoft Must Do To Reclaim Its Mojo In 2008 -- InformationWeek - 0 views

  • Instead of fighting standards, Microsoft (NSDQ: MSFT) needs to get on board now more than ever. With open, Web-based office software backed by the likes of IBM (NYSE: IBM) (think Lotus Symphony) and Google (NSDQ: GOOG) now a viable option, users—especially businesses frustrated by Microsoft's format follies (many are discovering that OOXML is not even fully backwards-compatible with previous versions of Microsoft Word)--can now easily switch to an online product without having to rip and replace their entire desktop infrastructure.
    • Gary Edwards
       
      This article discusses how Microsoft might change their ways and save the company. This particular quote concerns Microsoft support for standards, and their fight to push MS OOXML through ISO as an alternative to ISO approved ODF 1.0.
      The thing is, ODF was not designed for the conversion of MSOffice documents, of which there are billions. Nor was ODF designed to be implemented by MSOffice. ODF was designed exactly for OpenOffice, which has a differnet model for impementing basic docuemnt structures than MSOffice.
      So a couple of points regardign this highlight:
      The first is that IBM's Lotus Symphony is NOT Open Source. IBM ripped off the OpenOffice 1.1.4 code base back when it was dual licensed under both SSSL and LGPL. IBM then closed the source code adding a wealth of proprietary eXtensions (think XForms and Lotus Notes connections). Then IBM released the proprietary Symphony as a free alternative to the original Open Source Community "OpenOffice.org".
      If Microsoft had similarly ripped off an open source community, there would be hell to pay.
      Another point here is the mistaken assumption that users can easily switch from MSOffice to an on-line product like Google Docs or ZOHO "without having to rip our and replace their entire desktop infrastructure."
      This is a ridiculous assumption defied by the facts on the ground. Massqchusetts spent two years trying to migrate to ODF and couldn't do it. Every other pilot study known has experienced the same difficulties!
      The thing about Web 2.0 alternatives is that these services can not be integrated into existing business processes and MSOffice workgroup bound activities. The collaborative advantages of Web 2.0 alternatives are disruptive and outside existing workflows, greatly marginalizing their usefulness. IF, and that's a big IF, MSOffice plug-ins were successful in the high fidelity round trip conversion of wor
  • Microsoft in 2008 could make a bold statement in support of standards by admitting that its attempt to force OOXML on the industry was a mistake and that it will work to develop cross-platform compatibility between that format and the Open Document Format
    • Gary Edwards
       
      It's impossible to harmonize two application specific file formats. The only way to establish an effective compatibility between ODF and OOXML would be to establish a compatibility between OpenOffice and MSOffice.
      The problem is that neither ODF or OOXML were developed as generirc file formats. They are both application specific, directly reflecting the particular implementation models of OOo and MSOffice.
      Sun and the OASIS ODF TC are not about to compromise OpenOffice feature sets and implmentation methods to improve interop with MSOffice. Sun in particular will protect the innovative features of OpenOffice that are reflected in ODF and stubbornly incompatible with MSOffice and the billions of binary documents. This fact can easily be proven be any review of the infamous "List Enhancement Proposal" that dominated discussions at the OASIS ODF TC from November of 2006 through May of 2007.
      So if Sun and the OASIS ODF TC refuse to make any efforts towards compatibility and imporved interop with MSOffice and the billions of binary docuemnts seekign conversion to ODF, then it falls to Microsoft to alter MSOffice. With 550 million MSOffice desktops involved in workgroup bound business processes, any changes would be costly and disruptive. (Much to the glee of Sun and IBM).
      IBM in particular has committed a good amount of resources and money lobbying for government mandates establishing ODF as the accepted format. this would of course result in a massively disruptive and costly rip out and replace of MSOffice.
      Such are the politics of ODF.
Gary Edwards

Putting Andy Updegrove to Bed (without his supper) | Universal Interoperability Council - 0 views

  • In late 2007, an article by OASIS attorney Andy Updegrove claimed that W3C Compound Document Formats: [i] are non-editable formats; [ii] are not designed for conversions to other formats; and [iii] are therefore unsuitable as office formats. Updegrove could not have been more wrong. But unfortunately, the erroneous Updegrove article was widely publicized by the usual occupants of the IBM cheering section (1) in the stadium where the latest big vendor game for the Incompatible File Format Cup is being played, IFFC Games Stadium.
Gary Edwards

XML.com: Standard Data Vocabularies Unquestionably Harmful - 0 views

  • At the onset of XML four long years ago, I commenced a jeremiad against Standard Data Vocabularies (SDVs), to little effect. Almost immediately after the light bulb moment -- you mean, I can get all the cool benefits of web in HTML and create my own tags? I can call the price of my crullers <PricePerCruller>, right beside beside <PricePerDonutHole> in my menu? -- new users realized the problem: a browser knows how to display a heading marked as <h1> bigger and more prominently than a lowlier <h3>. Yet there are no standard display expectations or semantics for the XML tags which users themselves create. That there is no specific display for <Cruller> and, especially, not as distinct from <DonutHole> has been readily understood to demonstrate the separation of data structure expressed in XML from its display, which requires the application of styling to accomodate the fixed expectations of the browser. What has not been so readily accepted is that there should not be a standard expectation for how a data element, as identified by its markup, should be processed by programs doing something other than simple display.
    • Gary Edwards
       
      ODF and OOXML are contending to become the Standard Data Vocabulary for desktop office suite XML markup. Sun and Microsoft are proposing the standardization of OpenOffice and MSOffice custom defined XML tags for which there are no standard display expectations. The display expectations must therefore be very carefully described: i.e. the semantics of display fully provided.
      In this article Walter Perry is pointing out the dangers of SDV's being standardized for specific purposes without also having well thought out and fully specified display semantics. In ODF - OOXML speak, we would call display presentation, or layout, or "styles".
      The separation of content and presentation layer of each is woefully underspecified!
      Given that the presnetation layers of both ODF and OOXML is directly related to how OpenOffice and MSOffice layout engines work, the semantics of display become even more important. For MSOffice to implement an "interoperable" version of OpenOffice ODF, MSOffice must be able to mimic the OpenOffice layout engine methods. Methods which are of course quite differeent from the internal layout model of MSOffice. This differential results in a break down of conversion fidelity, And therein lies the core of the ODF interoeprability dilemma!
  • There have also emerged a few "horizontal" data vocabularies, intended for expressing business communication in more general terms. One of these is the eXtensible Business Reporting Language (XBRL), about which more below. Most recently, governments and governmental organizations have begun to suggest and eventually mandate particular SDVs for required filings, a development which expands what troubles me about these vocabularies by an order of magnitude.
  • ...5 more annotations...
    • Gary Edwards
       
      Exactly! When governments mandate a specific SDV, they also are mandating inherent concepts and methods unique to the provider of the SDV. In the case of ODF and OOXML, where the presentation layers are application specific and woefully underspecified, interoperability becomes an insurmountable challenge. Interop remains stubbornly application bound.
      Furthermore, there is no way to "harmonize" or "map" from one format to another without somehow resolving the application specific presentation differences.
    • Gary Edwards
       
      "in the nature of the SDV's themselves is the problem of misstatement, of misdirection of naive interpretation, and potential for fraud.
      Semantics matter! The presentation apsects of a document are just as important as the content.
    • Gary Edwards
       
      Walter: "I have argued for years that, on the basis of their mechanism for elaborating semantics, SDVs are inherently unreliable for the transmission or repository of information. They become geometrically less reliable when the types or roles of either the sources or consumers of that information increase, ending at a nightmarish worst case of a third-order diminution of the reliability of information. And what is the means by which SDVs convey meaning? By simple assertion against the expected semantic interpretations hard-coded into a process consuming the data in question.
      At this point in the article i'm hopign Walter has a solution. How do we demand, insist and then verify that SDV's have fully specifed the semantics, and not jus tpassed along the syntax?
      With ODF and OOXML, this is the core of the interoperability problem. Yet, there really is no way to separate the presentation layers from the uniquely different OpenOffice and MSOffice layout engine models.
    • Gary Edwards
       
      Interesting concept here: "the bulk of expertise is in understanding the detail of connections between data and the processes which produced it or must consume it ........ it is these expert connections which SDV's are intended to sever.
      Not quite sure what to make of that statement? When an SDV is standardized by ISO, the expectation is that the connections between data and processes would be fully understood, and implementations consistent across the board.
      Sadly, ODF is ISO approved, but doesn't come close to meeting these expectations. ODF interop might as well be ZERO. And the only way to fix it is to go into the presentation layer of ODF, strip out all the application specific bindings, and fully specifiy the ssemantics of layout.
  • In short, the bulk of expertise is in understanding the detail of connections between data and the processes which produced it or must consume it. It is precisely these expert connections which standard data vocabularies are intended to sever.
Gary Edwards

Wizard of ODF: The Foundation on Interop and the List Proposal Vote Deadline - 0 views

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

Doug Mahugh : Standards-Based Interoperability - 0 views

  • Standards-Based Interoperability
  • 05 June 09
  • Interoperability without Standards
  • ...46 more annotations...
  • First, let’s consider how software interoperability works when it is not standards-based. Consider the various ways that four applications can share data, as shown in the diagram to the right.  There are six connections between these four applications, and each connection can be traversed in either direction, so there are 12 total types of interoperability involved.
  • As the number of applications increases, this complexity grows rapidly.  Double the number of applications to 8 total, and there will be 56 types of interoperability between them:
  • through standards maintenance, transparency of implementation details, and collaborative interoperability testing.
    • Graham Perrin
       
      Issues relating to CalDAV are well addressed in these ways.
  • Here’s where those workarounds will need to be implemented: Note the complexity of this diagram.
  • In the real world, interoperability is almost never achieved in this way.  Standards-based interoperability is much better approach for everyone involved,
  • whether that standard is an open one such as ODF (IS26300)
  • or a de-facto standard set by one popular implementation.
  • or Open XML (IS29500)
  • The core premise of open standards-based interoperability is this:
  • each application implements the published standard as written, and this provides a baseline for delivering interoperability.
  • the existence of a standard addresses many of the issues involved, and the other issues can be addressed
  • In the standards-based scenario, the standard itself is the central mechanism for enabling interoperability between implementations: This diagram is much simpler
  • there is no question that users of other products are massively surprised by
  • How this all applies to Office 2007 SP2 I covered last summer the set of guiding principles that we used to guide the work we did to support ODF in Office 2007 SP2.
  • applied in a specific order
  • I’d like to revisit the top two guiding principles
  • Guiding Principle #1: Adhere to the ODF 1.1 Standard
  • Guiding Principle #2: Be Predictable
  • Being predictable is also known as the principle of least astonishment.
  • What about Bugs and Deviations? Of course, the existence of a published standard doesn’t prevent interoperability bugs from occurring.
  • deviations from the requirements
  • different interpretations
  • Our approach to the transparency issue has been to document the details of our implementation through published implementer notes.
  • Interoperability Testing The final piece of the puzzle is hands-on testing
  • What else would you like to know about how Office approaches document format interoperability?
  • a standard (evolved and improved as reality demands) is the proper foundation for resolving interoperabilty
  • All complex software has bugs, and some bugs can present significant challenges to interoperability.  Let’s consider the case that 3 of the 4 applications have bugs that affect interoperability, as shown in the diagram to the right.
  • (1) their spreadsheets having their formulas lost when interchanged with Excel 2007
  • (2) not being able to handle the formulase received in Excel 2007's ODF output.
  • I am creating my own fantasy about the state of affairs
    • Graham Perrin
       
      :-)
  • it is far too early to declare it to be unsuccessful
  • I cannot fault the Microsoft approach as incorrect
  • I was at the year-ago DII meeting where the guiding principles were announced and their application to spreadsheet formulas described.  I applauded the principles and understood the reasoning for formulas.
  • How this would impact various groups of users and non-users (who still want to interoperate) of Office 2007 did not surface in my consciousness.
  • there is NO published standard for ODF spreadsheet formulas yet.
  • Nor is there any de-facto standard that everyone agrees on.
  • the “spaghetti diagram" method, with all of the complexity and risk of bugs that entails
  • No implementer we know of has attempted that
  • In the case of spreadsheet formulas, help is on the way -- OpenFormula is under development for use with ODF 1.2.
  • I’d like to keep this thread on-topic
  • I appreciate the post, very good
  • Visually I would rather frame it in terms of convergence, a spiral.
  • and user satisfaction.
  • I doubt someone would ever find a magic bullet to interoperability
  • New Comments to this post are disabled
    • Graham Perrin
       
      Hurrah!
  • © 2009 Microsoft Corporation
  •  
    Diagrams here are eye-catching.
Gary Edwards

What will it be for ODF? Continuation of limited interop? Or a transition to Universa... - 0 views

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

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
Gary Edwards

Linux Foundation Legal : Behind Putting the OpenDocument Foundation to Bed (without its... - 0 views

  • CDF is one of the very many useful projects that W3C has been laboring on, but not one that you would have been likely to have heard much about. Until recently, that is, when Gary Edwards, Sam Hiser and Marbux, the management (and perhaps sole remaining members) of the OpenDocument Foundation decided that CDF was the answer to all of the problems that ODF was designed to address. This announcement gave rise to a flurry of press attention that Sam Hiser has collected here. As others (such as Rob Weir) have already documented, these articles gave the OpenDocument Foundation’s position far more attention than it deserved. The most astonishing piece was written by ZDNet’s Mary Jo Foley. Early on in her article she stated that, “the ODF camp might unravel before Microsoft’s rival Office Open XML (OOXML) comes up for final international standardization vote early next year.” All because Gary, Sam and Marbux have decided that ODF does not meet their needs. Astonishing indeed, given that there is no available evidence to support such a prediction.
  •  
    Uh?  The ODF failure in Massachusetts doesn't count as evidence that ODF was not designed to be compatible with existing MS documents or interoperable with existing MSOffice applications?

    And it's not just the da Vinci plug-in that failed to implement ODF in Massachusetts!  Nine months later Sun delivered their ODF plug-in for MSOffice to Massachusetts.  The next day, Massachusetts threw in the towel, officially recognizing MS-OOXML (and the MS-OOXML Compatibility Pack plug-in) as a standard format for the future.

    Worse, the Massachusetts recognition of MS-OOXML came just weeks before the September 2nd ISO vote on MS-OOXML.  Why not wait a few more weeks?  After all, Massachusetts had conducted a year long pilot study to implement ODF using ODF desktop office sutie alternatives to MSOffice.  Not only did the rip out and replace approach fail, but they were also unable to integrate OpenOffice ODF desktops into existing MSOffice bound workgroups.

    The year long pilot study was followed by another year long effort trying to implement ODF using the plug-in approach.  That too failed with Sun's ODF plug-in the final candidate to prove the difficulty of implementing ODF in situations where MSOffice workgroups dominate.

    California and the EU-IDABC were closely watching the events in Massachusetts, as was most every CIO in government and private enterprise.  Reasoning that if Massachusetts was unable to implement ODF, California CIO's totally refused IBM and Sun's effort to get a pilot study underway.

    Across the pond, in the aftermath of Massachusetts CIO Louis Guiterrez resignation on October 4th, 2006, the EU-IDABC set about developing their own file format, ODEF.  The Open Document Exchange Format splashed into the public discussion on February 28th, 2007 at the "Open Document Exchange Workshop" held in Berlin, Germany.

    Meanwhile, the Sun ODF plug-in is fl
Gary Edwards

ODF and OOXML - The Final Act - 0 views

  • The format war between Microsoft’s Open Office XML (OOXML) and the open source OpenDocument Format (ODF) has flared up again, right before the looming second OOXML ISO vote in March.
  • “ISO has a policy that, wherever possible, there should only be one standard to maximise interoperability and functionality. We have an international standard for digital documentation, ODF,” IBM’s local government programs executive Kaaren Koomen told AustralianIT.
  • ODF has garnered some criticism for being a touch limited in scope, however, one of its strengths is that it has already been accepted as a worldwide ISO standard. Microsoft’s format on the other hand, has been criticised for being partially proprietary, and even a sly attempt by the software giant to hedge its bets and get in on open standards while keeping as many customers locked into its solutions as possible.
    • Gary Edwards
       
      A "touch limited in scope"? Youv'e got to be kidding. ODF was not defined to be compatible with the billions of MSOffice binary (BIN) documents. Nor was it designed to further interoperability with MSOffice.
      Given that there are over 550 million MSOffice desktops, representing upwards of 95% of all desktop productivity environments, this discrepancy of design would seem to be a bit more than a touch limited in scope!
      Many would claim that this limitation was due to to factors: first that Microsoft refused to join the OASIS ODF TC, which would have resulted in an expanded ODF designed to meet the interoperability needs of the great herd of 550 million users; and second, that Microsoft refused to release the secret binary blueprints.
      Since it turns out that both IBM and Sun have had access to the secret binary blueprints since early 2006, and in the two years since have done nothing to imptove ODF interop and conversion fidelity, this second claim doesn't seem to hold much water.
      The first claim that Microsoft didn't participate in the OASIS ODF process is a bit more interesting. If you go back to the first OASIS ODF Technical Committee meeting, December 16th, 2002, you'll find that there was a proposal to ammend the proposed charter to include the statemnt that ODF (then known as Open Office XML) be compatible with existing file formats, including those of MSOffice. The "MSOffice" reference was of course not included because ODF sought to be application, platform and vendor independent. But make no mistake, the discussion that day in 2002 was about compatibility and the conversion of the legacy BIN's into ODF.
      The proposal to ammend the charter was tabled. Sun objected, claiming that people would interpret the statement as a direct reference to the BIN's, clouding the charter's purpose of application, platform and vendor independence. They proposed that the charter ammendment b
    • Gary Edwards
       
      Will harmonization work? I don't think so. The problem is that the DIN group is trying to harmonize two application specific formats. OpenOffice has one way of implementing basic document structures, and MSOffice another. These differences are directly reflected in the related formats, ODF and OOXML. Any attempts to harmonize ODF and OOXML will require that the applications, OpenOffice and MSOffice, be harmonized! There is no other way of doing this unless the harmonized spec has two different methods for implementing basic structures like lists, tables, fields, sections and page dynamics. Not to mention the problems of feature disparities. If the harmonized spec has two different implementation models for basic structures, interoeprability will suffer enormously. And interoperability is after all the prupose of the standardization effort. That brings us to a difficult compromise. Should OpenOffice compromise it's "innovative" features and methods in favor of greater interoperability with MSOffice and billions of binary documents? Let me see, 100 million OpenOffice installs vs. 550 MSOffice installs bound to workgroup-workflow business processes - many of which are critical to day to day business operations? Sun and IBM have provided the anser to this question. They are not about to compromise on OpenOffice innovation! They believe that since their applications are free, the cost of ODF mandated "rip out and replace" is adequately offset. Events in Massachusetts prove otherwise! On July 2nd, 2007, Sun delivered to Massachusetts the final version of their ODF plug-in for MSOffice. That night, after reviewing and testing the 135 critical documents, Massachusetts made a major change to their ETRM web site. They ammended the ETRM to fully recognize OOXML as an acceptable format standard going forward. The Massachusetts decision to overturn th
  • ...1 more annotation...
    • Gary Edwards
       
      The Burton Group did not recommend that ISO recognize OOXML as a standard! They pointed out that the marketplace is going to implement OOXML by default simply because it's impossible to implement ODF in situations where MSOffice dominates. ISO should not go down the slippery slope of recognizing application-platform-vendor specific standards. They already made that mistake with ODF, and recognizing OOXML is hardly the fix. What ISO should be doign is demanding that ODF fully conform with ISO Interoeprability Requirements, as identified in the May 2006 directive! Forget OOXML. Clean up ODF first.
  •  
    Correcto mundo! There should be only one standard to maximise interoeprability and functionality. But ODF is application specific to the way OpenOffice works. It was not designed from a clean slate. Nor was the original 2002 OpenOffice XML spec designed as an open source effort! Check the OOo source code if you doubt this claim. The ONLY contributors to Open Office XML were Sun employees! What the world needs is in fact a format standard designed to maximise interoperability and functionality. This requires a total application-platofrm-vendor independence that neither ODF or OOXML can claim. The only format that meets these requirements is the W3C's family of HTML-XML formats. These include advancing Compound Docuemnt Framework format components such as (X)HTML-5, CSS-3, XForms, SVG and SMiL.. The W3C's CDF does in fact meet the markeplace needs of a universal format that is open, unencumbered and totally application, platform and vendor independent. The only trick left for CDF is proving that legacy desktop applications can actually implement conversions from existing in-memory-binary-representations to CDF without loss of information.
Gary Edwards

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
Gary Edwards

Can IBM save OpenOffice.org from itself? - 0 views

  • OpenOffice.org's biggest foe may be Microsoft Office, but critics say the open-source organization has, from its inception, also been one of its application suite's own worst enemies -- a victim of a development culture that differs radically from the open-source norm. Observers now wonder if IBM's entry into OpenOffice.org can make the necessary changes.
    • Gary Edwards
       
      good article from Eric Lai of ComputerWorld. Written on the eve of the infamous Barcelona OpenOffice.org developers conference, Eric argues that OOo isn't a real open source community. Instead, OOo is a owned and operated by Sun.
      One of the more important control points Sun insists on is that of commit rights and project managers. Only Sun employees have these rights and can hold these important positions..
      The more important point is made by Marbux (below: ODF is an application specific format designed exactly for OpenOffice. While other applications might partially implement ODF, interoperability and successful ODF document exchange require the OOo code base!
      From Marbux: This is the only article I've found to date where IBM (Heintzman) flat out says IBM wants changes in OOo licensing, more in line with the Eclipse and Apache licenses. See pg. 2. Significant because it feeds the meme that IBM's own ODF-based development goal is proprietary closed source built on the OOo code base, e.g., Symphony, et cet.
      And that has huge signficance once you realize that ODF is not the real standard; the OOo code base is the real ODF standard. Look around the world and you see that ODF adoption decisions by governments are all in reality decisions to go with StarOffice, OOo, or OOo clones. I haven't, for example, seen a single instance where a government decided to ride with KOffice. Why would they, with the interop issues between KOffice and OOo? The fact that OOo's code base is the real ODF standard will figure strongly in the comments. Couple it with Sun's iron-fisted control of the OOo code base, and you have vendor lock-in with a Microsoft partner.
      But with 70 developers committed in China, where developers salaries are inexpensive, IBM will soon be in a position to threaten to fork the OOo code base using proprietary extensions. Is that their real tactic to force changes in licensing and gov
Gary Edwards

The Case for Harmonization (that IBM will vote against anyway) « A Frantic Op... - 0 views

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

Re: [office-comment] Public Comment - 0 views

  • Regarding section 1.5 itself: The Open Office TC decided to use the term MAY rather than MUST (or will) at the mentioned location, because it wanted to ensure that the OpenDocument specification can be used by as many implementations as possible. This means that the format should also be usable by applications that only support a very small subset of the specification, as long as the information that these applications store can be represented using the OpenDocument format. A requirement that all foreign elements and attributes must be preserved actually would mean that some applications may not use the format, although the format itself would be suitable. Therefor, we leave it up to the implementations, which elements and attributes of the specification they support, and whether they preserve foreign element and attributes. Some more information about this can be found in appendix D of the specification.
    • Gary Edwards
       
      This OASIS ODF discussion is about the Compliance - conformance clause of the ODF specification: Section 1.5. A developer has complained that use of MAY instead of MUST in the wording of the clause would enable conforming applications to destroy foreign elements and alien attribute markup at will. This of course would result in ZERO Interoeprability!!!!! The foreign elments and alien attributes were included for the purposes of improved ODF compatibility with the billions of MSOffice binary documents that would need to be converted to ODF. Sadly, the section 1.5 loop hole falls short of the compatibility goal, but that only begins to scratch the surface of the ODF problems. OpenOffice only supports foreign elements and alien attributes for text spans, and paragraphs!!!!!! All other such markup is unrecognized and therefore "destroyed" by OpenOffice. ZERO interop. No roundtripping with MSOffice desktops. Lossy conversion with jagged fidelity. Guaranteed.
‹ Previous 21 - 40 of 62 Next › Last »
Showing 20 items per page