Skip to main content

Home/ OpenDocument/ Group items tagged convert

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Gary Edwards

Open Document Foundation Gives Up | Linux Magazine - 0 views

www.linux-magazine.com/...n_document_foundation_gives_up

cdf odf ooxml w3c

shared by Gary Edwards on 16 Nov 07 - Cached
  • The reasons for the move to CDF was improved compatibility with Microsoft’s OOXML format the foundation claimed at the time. Cris Lilley from W3C contradicted. CDF is not an office format, and thus not an alternative to the Open Document Format. This turn-down is likely the reason for the abrupt ditching of the foundation.
  • Gary Edwards on 16 Nov 07
     
    I've got to give this one extra points for creativity!  All anyone has to do is visit the W3C web sites for CDF WICD Full 1.0 to realize that there is in fact a CDf profile for desktops.  CDF WICD Mobile is the profile for devices.

    My guess is that Chris Lilley is threading the needle here.  IBM, Groklaw, and the lawyer for OASIS have portrayed the Foundation's support for CDF WICD Full as a replacement for ODF - as in native file format for OpenOffice kind of replacement.  Mr. Lilley insists that CDF WiCD Full was not designed for that purpose.  It's for export only!  As in a conversion of native desktop file formats.

    Which is exactly what the da Vinci group was doing with MSOffice.  The Foundation's immediate interest in CDF WICD was based on the assumption that a similar conversion would be possible between OpenOffice ODF and CDF WICD.

    The Foundation's thinking was that if the da Vinci group could convert MSOffice documents and processes to CDF WICD Full, and, a similar conversion of OpenOffice ODF documents and processes to CDF WICD could be done, then near ALL desktop documents could be converted into a highly interoperable web platform ready format.

    Web platform ready documents from OpenOffice?  What's not to like?  And because the conversion between ODF and CDF WICD Full is so comparatively clean, OpenOffice would in effect, (don't go native file format now) become ahighly integrated rich client end user interface to advancing web platforms.

    The Foundation further reasoned that this conversion of OpenOffice ODF to CDF WICD Full would solve many of the extremely problematic interoperability problems that plague ODF.  Once the documents are in CDF WICD Full, they are cloud ready and portable at a level certain to diminish the effects of desktop applications specific feature sets and implementation models.

    In Massachusetts, the Foundation took
Gary Edwards

ODF Split: Good Riddance, Good Grief, or Game Over? Michael Desmond Redmond Developer ... - 0 views

reddevnews.com/...weblog.aspx

cdf foundation odf ooxml opendocument

shared by Gary Edwards on 13 Dec 07 - Cached
  • Gary Edwards on 13 Dec 07
     
    Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~
  • Gary Edwards on 13 Dec 07
     
    Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~
Gary Edwards

Front-page: Matusow backs the French proposal? - 0 views

www.noooxml.org/...usow-backs-the-french-proposal

afnor cdf merger odf ooxml opendocument

shared by Gary Edwards on 11 Dec 07 - Cached
  • But markets and governments understand that Open Document is the appropriate standard to replace the old Microsoft binary formats for office communication.
  • Gary Edwards on 11 Dec 07
     
    When did this happen? Th eonly thing markets and government pilot studies show is that it's IMPOSSIBLE to convert existing MSOffice documents to ODF. And even if you are able to do a lossy conversion, there is no way to convert back again without serious loss processing specific informaiton. (round tripping - which is critical to business process document exchange and routing).
Paul Merrell

Doug Mahugh : Office support for document format standards - 0 views

blogs.msdn.com/...document-format-standards.aspx

interop microsoft odf strategy

shared by Paul Merrell on 22 May 08 - Cached
  • Third-party translators. We anticipate that some developers may want to take over the default ODF load and save paths, so that they can plug in their own translators for ODF, and we'll be providing an API in SP2 that enables this scenario. This means that if a developer disagrees with the details of our approach and would like to implement ODF for Office in a different way, they're free to do so and can set it up such that when a user opens an ODT attached to an email or from their desktop, it will be loaded through their ODF code path.
    • Paul Merrell
      Paul Merrell on 22 May 08
       
      The Third-party translators discussion of the forthcoming new API suggests that it is for ODF only, and thereby implicitly that it will not be a tool for accessing the full functionaolity of MS Word, i.e., that only the functionality specified in ODF 1.1 will be available. E.g., no control of Sharepoint functionality or manipulation of the Microsoft cloud through the API from OpenOffice.org via ODF. .
    • Jesper Lund Stocholm
      Jesper Lund Stocholm on 23 May 08
       
      The Microsoft cloud depends heavily on OOXML, and that is likely not going to change. Are you saying that you'd prefer a plug-in mechanism in SharePoint as well? I believe the protocols used by SharePoint are included in the specs now provided. Won't that do (apart from the non-commercial usage of the specs)
  • If you're an Office 2007 user, the image above probably looks pretty familiar. But look close, and you'll see some Save-As options you've not seen before here: OpenDocument, and (unless you have the existing add-in) PDF & XPS.
  • There is new information today about the planned release of v2.0 of the ODF translator on the ODF translator team blog. The SourceForge translator projects will continue to move forward, and Microsoft will continue to be an active participant in these projects.
  • ...2 more annotations...
  • This is a screen shot of a pre-release copy of SP2 (Service Pack 2) for the 2007 Microsoft Office System, showing the new document format standards that we'll be supporting starting with SP2.
    • Paul Merrell
      Paul Merrell on 23 May 08
       
      Hi, Jesper. according to another article I found later, the new APIs (I assume it should be plural rather than singlular) will allow addition of formats other than ODF, so I apparently got that part wrong. On the Sharepoint example, I wasn't sufficiently clear and apologize. Assume you create a document in MS Office that invokes Sharepoint functionality, then you save it as ODF and ship it off to a co-worker using OOo. The OOo user wants to send it back to you for further processing. But if saving to ODF in Office wipes the Sharepoint metadata, you've got data loss on the outbound trip. The path you suggest would work at least in theory (I haven't heard any reports yet of the documentation on the Sharepoint APIs) if Sharepoint were used as an intermediary hub. But the Sharepoiint document may not be accessible to the co-worker, e.g., because of page security settings. I anticipate that there would be many cases where only one end of the trip has access to the hub, so there's a need to keep the path open that bypasses the hub and for it to be non-lossy. There is an article on BetaNews by Scott Fulton that interviews a couple of the Softies. They said that there will be lots of Office functionality that won't be able to be saved in ODF, that they're not planning a compatability mode that would block use of features that can't be saved to ODF, and that they're not planning to go beyond the features specified in ODF 1.1. So if they carry through on what they said, the outbound trip to ODF implementations will be lossy. I think the real problem with the Sharepoint specs and other documentation Microsoft is releasing is that it isn't in a standard where a technical committee could say yea or nay on whether it is suffiiciently specific and where the specs can be made vendor-neutral. In other words, that Micrsooft is in control of the specifiation rather than a standards body. Microsoft got away so far with creating a de facto standard for the line of business functional
    • Paul Merrell
      Paul Merrell on 23 May 08
       
      Hi, Jesper. according to another article I found later, the new APIs (I assume it should be plural rather than singlular) will allow addition of formats other than ODF, so I apparently got that part wrong. On the Sharepoint example, I wasn't sufficiently clear and apologize. Assume you create a document in MS Office that invokes Sharepoint functionality, then you save it as ODF and ship it off to a co-worker using OOo. The OOo user wants to send it back to you for further processing. But if saving to ODF in Office wipes the Sharepoint metadata, you've got data loss on the outbound trip. The path you suggest would work at least in theory (I haven't heard any reports yet of the documentation on the Sharepoint APIs) if Sharepoint were used as an intermediary hub. But the Sharepoiint document may not be accessible to the co-worker, e.g., because of page security settings. I anticipate that there would be many cases where only one end of the trip has access to the hub, so there's a need to keep the path open that bypasses the hub and for it to be non-lossy. There is an article on BetaNews by Scott Fulton that interviews a couple of the Softies. They said that there will be lots of Office functionality that won't be able to be saved in ODF, that they're not planning a compatability mode that would block use of features that can't be saved to ODF, and that they're not planning to go beyond the features specified in ODF 1.1. So if they carry through on what they said, the outbound trip to ODF implementations will be lossy. I think the real problem with the Sharepoint specs and other documentation Microsoft is releasing is that it isn't in a standard where a technical committee could say yea or nay on whether it is suffiiciently specific and where the specs can be made vendor-neutral. In other words, that Micrsooft is in control of the specifiation rather than a standards body. Microsoft got away so far with creating a de facto standard for the line of business functional
  • Paul Merrell on 22 May 08
     
    "This is a screen shot of a pre-release copy of SP2 (Service Pack 2) for the 2007 Microsoft Office System, showing the new document format standards that we'll be supporting starting with SP2."
  • Jesper Lund Stocholm on 23 May 08
     
    "This is a screen shot of a pre-release copy of SP2 (Service Pack 2) for the 2007 Microsoft Office System, showing the new document format standards that we'll be supporting starting with SP2."
Graham Perrin

Doug Mahugh : 1 + 2 = 1? - 0 views

blogs.msdn.com/...1-2-1.aspx

shared by Graham Perrin on 13 May 09 - Cached
  • five prioritized guiding principles for Office’s ODF implementation
  • When Will Office Support OpenFormula?
  • nobody knows yet when ODF 1.2 will be published as an OASIS or ISO standard
  • ...4 more annotations...
  • risk that the results might not be the same
  • Open XML / ODF Translator Add-Ins for Office can be used with Office 2007 SP2
  • Sun ODF Plugin
  • apparently works with SP2
Gary Edwards

Slamming the door shut on MS OOXML - 0 views

lists.oasis-open.org/...msg00033.html

cdf interoperability iso odf odf-tc officeopenxml ooxml opendocument xml

shared by Gary Edwards on 24 Aug 07 - Cached
  • So your goal is a networked world where metadata is routinely trashed by apps developed by those who are too dumb or otherwise disabled to preserve metadata and only the big boys get to do interoperability, right? So if I send you a document for your editing, I can't count on getting it back with xml:id attributes intact. No thanks, Patrick. That sounds way too much like how things have worked ever since office productivity software first came on the market. In your world, interoperability belongs only to those who can map features 1:1 with the most featureful apps. And that is precisely why OpenDocument never should have been approved as a standard. Your kind of interoperability makes ODF a de facto Sun Microsystems standard wearing the clothing of a de jure standard. Why not just standardize the whole world on Microsoft apps and be done with it? Are two monopolies maintained by an interoperability barrier between them better than one? Fortunately, we don't have to debate the issue because the Directives resolve the issue. You lose under the rules of the game.
  • Gary Edwards on 24 Aug 07
     
    Marbux on metadata and the language of universal interoperability: Few people are aware of the raging debate that has pushed ODF to the edge. The OASIS ODF TC is split between those who support Universal Interoperability, and those who insist on continuing with limited ODF interoperability.

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

    Many mistakenly believed that submission of ODF to ISO and subsequent approval as an international standard would provide an effective separation, putting ODF on the track of a truly universal file format.

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

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

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

    It's a devastating argument.

Gary Edwards

We've Been Had! - 0 views

www.computerworld.com/...9027164

iso odef odf ooxml openwave xhtml xml

shared by Gary Edwards on 20 Jul 07 - Cached
  • There is nothing open about MOOXML, and it should have never made it to consideration as an international standard. But one has to ask, what is up with Sun? The John Bosak comment is just as much cause for concern as the fact that the nations of the world would dare consider OOXML as an international standard. All i can say is that we've been had. Sun and Microsoft have worked us royally, and only now, at the last moment, does the fog of confusion clear and we can see it all.
  • Gary Edwards on 20 Jul 07
     
    Yeah.  I said this!  And i still think ODF has what it takes to become a universal file format.  But only if the "interoperability enhancment" proposals are made part of the specification.  You can't talk your way to universal interop.   It has to go into the spec!

    OBTW, for you idiots who think i support OOXML as a standard?  You're idiots.  I support the quest for a universal file format that is totally application, platform and vendor independent.  The requirements, demands and criticisms we make of OOXML should be applied to every file format up for universal file format consideration.  Including ODF.  Including XHTML+ (XHTML, CSS3, RDF).  Including the EU IDABC "ODEF".

    The one area where i differ from most universal interoperability seekers is that i fully believe the big vendors have left open a loop hole we can exploit.  The plugin architecture is fully able to convert a big vendors application to produce our beloved but elusive universal file format. 

    This is important because the big vendors control "interoperability" by contolling the big vendor standards consortia, and, the major applications.  It's a double edged sword.

    The ubiquitous plugin architecture enables universal interop seekers to exploit the applications any way we want.  What's missing is a truly open "universal" standards process that is outside the reach of big vendors. 

    Personally i like the recent GPL3 process as a model on which to base emerging universal standards work.  Somehow the big vendors must be neutralized.  Otherwise, we;ll never see the universal inteop the world so desires.

    idiots,
    ~ge~

  • Gary Edwards on 23 Jul 07
     
    The "Backwards Compatibility" issue is all the rage at ISO, with the September vote on MS OOXML just a month away.

    Microsoft and Sun (We've Been Had!) are arguing that ISO should approve MS OOXML (Microsoft OfficeOpenXML) because OOXML offers a backwards compatibility with the legacy of existing billions of binary documents.

    This oft sighted history of Microsoft's reprehensible business practices is worth citing once again before the nations of the world go down that treacherous path towards ratifying Microsoft's proprietary systems and products as international standards.



Gary Edwards

Bringing Open Source to SOAs - 0 views

www.eweek.com/...0,1895,2155922,00.asp

apache eclipse opensource oss soa

shared by Gary Edwards on 15 Jul 07 - Cached
  • Vendors such as Iona Technologies, Red Hat, MuleSource, WSO2, Sun Microsystems and even IBM are pushing open-source components as key pieces of service-oriented architecture implementations.
  • Iona is heading the Eclipse Foundation's SOA Tools Platform Project, which is building frameworks and tools that enable the design, configuration, assembly, deployment, monitoring and management of software designed around a service-oriented architecture.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      This is certainly a big win for IBM hardware and Services.   I wonder how IONA plans to compete against IBM when IBM hardware and services can combine a one tow enterprise punch usign IONA open source efforts?

      I hope the IONA guys know what they're doing.  Or this could get ughly.

  • MuleSource CEO Dave Rosenberg, in San Francisco, agreed. "One of the key goals of SOA is to free up your IT environment from burdensome proprietary standards and vendor stacks that lock you in," he said. "In order to truly control your environment, open source is the only answer." MuleSource maintains the open-source Mule ESB.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      1

      A big 1
  • ...1 more annotation...
  • Shaun Connolly, vice president of JBoss, said that the company's "application platform, Web apps, Web services, portal and the overall SOA platform provides more service bus integration for a more open and integrated platform."
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      This is sad.  Red Hat does not yet understand how important the portable XML dcoument/data file format wars are to the future of SOA.  The Microsoft Vista Stack, based on OOXML-Smart Documents as the inter application stack transport, will effectively lock Red Hat out of any enterprise transitioning from MSOffice bound business processes.

      I guess it's because open source vendors don't see the MSOffice <> MS Exchange/SharePoint Hub as part of a SOA solution, that they don't see the importance of OOXML-SmartDocs.

      Red Hat Servers are under assault throughout the USA as Exchange/SharePoint Hub server system move in.  The E/S Hubs have an extraordinary connectivity to existing MSOffice desktops, with OOXML-Smart Docs as the transport connecting the two.

      The only way Red Hat could ever hope to crack that Vista Stack is by using ODF plugins at the head point; MSOffice bound business processes.

      The idea being to let the plugin convert existing documents and business processes to ODF in much the same way that the OOXML plugin for MSOffice carries out the non disruptive conversion to OOXML.

  • Gary Edwards on 15 Jul 07
     
    An eWEEK must read.  I think the recent aquisition is having a positive impact on the eWEEK journalist and reporters.   What a great series they've put together on SOA. SaaS and the Web 2.0
Gary Edwards

2. WordprocessingML Reference Material - OOXML-Wiki - 0 views

www.xmlopen.org/...rocessingML_Reference_Material

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

shared by Gary Edwards on 11 Jul 07 - Cached
  • It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following features:
  • It is desired to have improved interoperability between ODF and OOXML. However, OOXML lacks the following feature: image can be positioned absolutely within a frame Proposed change: Include support for this feature from ISO ODF in order to improve interoperability between the two formats.
    • Gary Edwards
      Gary Edwards on 11 Jul 07
       
      Include support for this feature in ISO ODF is another way of saying to hell with Ecma, OASIS and the big vendors driving the ODF-OOXML bus, Micrsoft and Sun. This is delicious beyond belief. It's also the only way the world is going to get the interoperability they are demanding. The big vendors must be neutralized. The file formats must be completely independent of applications, platforms and the control of big vendors who routinely make exclussionary interoperabilty deals with each other whenever and wherever profitable.
  • Gary Edwards on 11 Jul 07
     
    I promise that within a few minutes of reading this OOXML Wiki you will be wondering if this is in fact an ODF Wiki!  This is incredible.

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

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

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

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

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

    Not OASIS ODF!  Not Ecma OOXML.

    ISO ODf!

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

    This is
Gary Edwards

Microsoft trounces pro-ODF forces in state battles over open document formats - 0 views

www.computerworld.com/...article.do

shared by Gary Edwards on 09 Jun 07 - Cached
  • Microsoft trounces pro-ODF forces in state battles over open document formats Eric Lai and Gregg Keizer &nbsp; document.write(''); if (navigator.userAgent.indexOf("Gecko")==-1) { document.write(''); } document.write(''); if (document.getElementById('dclk999')) { document.getElementById('dclk999').src = 'http://ad.doubleclick.net/adi/idg.us.cpw.desktopapplications/index;pos=imu;tile=3;sz=336x280;ord=' + ord + '?'; } document.write(''); if ((!document.images && navigator.userAgent.indexOf('Mozilla/2.') >= 0)|| navigator.userAgent.indexOf("WebTV") >= 0) {document.write('');} June 03, 2007 (Computerworld)
  • Keeping it private The other problem, Mathers said, was the jargon-laden disinformation that committee members felt they were being fed by lobbyists for both IBM and Microsoft. Although lobbyists would tell the committee one thing in private, they got cold feet when asked to verify the information publicly, under oath. "Suddenly, nobody wanted to sign witness affirmation forms and testify," he said. That undermined the credibility of each side, but it particularly damaged the position of ODF proponents. After Wyne testified publicly that in Massachusetts, only a handful of computers had thus far been converted over to using ODF,&nbsp;IBM declined to dispute her claims, Mathers said -- despite having earlier given "gleaming" reports on the progress of ODF in Massachusetts. "That's when I really started to question the whole bill," he said.
  • Gary Edwards on 09 Jun 07
     
    Uh Oh.  They got IBM dead to rights in Massachusetts.  I guess the truth about Massachusetts will be told!  Finally.  ODF failed in Massachusetts because there isn't a reasonable  means of implementing ODF.  Same in California.
  • Gary Edwards on 09 Jun 07
     
    A must read.  And yes, the ODF Vendors are the reason ODF lost.  They didn't provide useful solutions.  In fact, the applicaitons they proposed were seen by government CIO's as cstly and disruptive "rip out and replace" non starters.  In California, CIO's asked if it was even possible to implement ODF!!!
Gary Edwards

Microsoft Will Support ODF! But Only If ISO Doesn't 'Restrict Choice Among Formats' - 0 views

www.betanews.com/...1181922127

ecma-376 iso microsoft odf officeopenxml ooxml opendocument xml

shared by Gary Edwards on 19 Jun 07 - Cached
  • 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.
  • Gary Edwards on 19 Jun 07
     
    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
Gary Edwards

Billions of Legacy Binary Documents -- gary_edwards's comment on &quot;Linux leaders pl... - 0 views

talkback.zdnet.com/5208-3513-0.html

ecma-376 iso microsoft odf officeopenxml ooxml opendocument xml

shared by Gary Edwards on 19 Jun 07 - Cached
  • 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.
  • Gary Edwards on 19 Jun 07
     
    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
Gary Edwards

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

weblog.infoworld.com/...013777.html

cdf html odf officeopenxml ooxml opendocument

shared by Gary Edwards on 12 Sep 07 - Cached
  • the fact is that Redmond could own this new space if it wanted to. All it would need to do is push interoperability and integration between lightweight Web versions of Office applications and its desktop fatware. Advanced features would be absent from the lightweight versions, but the company could ensure any Office doc would load on the Web -- whatever new desktop service packs and upgrades might appear -- and online document management could be integrated with Windows for offline access.
  • Gary Edwards on 12 Sep 07
     
    Great quote from Eric Knorr.  He hits the nail on the head here, pointing out the problem Office 2.0  Web Apps and SaaS apps face:  If these Web wonders have interoperability and high fidelity document exchange with MSOffice, their collaborative features are value added wonders for existing business processes and workgroup-workflow scenarios.  If, on the other hand they lack this level of interop - integration with MSOffice documents and processes, the value add becomes a problematic split in a business process.  The only way to overcome that kind of a split is to take the entire process.  Which is difficult for lightweight mashup happy web wonders to do.

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

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

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

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

Brian Jones: Open XML Formats : Mapping documents in the binary format (.doc; .xls; .pp... - 0 views

blogs.msdn.com/...pt-to-the-open-xml-format.aspx

burtongroup cdf css ibm iso microsoft odf okelly ooxml opendocument openxml sun w3c xhtml

shared by Gary Edwards on 20 Jan 08 - Cached
  • The second issue we had feedback on was an interest in the mapping from the binary formats into the Open XML formats. The thought here was that the most effective way to help people with this was to create an open source translation project to allow binary documents (.doc; .xls; .ppt) to be translated into Open XML. So we proposed the creation of a new open source project that would map a document written using the legacy binary formats to the Open XML formats. TC45 liked this suggestion, and here was the TC45 response to the national body comments: We believe that Interoperability between applications conforming to DIS 29500 is established at the Office Open XML-to- Office Open XML file construct level only.
    • Gary Edwards
      Gary Edwards on 20 Jan 08
       
      And here i was betting that the blueprints to the secret binaries would be released the weekend before the September 2nd, 2007 ISO vote on OOXML! Looks like Microsoft saved the move for when they really had to use it; jus tweeks before the February ISO Ballot Resolution Meetings set to resolve the Sept 2nd issues. The truth is that years of reverse engineering have depleted the value of keeping the binary blueprints secret. It's true that interoperability with MSOffice in the past was near entirely dependent on understanding the secret binaries. Today however, with the rapid emergence of the Exchange/SharePoint juggernaught, interop with MSOffice is no longer the core issue. Now we have to compete with E/S, and it is the E/S interfaces, protocols and document API's and dependencies tha tmust be reverse engineered. The E/S juggernaught is now surging to 70% or more of the market. These near monopoly levels of market penetration is game changing. One must reverse engineer or license the .NET libraries to crack the interop problem. And this time it's not just MSOffice. Today one must crack into the MS Stack whose core is tha tof MSOffice <> E/S. So why not release the secret binary blueprints? If that's the cost of getting the application, platform and vendor specific OOXML through ISO, then it's a small price to pay for your own international standard.
  • Gary Edwards on 20 Jan 08
     
    Well well well. We knew that IBM had access to the secret binary blueprints back in 2006. Now we know that Sun ALSO had access!
    And why is this important? In June of 2006, Massachusetts CIO Louis Gutierrez asked the OpenDocument Foundation's da Vinci Group to work with IBM on developing the da Vinci ODF plug-in clone of Microsoft's OOXML Compatibility Pack plug-in. When we met with IBM they were insistent that the only way OASIS ODF could establish sufficient compatibility with MSOffice and the billions of binary documents would be to have the secret blueprints open.
    Even after we explained to IBM that da Vinci uses the same internal conversion process that the OOXML plug-in used to convert binaries, IBM continued to insist that opening up the secret binaries was a primary objective of the OASIS ODF community.
    For sure this was important to IBM and Sun, but the secret binaries were of no use to us. da Vinci didn't need them. What da Vinci needed instead was a subset of ODF designed for the conversion of those billions of binary documents! A need opposed by Sun.
    Sun of course would spend the next year developing their own ODF plug-in for MSOffice. But here's the thing: it turns out that Sun had complete access to the secret binary blueprints dating back to 2006!!!!!!
    So even though IBM and Sun have had access to the blueprints since 2006, they have been unable to provide effective conversions to ODF!
    This validates a point the da Vinci group has been trying to make since June of 2006: the problem of perfecting a high fidelity conversion between the billions of binaries and ODF has nothing to do with access to the secret binary blueprints. The real issue is that ODF was NOT designed for the conversion of those binary documents.
    It is true that one could eXtend ODF to achieve the needed compatibility. But one has to be very careful before taking this ro
Gary Edwards

Interoperability Enhancement Proposal: Suggested ODF1.2 items - 0 views

lists.oasis-open.org/...msg00048.html

foundation interop ix odf odfix opendocument subset

shared by Gary Edwards on 20 Jan 08 - Cached
  • Subject: Suggested ODF1.2 items From: "Florian Reuter" &lt;freuter@novell.com&gt; To: &lt;office@lists.oasis-open.org&gt; Date: Mon, 20 Nov 2006 17:03:24 +0100
  • Gary Edwards on 20 Jan 08
     
    This is the fifth of the six major iX - interoperability enhancement proposals submitted to the OASIS ODF TC - SC between July 2006 and February of 2007. This particular iX proposal lead to the "List Enhancement Proposal" donnybrook that consumed the OASIS ODF TC for the next six months, ending with the OpenDocument Foundation being booted out of OASIS in May of 2007. The six iX proposals were all different approaches to the same basic problem: ODF was not desinged to be interoperable with MSOffice documents, applications or bound processes. The proposals come out of the OpenDocument' Foundation's efforts to save ODF in Massachusetts. ODF iX repressents a subset of ODF designed to grealty improve compatibility with MS binary and XML formats. With the ODF iX subset, the da Vinci plug-in would be able to convert the billions of MSOffice binary and xml documents with a very high level of fidelity, and do so within the bounds of "round trip" business processes. The most basic iX approach was to add five generic elements to the existing ODF specification. The five generic elements would cover lists, tables, fields, sections, and page dynamics (breaks). It is a well known fact that these five areas of incompatibility between OpenOffice ODF and MSOffice binaries represent 95% of all conversion fidelity problems. MSOffice has one way of implementing lists, and, OpenOffice has another. These application specific implementation models are irreconcilably different. It's also true that the applicaiton specific implementation models are directly reflected in each file format. So applications implementing ODF must also implement the OpenOffice model for lists, fields, tables, sections and page dynamics-page positioning if they are to have any meaningful measure of exchange fidelity. Perhaps the best of the iX approaches was that based on the innovative use of metadata to describe presentation-layout attributes.
Gary Edwards

Open Stack: ISO Does The Unthinkable. How ISO approval of MSOffice-OOXML will break th... - 0 views

openstack.blogspot.com/...ment-as-perfect-microsoft.html

css davinci interoperability msoffice odf ooxml xaml xhtml

shared by Gary Edwards on 22 Apr 08 - Cached
  • In August of 2007 we dropped ODF as the da Vinci target conversion format, and moved to the W3C's Compound Document Format (CDF) with an ePUB wrapper.The reason for this move is that we could not establish a reasonable degree of interoperability with OpenOffice ODF unless Sun supported the five generic eXtensions to ODF needed to hit the high fidelity conversion the da Vinci process is capable of.Since da Vinci is a clone of the MSOffice OOXML compatibility Kit, we use the same internal conversion process where imbr (in-memory-binary-representation) is converted to another format: imbr &lt;&gt; OOXML or, imbr &lt;&gt; RTF.While it's entirely compliant to eXtend ODF, without Sun's changes to OpenOffice ODF the application-platform-vendor independent interoperability end users expect would be meaningless.The problem as we see it is this; it is impossible to do a high fidelity conversion between two application specific XML formats. It is however quite possible to do a conversion between an application specific format and a generic (application-platform-vendor independent) format.
  • Gary Edwards on 22 Apr 08
     
    A summary of my views on ISO approval of MSOffice-OOXML and the impact it will have on the futrue of the open web.
  • Gary Edwards on 22 Apr 08
     
    In response to a recent question posted to a rather old OpenStack blog, i posted this summary of my views on ISO approval of MSOffice-OOXML and the impact it will have on the futrue of the open web.
Gary Edwards

XML-Empowered Documents Extend SOA's Connection to People and Processes | BriefingsDire... - 0 views

briefingsdirect.blogspot.com/...red-documents-extend-soas.html

cloud-computing collaborative-computing paas saas soa woa

shared by Gary Edwards on 07 Apr 08 - Cached
  • We're going to talk about dynamic documents. That is to say, documents that have form and structure and that are things end-users are very familiar with and have been using for generations, but with a twist. That's the ability to bring content and data, on a dynamic lifecycle basis, in and out of these documents in a managed way. That’s one area.The second area is service-oriented architecture (SOA), the means to automate and reuse assets across multiple application sets and data sets in a large complex organization.We're seeing these two areas come together. Structured documents and the lifecycle around structured authoring tools come together to provide an end-point for the assets and resources managed through an SOA, but also providing a two-way street, where the information and data that comes in through end-users can be reused back in the SOA to combine with other assets for business process benefits.
  • Thus far we’ve been talking about the notion of unstructured content as a target source to SOA-based applications, but you can also think about this from the perspective of the end application itself -- the document as the endpoint, providing a framework for bringing together structured data, transactional data, relational data, as well as unstructured content, into a single document that comes to life.Let me back up and give you a little context on this. You mentioned the various documents that line workers, for example, need to utilize and consume as the basis for their jobs. Documents have unique value. Documents are portable. You can download a document locally, attach it to an email, associate it with a workflow, and share it into a team room. Documents are persistent. They exist over a period of time, and they provide very rich context. They're how you bring together disparate pieces of information into a cohesive context that people can understand.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      "various line of business applications and composite applications" is exactly where ODF failed in Massachusetts! Think of client/server, with many business processes bound to MSOffice on the client side. The big ODF vendors tried to convince Massachusetts to "rip out and replace" MSOffice. Which proved to be terribly disruptive and costly. These bound "client side" processes would have to be rewritten, and none of the ODF applications were the equivalent of MSOffice as a developers platform (even if the cost was something MASS was willing to pay for - which they were not!). MASS came up with an alternative idea to save ODF, the idea of cloning the OOXML plug-in for MSOffice to create an ODF plug-in. The problem was that MASS did not have an IT budget thanks to Microsoft's political mucking. So MASS CIO Louis Gutierrez turned to the big vendors askign them to support something they seriously opposed. An ODF plug-in would leave MSOffice in place.
  • ...8 more annotations...
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      This paragraph says it all. The portable document is an essential frame for moving information thoughout the emerging client/ Web Stack /server information infrastructure model. The key is that the portable docuemnts are interactive and "live". The data and media streams bound to objects within the documents are attached to their original sources using XML connecting streams like XMLHTTPRequest or P2P Jabber XML routers. In 2003 we used Jabber to hot wire Comcast documents (docs, spreadsheet cells and presentations) to backend transactional blackboxes and web service rich data resources. The productivity gain from this approach is that end users are no longer required to verify and manage data. The "system" manages the data, freeing the end user to concentrate on the task of presentation, analysis and explanation.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      What? The key to client/ Web Stack /server design (advanced SOA) is to have a desktop "editor" that writes highly strucutred XML docuemnts that are universally portable across a wide range of Web Stacks. The W3C provides CDF as a very advanced docuemnt container for the purpose of porting complex documents across a wide range of "editors", servers, and devices. (X)HTML 2.0 - CSS3, SVG, XForms and RDF are the core components of the open web future where complex documents and business processes will move to client/ Web Stack /server models. The problem is that there are NO desktop "editors" capable of producing CDF. ISO approval of MS-OOXML stamps MSOffice as a standards compliant "editor". The problem is that it is very difficult to convert MS-OOXML documents to CDF - XHTML-CDF-SVG-RDF!!! The MSOffice SDK does provide an easy to implement MS-OOXML <> XAML conversion component. XAML itself is part of the proprietary WPF set of technologies, joining Silverlight, Smart Tags, and WinForms as a complete MS-Web ready alternative to advanced W3C technolgoies: XHTML, CSS, SVG, XForms, and RDF. XAML "fixed/flow" replaces XHTML-CSS. Silverlight replaces SVG and SWF (Flash). Smart Tags is a porprietary alternative to RDF-RDFa. And WinForms is of course an alternative to XForms. The MS Web STack core s comprised of Exchange, SharePoint and MS SQL Server. The core is joined by Windows Server, MS Dynamics, and MS Live (among so many). ISO approval of MS-OOXML provides the MS Cloud with a standards compliant "editor" that currently ownes OVER 95% of the desktop marketshare when it comes to bound business processes. With ISO approval, an entire generation of client/server processes can now transition to client/ Web Stack /server models, where they can take full advantage of the advanced SOA model where portable XML documents move structured data and media through a highly distributed but end user controlled web model.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      OK. Nice summary!
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      Uh oh. Does Mr. Sorofman understand the importance of MSOffice-OOXML-XAML-Smart Tags as an alternative to W3C RDF? This split in the Web will result in a nightmare for Google. Think of it as though Google owns the consumer side of the web, and Microsoft owns the business process side. Such is the importance of ISO approval of MS-OOXML! Google will be unable to match the search advantages of either RDF or Smart Tags. With Smart Tagged docuemnts though, Google won't even get the chance to compete. They will be locked out of the document processing chain that begins with MSOffice-OOXML and extends through a proprietary MS Web STack rich with XAML, Silverlight, WinForms and Smart Tag semantics! Although hindsight is 20-20, we can look back at 2006 in Massachusetts and see that the failure of ODF there is going to result in huge losses to Google and Oracle. Google will find themselves locked into a consumer web box, unable to branch out to business. Oracle will find themselves on the wrong side of a Microsoft dominated client/ Web Stack /server based transition of legacy client/server systems.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      Great idea Mr. Sorofman, but Microsoft owns the "editor" in this equation.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      Another good summary statement. Convergence however is very much tied to interoperability across the emerging client/ Web-Stack /server model that represents advanced SOA, SaaS, Web 2.0 and emerging Cloud Computing models.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      What we found at Comcast in 2002-2003 was many spreadsheet "templates" that the sales staff used to keep track of inventory, pricing, and client accounts. By P2P enabling the cells in these templates, we were able to connect in transactional database information in real time ( or web connect time :). Every template, whether it was a writer document,-form, spreadsheet template, or presentation deck was P2P Jabber wired at the object level wherever an external information source was invloved. Which seemed to be everywhere! The hard work is getting the XML connectors in place, setting up an information stream between the Web Stack (Apache Tomcat - MySQL-XUL Server), and the backend transational black boxes. With Comcast this was done through a 24 hour dump cycle with each black box dumping and uploading from the Web Stack. For sales, marketing and management, the Web Stack did the heavy business of serving up Jabber data and resolving order conflicts. The "system" took over the management and verification of data, releasing the sales force to concentrate on their primary task.
    • Gary Edwards
      Gary Edwards on 15 Apr 08
       
      In Massachusetts, they were using eMail to shuttle spreadsheet templates around. This is about as brittle and unproductive a method as there is, but it was all they had. Rather than focusing on keeping their client side business processes operating, MASS might have been better off focusing on building a client/ Web-Stack /server model they could gradually transition these desktop bound processes to. Establish an open Web-Stack design, and work back towards the desktop client. Instead, MASS fell into the trap of trying to replace MSOffice on the desktop with ODF OpenOffice based alternatives, while simultaneously purchasing Exchange-SharePoint Web-Stack components! The MS Web-Stack is designed for MSOffice-OOXML business processes, not ODF!!!!!
  • Gary Edwards on 07 Apr 08
     
    Dana Gardner transcript of podcast interview with JustSystems and Phil Wainwright. Covers the convergence of the portable XML document model with SOA. It's about time someone out there got it. You know the portable XML document has arrived when analyst finally get it.
Gary Edwards

Issue 51726: OpenOffice ODF Graphics Nightmare - 0 views

www.openoffice.org/...show_bug.cgi

application-specific din florian-reuter graphics odf openoffice

shared by Gary Edwards on 25 Jan 08 - Cached
  • Currently, the above given specification is a draft and has to be adjusted. Beside the change of the context menu and the navigator it's is needed to adjust the import of the XML file formats (OpenDocument and OpenOffice.org) and the export to the OpenOffice.org file format. The import needs adjustment, because the existence of name is used to distinguish Writer graphics/text boxes and Draw graphics/text boxes. The new criterium is now, that Draw graphics/text boxes of Writer documents doesn't have a parent style. The export to the OpenOffice.org file format needs adjustment, because a Writer document in the OpenOffice.org file format doesn't contain names for shapes.
    • Gary Edwards
      Gary Edwards on 25 Jan 08
       
      The EU DIN effort to harmonize or merge ODF and OOXML has uncovered some incredible inconsistencies in OpenOffice ODF tht will break interop every time, guaranteed. This particular issue has to do with problems naming graphics, and the hack solution now in use. It's hacks like this that make it impossible to convert MSOffice binaries to ODF.
Gary Edwards

Denmark: OOXML vote won't affect public sector. ODF is too costly! | InfoWorld - 0 views

www.infoworld.com/...t-Denmark-public-sector_1.html

brm denmark geneva iso msoffice odf ooxml opendocment openxml

shared by Gary Edwards on 07 Mar 08 - Cached
  • Lebech said Denmark considers OOXML an open standard, regardless whether it is approved by the ISO. "It would be impossible for us to use only ISO standards if we want to fulfill the goal of creating interoperability in the government sector," he said. The Danish Parliament also mandated that public agencies consider the cost of using open formats. One of the main reasons OOXML was included is because Denmark is heavily dependent on document management systems that are integrated with Microsoft's Office products, Lebech said. Denmark also found that requiring agencies to only use ODF would have been too expensive, mostly because of the cost of converting documents into ODF, Lebech said. "We wouldn't have been able to only support ODF," Lebech said. "It wouldn't have been cost neutral."
Gary Edwards

Office generations 1.0 - 4.0| Rough Type: Nicholas Carr's Blog: - 0 views

www.roughtype.com/...office_generati.php

carr office office20 web

shared by Gary Edwards on 18 Dec 07 - Cached
  • The key is to extend both functionality and interoperability without taking away any of the capabilities that users currently rely on or expect. Reducing interoperability or functionality is a non-starter, for the end user as well as the IT departments that want to avoid annoying the end user. You screw with PowerPoint at your own risk.
    • Gary Edwards
      Gary Edwards on 18 Dec 07
       
      Exactly! This is also the reason why ODF failed in Massachusetts! Reducing the interoperability or functionality of of any workgroup related business process is unacceptable. Which is why IBM's rip out and replace MSOffice approach as the means of transitioning to ODF is doomed. The Office 2.0 (er 3.0) crowd is at a similar disadvantage. They offer web based productivity services that leverage the incredible value of web collaboration. The problem is that these collaboration services are not interoperable with MSOffice. This disconnection greatly reduces and totally neutralizes the collaboration value promise. Microsoft of course will be able to deliver that same web based collaborative comp[uting value in an integrated package. They and they alone are able to integrate web collaboration services into existing MSOffice workgroups. In many ways this should be an anti trust issue. If governments allow Microsoft to control the interop channels into MSOffice, then Microsoft web collaboration systems will be the only choice for 550 million MSOffice workgroup users. The interop layer is today an impossible barrier for Office 2.0, Web 2.0, SaaS and SOA competitors. This is the reasoning behind our da Vinci CDF+ plug-in for MSOffice. Rather than continue banging the wall of IBM's transition to ODF through government legislated rip out and replace mandates, we think the way forward is to exploit the MSOffice plug-in architecture, using it to neutralize and re purpose existing MSOffice workgroups. The key is getting MSOffice documents into a web ready format that is useful to non Microsoft web platform (cloud) alternatives. This requires a non disruptive transition. The workgroups will not tolerate any loss of interop or functionality. We believe this can be done using CDF+ (XHTML 2.0 + CSS). Think of it as cutting off the transition of existing workgroup business p
  • Microsoft sees this coming, and one of its biggest challenges in the years ahead will be figuring out how to replace the revenues and profits that get sucked out of the Office market.
    • Gary Edwards
      Gary Edwards on 18 Dec 07
       
      Bingo!
  • The real problem that I see is the reduced functionality and integration. I don’t think there can be a Revolution until someone builds an entire suite of Revolutionary office products on the web. Office has had almost (or more than, don't quote me) 15 years of experience to build a tight cohesive relationship between it's products.
    • Gary Edwards
      Gary Edwards on 18 Dec 07
       
      Rather than replace MSOffice, why not move the desktop bound business processes to the web? Re write them to take advantage of web collaboration, universal connectivity, and universal interop.
      Once the business processes are up in the cloud, you can actually start introducing desktop alternatives to MSOffice. The trick is to write these alternative business processes to something other than .NET 3.0, MS-OOXML, and the Exchange/SharePoint Hub.
  • ...1 more annotation...
  • left standing in a few years will be limited to those who succeeded in getting their products adopted and imbedded into the customers 'workflow' (for lack of a better term) and who make money from it. A silo'ed PPA is not embedded in a company's workflow (this describes 95% of the Office 2.0 companies) thus their failure is predetermined. A Free PPA is not making money thus their failure is predetermined as well. For those companies who adapt to a traditional service and support model and make it through the flurry.....would they really qualify as Office 4.0?
    • Gary Edwards
      Gary Edwards on 18 Dec 07
       
      Spot on! Excellent comments that go right to the heart of the matter. The Office 2.0 crowd is creating a new market category that Microsoft will easily be able to seize and exploit when the time is right. Like when it becomes profitable :)
  • Gary Edwards on 18 Dec 07
     
    In this 2006 article Nick Carr lays out the history of office productivity applications, arguing the Office 2.0 is really Office 3.0 - the generation where desktop productivity office suites mesh with the Web. This article is linked to The Office question, December 18, 2007
‹ Previous 21 - 40 of 55 Next ›
Showing 20▼ items per page