Skip to main content

Home/ Document Wars/ Group items tagged office-formats

Rss Feed Group items tagged

Gary Edwards

Google Makes it Easier to Dump Microsoft Office #io14 - 0 views

  •  
    "At I/O, Google always seems to find a way to squeeze the fun from Microsoft's master plan to rule the business world. This year, the 'something' comes in the ability to edit Microsoft Office documents in Google Docs. At face value, it doesn't seem too serious. But when you stand back and look at it, it takes on far more significance than first impressions convey. Who Needs Office? Equally important is the fact that Google Docs enable users to open Word, Excel and PowerPoint files, make changes and then save them onto the Google cloud in their native formats. By enabling users to edit Office documents through the cloud-based platform, it removes one of the biggest obstacles to Google Docs adoption. It also puts Google right up there with Microsoft Office as an option for enterprises looking for a business productivity suite. OK, we know. Microsoft Office has a lot more punch than Google Docs or even Google Apps, offering all kinds of functionality that Google still hasn't introduced. But Google Apps is still cheaper than Office 365 - and in light of this week's Outlook.com outage, it is probably looking a lot more attractive, especially to those who couldn't access their emails. It is also worth remembering that, as we saw in April, a lot of business users are using only limited functions in Office and could quite happily dump it, take up Google Docs and still work away without any problems. In fact, the research by SoftWatch showed the average employee spends only 48 minutes per day in MS Office programs, and most of that time is spent on Outlook. Other Office application use usually occurs for viewing and light editing purposes, with only a tiny portion of the workforce identified as heavy users. The new editing functionality Google is offering is also available for mobile devices along with offline support that means that users can work away on their documents even when they are out of mobile reach and have the changes uploaded once they
Gary Edwards

AlphaDog Barks Loudly: Why Can't You Guys Just Get Along and Solve MY MSOffice Problem!... - 0 views

  • First, let me say that I am a CIO in a small (20 employees but growing fast) financial services company. I am well aware of how locked-in I am getting with our MS-only shop. I am trying to see my way out of it, but this "ODF vs ODFF" is leaving me very confused and no one is working to clear the fog. I beg for all parties to really work towards some sort of defined understanding. I don't need cooperation. But, what I don't have is well-defined positions from all parties. As it is, I feel safer staying the course with MS right now, honestly. It's what I know vs the mystery of this "open cloud" and all the bellicose infighting. How's that for "in the trenches" data? I posted a comment on Andy's blog, and I will post the same comment here for your group (minor edits): I will admit to being very, very confused by all of this ODF vs ODFF posturing. I will try to put my current thoughts in short form, but it will be a muddled mess. I warned you! From what I gather, the OpenDocument Foundation (ODFF) is attempting to create more of an interop format for working against a background MS server stack (Exchange/Sharepoint). You worry that MS is further cementing their business lock-in by moving more and more companies into dependency on not only the client-side software but also the MS business stack that has finally evolved into a serious competitive set. At that level, and in your view, the "atomic unit" is the whole document. The encoded content is not of immediate concern. ODF is concerned with the actual document content, which ODFF is prepared to ignore. The "atomic unit" is the bits and parts in the document. They want to break the proprietary encodings that MS has that lock people into MSOffice. The stack is not of any immediate concern. So, unless I misunderstand either camp, ODF is first attacking the client end of the stack, and ODFF is attacking the backbone server end of the stack. The former wants to break the MSOffice monopoly by allowing people to escape those proprietary encodings, and the latter wants to prevent the dependency on server software like Exchange and Sharepoint by allowing MS documents to travel to other destinations than MS "server" products. Is this correct? I have yet to see anyone summarize the differences in any non-partisan way, so I am at a loss and not enough information is forthcoming for me to see what's what. The usual diatribe by people closer to the action is to go into the history of ODF or ODFF, talk about old slights and lost fights, and somehow try to pull at emotional heartstrings so as to gain mindshare. Gary's set of comments on this blog have that flavor. This is childish on both sides. Furthermore, the word "orthogonal" comes to mind. I often see people too busy arguing their POV, and not listening to others, when there is no real argument to keep making. It's apple-and-oranges. ODF vs ODFF seems like they are caught in this trap. Everyone wants to win an argument that has no possible win because the participants are not arguing about the same thing. Tell me: Why can't the two parties get along? I can see a "cooperative" that attacks the entire stack. Am I the only one seeing this? Am I wrong? If yes, what's the fundamental difference that prevents cooperation?
  •  
    AlphaDog When asked about the source of his incredible success, the hockey great Wayne Gretzky replied, "I skate to where the puck is going to be, not where it has been." You and i need to do the same. Let me state our position as this: The desktop office suite is where the puck has been. The Exchange/SharePoint Hub is where it's going to be. The E/S Hub is the core of an emerging Microsoft specific web platform which we've also called, the MS Stack. In this stack, MSOffice is relegated to the task of a rich client end user interface into the E/S Hub of business processes and collaborative computing connections. The rest of the MS Stack swirls like a galaxy of services around the E/S Hub. Key to Microsoft's web platform is the gradual movement of MSOffice bound business processes to the E/S Hub where they connect to the rest of the MS Stack. So what now you might ask? Some things to consider before we get down to brass tacks: ... There is a way to break the monopolists MSOffice desktop grip, but it's not a rip out and replace the desktop model. It's a beat them at the E/S Hub model that then opens up the desktop space. And opens it up totally. (this is a 3-5 year challenge though since it's a movement of currently bound business processes). ... It's all about the business processes. Focusing entirely on the file formats is to miss the big picture. ... The da Vinci group's position is this; we believe we can neutralize and re purpose MSOffice by converting in proce
Gary Edwards

Dump the file server: Why we moved to the SharePoint Online cloud [review] - 0 views

  • For this article, I wanted to focus on an important aspect of our move to Office 365, and that was our adoption of SharePoint Online as our sole document file server. I know, how passé for me to call it a file server as it represents everything that fixes what plagues traditional file servers and NASes. Let's face it: file servers have been a necessary evil, not a nicety that have enabled collaboration and seamless access to data. They offer superior security and storage space, but this comes at the price of external access and coauthoring functionality. Corporate IT departments have had a band-aid known as VPN for some time now, but it falls short of being the panacea vendors like Cisco make it out to be. I know this well -- I support these kinds of VPNs day to day. Their licensing is convoluted, they're drowning in client application bug hell, and most of all, bound by the performance bottlenecks on either the client or server end.
  • I previously wrote about how my company used to juggle two distinct file storage systems. We had Google Drive as our web-based cloud document platform, buts its penetration didn't go much further than its Google Docs functionality. That's because Google has a love-hate relationship with any Office file that's not a Google Doc. Sure, you can upload it and store it on the service, but the bells and whistles end there. Want to edit it with others? It MUST be converted to Google's format. And so we had to keep a crutch in place for everything else that had to stay in traditional Office formats, either due to customer requirements, complex formatting, or other reasons. That other device for us was a simple QNAP NAS box with 1.5TB of space.
  • I previously wrote about how my company used to juggle two distinct file storage systems. We had Google Drive as our web-based cloud document platform, buts its penetration didn't go much further than its Google Docs functionality. That's because Google has a love-hate relationship with any Office file that's not a Google Doc. Sure, you can upload it and store it on the service, but the bells and whistles end there. Want to edit it with others? It MUST be converted to Google's format.
  • ...9 more annotations...
  • And so we had to keep a crutch in place for everything else that had to stay in traditional Office formats, either due to customer requirements, complex formatting, or other reasons. That other device for us was a simple QNAP NAS box with 1.5TB of space.
  • We liked Google Drive's real time collaboration functionality, but the way it treated non-Docs files was pretty pitiful.
  • Dropbox for Business provides the best headroom for growth, but it's starting monthly price is too much to swallow.
  • And Box and Egnyte don't bring much more to the table besides bona fide cloud storage and sync;
  • SharePoint Online offers a rich ecosystem that we can grow on.
  • For the purpose of running our day to day business needs, SharePoint Online has taken over for both Google Drive and our former NAS alike. We don't have to convert items to and from Google Docs anymore just to collaborate. We have as good, or better, permissions in SharePoint compared to Google Drive. And the search power in SharePoint is disgustingly accurate, providing the accuracy and file previews that we were used to on Google Drive.
  • SharePoint Online is first and foremost a cloud solution that has additional tie-ins with Office Online products, OneDrive, etc that may or may not exist in the on-premise version of the product.
  • It's a cloud file server (the focus of this piece). It's a content search hub. It can run public websites and internal intranets. It can help handle complex document workflows. You can even run Access databases on it.
  • I can finally work as I wish, in-browser or in Office 2013 -- or both at once. My entire company "file server" is synced via OneDrive for Business to my Thinkpad, and likewise, I can edit any files in a browser via Office Online apps. It's a nirvana that Google Drive almost afforded us, if it weren't for Google's distaste of traditional Office files. It's good to know you can have your cake and eat it too.
  •  
    Yesterday Google announced dramatic price reductions for their Cloud Computing platform. This announcement was followed immediately by a similar announcement from Amazon. But what about Microsoft? The truth is that Microsoft doesn't need to reduce prices, and they are forcing both Google and Amazon reductions. My guess is that there are more reductions to come too. The answer is in this review of SharePoint OnLine and Office 365, where the author points out the fact that Google Drive / Apps totally mangles an MSOffice document. Once Google converts the documents, they are useless. "I previously wrote about how my company used to juggle two distinct file storage systems. We had Google Drive as our web-based cloud document platform, buts its penetration didn't go much further than its Google Docs functionality. That's because Google has a love-hate relationship with any Office file that's not a Google Doc. Sure, you can upload it and store it on the service, but the bells and whistles end there. Want to edit it with others? It MUST be converted to Google's format. And so we had to keep a crutch in place for everything else that had to stay in traditional Office formats, either due to customer requirements, complex formatting, or other reasons. That other device for us was a simple QNAP NAS box with 1.5TB of space." In 2006-2007, when we were in the middle of the great ODF vs OOXML document wars, I had a conversation with Google's Open Source - Opoen Standards guru, Chris DiBona. It was during the Massachusetts crisis, and we were trying to garner Google Corporate support for ODF. Chris listened to my pitch and summarized his position that conversion methods were very advanced, and going forward, file formats really didn't matter. He famously said, "Let a thousand formats bloom". I wonder if he still thinks that?
Gary Edwards

Groklaw - Digging for Truth : The problem with XML document formats - 0 views

  • The problem with that, as I understand it, is that the transitional spec is pretty much unimplementable by anybody except MS
    • Jesper Lund Stocholm
       
      Well, herein lies the problem, dude ... you don't understand it.
  •  
    Wow! The ODF peasants with pitchforks are have taken to the streets, and ISO document expert Alex Brown is taking them on. The volumes of traffic generated by any discussion of the ISO XML document wars continues to amaze. It's very one sided though. The basic problem seems to be that ISO has accepted two XML document format standards, OOXML and ODF, with OOXML being held to a higher set of expectations than ODF. Alex would do well if he could step back from the OOXML - ODF war, and move the discussion to something like the theoretical IDABC ODEF: the European "Open Document Exchange Formats" design. With ODEF as single set of XML format requirements against which both OOXML and ODF can be measured and compared, Alex might be able to neutralize the heated emotions of angry Open Source - Open Standards - Open Web supporters, who mistakenly think ODF measures up to ODEF expectations and requirements. Trying to compare ODF to OOXML isn't getting us anywhere. At some point, we have to ask ourselves what is it that we want from a standardized XML document format. Having participated in both the Massachusetts pilot study and the California pilot discussions, i have to say that the public expectations were that XML formats would have a basic set of characteristics: open markup; structured separation of content, presentation and logic; high level interoperability (exchange), and Web ready. These are basic "must have" expectations. XML formats were expected to be "better" than 1998 HTML-CSS. But when we apply the basic set of expectations, todays HTML+ (webkit HTML5, CSS4, SVG/Canvas, JS, JS Libs) turns out to be a far better format. Where the XML formats really fall off the wagon are the interoperability and Web ready expectations. For the life of me i don't see how anyone can compare ODF or OOXML interoperability with that of HTML+. And of course, HTML+ is the native language/for
  •  
    Jesper Lund Stocholm was kind enough to point out that, once again, GrokLaw is stoking the fires of the XML document wars. This time PJ takes on Alex Brown, of the ISO SC34 document standards group convenor. And Alex responds ... and responds ... and responds. of course, the attacks keep coming! I left Jesper a rather lengthy comment at: http://tinyurl.com/document-wars
Gary Edwards

Between a rock and a hard place: ODF & CIO's - Where's the Love? - 0 views

  • So I'm disappointed. And not just on behalf of open documents, but on behalf of the CIOs of this country, who are now caught between a rock and a hard place, without a paddle to defend themselves with if they won't to do anything new, innovative and necessary, if a major vendor's ox might be gored in consequence. After the impressive lobbying assault mounted over the past six months against open document format legislation, I expect you won't be hearing of many state IT departments taking the baton back from their legislators.    And who can blame them? If they tried, it wouldn't be likely to be anything as harmless as an open document format that would bite them in the butt.
  •  
    Andy Updegrove weighs in on the wave of ODF legislative failures first decribed by Eric Lai and Gregg Keizer compiled the grim data in a story they posted at ComputerWorld last week titled  Microsoft trounces pro-ODF forces in state battles over open document formats.


    Andy believes that it is the failure of state legislators to do their job that accounts for these failures.  He provides three reasons for this being a a failure of legislative duty.  The most interesting of which is claim that legislators should be protecting CIO's from the ravages of aggressve vendors. 


    The sad truth is that state CIO's are not going to put their careers on the line for a file format after what happened in Massachusetts.


    Andy puts it this way, "
      

    And second, in a situation like this, it is a cop out for legislatures to claim that they should defer to their IT departments to make decisions on open formats.  You don't have to have that good a memory to recall why these bills were introduced in the first place: not because state IT departments aren't a good place to make such decisions, but because successive State CIOs in Massachusetts had been so roughly handled in trying to make these very decisions that no state CIO in his or her right mind was likely to volunteer to be the next sacrificial victim.
    As both Peter Quinn and Louis Gutierrez both found out, trying to make responsible standards-related decisions whe
Gary Edwards

LOL :: Microsoft's Jean Paoli on the XML document debate - 0 views

  • What’s distinctive about the goals of OOXML? Primarily, to have full fidelity with pre-existing binary documents created in Microsoft Office. “What people want is to make sure that their billions of important documents can be saved in a format where they don’t lose any information. As a design goal, we said that those formats have to represent all the information that enables high-fidelity migration from the binary formats”, says Paoli. He mentions work with institutions including the British Library and the US Library of Congress, concerned to preserve the information in their electronic archive. I asked Paoli if such users could get equally good fidelity by converting their documents to ODF. “Absolutely not,” he says. “I am very clear on that. Those two formats are done for different reasons.” What can go wrong? Paoli gives as an example the myriad ways borders can be drawn round tables in Microsoft Office and all its legacy versions. “There are 100 ways to draw the lines around a table,” he says. “The Open XML format has them all, but ODF which has not been designed for backward compatibility, does not have them. It’s really the tip of the iceberg. So if someone translates a binary document with a table to ODF, you will lose the framing details. That is just a very small example.”
  • “Open Document Format and Office Open XML have very different goals”, says Paoli, responding to the claim that the world needs only one standard XML format for office documents. “Both of them are formats for documents … both are good.”
    • Gary Edwards
       
      The door should have been slammed shut on OOXML near five years ago when, on December 14th, 2006, at the very first OASIS ODF TC meeting, Stellent's Phil Boutros proposed that the charter include, "compatibility with existing file formats and interoperability with existing applications" as a priority objective.
  • I put it to Paoli that OOXML is hard to implement because of all its legacy support, some of which is currently not well documented. “I don’t believe that at all. It’s actually the opposite,” he says. He make the point that third parties like Corel, which have previously implemented support for binary formats like .doc and .xls, should find it easy to transition to OOXML. “We believe Open XML adoption by vendors like Corel will be very easy because they have already been doing 90% of the work, doing the binary formats. The features are already there.”
    • Gary Edwards
       
      WordPerfect does an excellent import of MSWord .doc documents. But there is no conversion! It's a read only rendering. Once you start editing the document in WP, all kinds of funny things happen, and the perfect fidelity melts away like the wicked witch of west in a bucket full of water.
  • ...5 more annotations...
  • Another benefit Paoli claims for OOXML is performance. “A lot of things are designed differently because we believe it will work faster. The spreadsheet format has been designed for very big spreadsheets because we know our users, especially in the finance industry, use very large spreadsheets.
    • Gary Edwards
       
      Wrong. The da Vinci plug-in prototype we demonstrated to Massachusetts on June 19th, 2006 proved that there is little or no difference in spreadsheet performance between a OOXML file, and an ODF file.

      In fact, ODF version of the extremely large test file beat the OOXML load by 12 seconds.

      Where the performance difference comes in is at the application level. MS Excel can load a OOXML version of a large spreadsheet faster than OpenOffice can load an ODF version of that same spreadsheet.

      If you eliminate the application differential, and load the OOXML file and the ODF version of that same spreadsheet into a plug-in enabled Excel, the performance differences are negligible.

      The reason for this is that the OOXML plug-in for Excel has a conversion overhead identical to the da Vinci plug-in for Excel. It has nothing to do with the file format, and everythign to do with the application.

      ~ge~
  • Paoli points to the conversion errors as evidence of how poorly ODF can represent legacy Office documents. My hunch is that this has more to do with the poor quality of the converter.
    • Gary Edwards
       
      Note that these OASIS ODF TC November 20th iX "interoperability enhancement" suggestions were submitted by Novell as part of their effort to perfect a OOXML plug-in for OpenOffice!!!!

      "Lists" were th first of these iX items to be submitted as formal proposal. And Sun fought that list proposal viciously for the next four months. The donnybrook resulted i a total breakdown of the ODF consensus process. But, it ensured that never again would anyone be stupid enough to challenge Sun's authority and control of the OASIS ODF TC.

      Sun made it clear that they would viciously oppose any other efforts to establish interoperability with existing Microsoft documents, applications, processes effort.

      Point taken.

      ~ge~
  • the idea that Sun is preparing a reference implementation of OOXML is laughable.
    • Gary Edwards
       
      Sorry Tim. It's true. Sun and Novell are working together to develop native OOXML file support in OpenOffice. You can find this clearly stated in the Gullfoss Planet OpenOffice blogs.

      The funny thing is that Sun will have to implement and support the November 20th iX enhancements submitted by Novell!! (Or, the interoperability frameworks also submitted by Novell in February of 2007). There is simply no other way for OpenOffice to implement OOXML with the needed fidelity.

      ~ge~
  • One of new scenarios enabled by the “custom xml parts” (again, if you read their blogs, you must have heard of this stuff) is the ability to bind xml sources and a control+layout so that it enables the equivalent of data queries (we’ve had in Excel for many years already), just with a source which is part of the package, contrary to the typical external data source connection. Well this stuff, besides the declaration (which includes, big surprise, GUIDs and stuff like that) requires the actual Office 2007 run-time to work. So whenever MS says this stuff is interoperable, they cannot mean you can take this stuff away in another application. Because you can’t. This binding is more or less the same than the embedding of VBA macros. It’s all application-specific, and only Microsoft’s own suite knows how to instantiate this stuff.
    • Gary Edwards
       
      Stephan whacks this one out of the park! Smart Documents will replace VBa scripts, macros and OLE functionality going forward. It's also the data binding - workflow and metadata model of the future. And it's all proprietary!

      It's the combination of OOXML plus the MSOffice- Vista Stack specific Smart Documents that will lock end users into the Vista Stack for years to come.

      Watch out Google!

      ~ge~
  • Has Microsoft published the .doc spec publicly? Then why should ODF worry about the past? It’s not ODF’s concern to worry about Microsoft’s past formats. (Understand that the .doc format alone changed six times in the last eight versions of Office!) That’s Microsoft’s legacy problem, not ODF’s.
    • Gary Edwards
       
      There really is no need to access the secret binary blueprints. The ACME 376 plug-in demonstration proves this conclusively. The only thing the ACME 376 demo lacks is that we didn't throw the switch on the magic key to release all VBa scripts, macros and OLE bindings to ACME. But that can be done if someone is serious about converting the whole shebang of documents, applications and processes.

      The real problem is that although ACME 376 proves we can hit the high fidelity required, it is impossible to effectively capture that fidelity in ODF without the iX interoperability enhancements. The world expects ODF interoperability. But as long as Sun opposes iX, we can't pipe from ACME 376 to ODF.

      ~ge~
  •  
    Tim Anderson interviews Microsoft's Jean Paoli about MOOXML and ODF.    Jean Paoli of course has the predictable set of answers.  But Tim anderson provides us with some interesting insights and comments of his own.  There is also a gem of a comment from Stephane Rodriquez, the reknown spreadsheet expert.

    The bottom line for Microsoft has not changed.  MOOXML exists because of the need for an XML file format compatible with the legacy of existing MSOffic ebinary documents.  He claims that ODF is not compatible, and offers the "page borders" issue as an example.

    Page borders?  What's that got to do with the ODF file format?   These are application specific, application bound proprietary graphics that can not be ported to any other application - like OpenOffice.  The reason has nothign whatsoever to do with ODF and everything to do with the fact that the page border library is bound to MSOffice and not available to other applications like OpenOffice. 

    So here is an application specific feature tha tJean Paoli claims can not be expressed in ODF, but can in MOOXML.  But when are running the da Vinci ODF plugin in MSWord, there is no problem whatsoever in capturing the page borders in ODF!!!!!!!!!!!!!!!!!!!!!!!!!!!  No problem!!!!!!!!!!

    The problem is opening up that same da Vinci MSWord document in OpenOffice.  That's where the page borders are dropped.  The issue is based entirely on the fact that OpenOffice is unable to render these MSWord specific graphics bound to an MSOffice only library.

    If however we take that same page border loaded da Vinci MSWord document, and send it half way across the world to another MSWord desktop running da Vinci, the da Vinci plugin easily loads the ODF document into MSWord where it is perfectly rendered, page borders and all!!!!!!!!

    Now i will admit that this is one very difficult issue to understand.  If not f
  •  
    Great interview. Tim can obviously run circles around poor Jean Paoli.
Gary Edwards

ODF - the state of play - The future of ODF under OASIS, now that the... - 1 views

  •  
    "ODF - open document format - is an open, XML-based rich document format that has been adopted as the standard for exchanging information in documents (spreadsheets, charts, presentations and word processing documents), by many governments and other organisations (see, for example, here), including the UK Government. This is despite strong opposition by Microsoft; but I have seen Microsoft's proposed "open XML" standard and, frankly, it is huge and horrid (in the word of standards, these go together). If I remember correctly, the early draft I saw even incorporated recognition of early Excel leap-year bugs into the standard. ODF is now a pukka ISO standard, maintained by OASIS, under the proud banner: "The future is interoperability". My personal thoughts, below, are prompted by an ODF session at ApacheCon Core titled "Beyond OpenOffice: The State of the ODF Ecosystem" held by Louis Suárez-Potts (community strategist for Age of Peers, his own consultancy, and the Community Manager for OpenOffice.org, from 2000 to 2011), and attended by very few delegates - perhaps a sign of current level of interest in ODF within the Apache community. Nevertheless, and I am talking about the ODF standard here, not Apache Open Office (which is currently my office software of choice) or its Libre Office fork (which seems to be where the excitement, such as it is, is, for now), the standards battle, or one battle, has been won; we have a useful Open Document Format, standardised by a recognised and mature standards organisation, and even Microsoft Office supports it. That's good. So what could be the problem? Well, I don't care whether I use ODF from Open Office, Libre Office or even Office 365, I just want to be sure that everyone else can read my ODF documents (with a .odt, .ods or .odp extension, for text, presentation or spreadsheet, respectively), with whatever software they like; and that they'll either see exactly the functionality and formatting I see; or a well defined (an
Gary Edwards

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

  • 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
       
      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
       
      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
       
      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
       
      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 :)
  •  
    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
  •  
    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
Gary Edwards

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

  • This seems to me to be a turning point for the creation of global standards. Microsoft was invited to be part of the original ODF Technical Committee in OASIS, and chose to stand aside. That committee tried to do its best to make the standard work well with Office, but was naturally limited in that endeavor by Microsoft's unwillingness to cooperate. This, of course, made it easier for Microsoft to later claim a need for OOXML to be adopted as a standard, in order to "better serve its customers." The refusal by an incumbent to participate in an open standards process is certainly its right, but it is hardly conduct that should be rewarded by a global standards body charged with watching out for the best interests of all.
  •  
    Andy UpDegrove takes on the issue of Microsoft submitting their proprietary "XML alternative to PDF" proposal to Ecma for consideration as an international standard.  MS XML-PDF will compliment ECMA 376 (OOXML - OfficeOpenXML) which is scheduled for ISO vote in September of 2007.  Just a bit over 60 days from today.

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

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

    If that sounds familiar, it should, because it echoes the absolute directive of the original OOXML technical committee charter, wh
Gary Edwards

Microsoft attacks UK government decision to adopt ODF for document formats - 0 views

  • the panel reached consensus that one standard is important to ensure interoperability and to allow users to collaborate effectively on the same document,” said the minutes
  • A subsequent meeting of the same panel also considered a detailed comparison of ODF and OOXML, citing concerns raised by one member. “We need to make sure there is sound reasoning to back up the decision as this may incur significant costs to some government departments. The comparison may be slightly skewed by concentrating solely on implementation of strict OOXML, which is an emerging standard similar to ODF 1.3, whilst considering implementations of all ODF versions. It ignores transitional OOXML which does have very wide support, arguably wider than ODF,” said the meeting minutes.
  • “LH described the issues identified in the [comparison] document and added that there has since been some confusion about support for OOXML strict in LibreOffice.  It appears that LibreOffice supports the standardised transitional OOXML, as well as a different Microsoft version of transitional OOXML,” the minutes stated.
  • ...3 more annotations...
  • Despite its obvious disappointment at the government’s decision, Microsoft was also keen to point out that its software does fully support ODF.
  • “The good news for Office users is that Office 365 and Office 2013 both have excellent support for the ODF file format, so their current and future investments in Office are safe.  In fact, Office 365 remains the only business productivity suite on the UK government’s G-Cloud that is accredited to the government’s own security classification of 'Official' and which also supports ODF,” said the Microsoft spokesman.
  • Government Digital Service director Mike Bracken
  •  
    "Microsoft has attacked the UK government's decision to adopt ODF as its standard document format, saying it is "unclear" how UK citizens will benefit. The Cabinet Office announced its new policy yesterday, whereby Open Document Format (ODF) is immediately established as the standard for sharing documents across the public sector, with PDF and HTML also acceptable when viewing documents. SERGIGN - FOTOLIA The decision was a rejection of Microsoft's preference for Open XML (OOXML), the standard used by its Word software, which remains the dominant wordprocessor in government. "Microsoft notes the government's decision to restrict its support of the file formats it uses for sharing and collaboration to just ODF and HTML," said a spokesman for the software giant in a statement to Computer Weekly. "Microsoft believes it is unproven and unclear how UK citizens will benefit from the government's decision. We actively support a broad range of open standards, which is why, like Adobe has with the PDF file format, we now collaborate with many contributors to maintain the Open XML file format through independent and international standards bodies," it added"
Gary Edwards

We Can No Longer Unbundle Microsoft Office - 0 views

  • In 2007, productivity reached the cloud when the EU forced Microsoft to open the file formats to OpenXML and add an x at the end of our familiar file extensions .pptx, .xlsx and .docx. Google Docs also quickly floated cloud versions of each Office document format. However, in the same year, Apple launched iPhone without a view to file storage on the device. Since then a lot of startup innovation came from Dropbox and Box unbundling file storage from the OS, but software that enables the creation and editing of files on touchscreen devices has been less of a concern.
    • Gary Edwards
       
      2007 was also the year that Apple released the first iPhone. ISO standardised PDF with a unique very valuable attribute; "tags". Tagged PDF raced into the mobility breach enabling all kinds of data binding and digital signature advances critical to mobile document centric workflows. In 2008 we saw a global financial collapse that put more pressure than ever on productivity. To survive, companies had to do more with less. Less people, less resources and less money. Cloud computing and mobility rose to the occasion, but the timing of the cloud tsunami connects the incredible synchronicity of XML compound document formats (business documents), Tagged PDF, the iPhone, and the financial collapse of 2008. The rise of sync-share-store services like DropBox is a natural replacement of the local, workgroup bound, client/server hard drive problem. Most importantly though, the iPhone is the first device to integrate and combine communications with computation. The data had to move to the Cloud before it could become useful to mobile apps combining for the first time, communications, content and computation is hand held devices. Anyone who ever worked in the Microsoft client/server productivity ecosystem will tell you that the desktop PC was totally lacking in "communications"; let alone the kind of integrated communications that the iPhone offers. It is the integration of communications, content and collaborative computation that will make the productivity of Cloud Computing something extraordinary.
  • Three years ago, CloudOn CEO Milind Gadekar started using OpenXML formats to bring Microsoft Office to iPad. Since then, the company opened its interface to file authoring tools from Office and Google Drive, and storage providers like Dropbox, Box and Hightail, Google Drive, and OneDrive, and will soon be hard at work adding Apple’s CloudDrive. CloudOn feels that if it focuses on providing the best compatibility and exportability across devices, then they can be the place where users can “preserve, render and manipulate” documents on mobile. Once CloudOn can maintain its goal of giving consumers a familiar look and feel and lossless publishing for all the most popular document creation and storage providers, they plan to optimize for touchscreens. CloudOn sees only single-digit-minute session times in files, so their next step is to enable gestures to edit charts and annotate text with your fingers to help make better use of that time.
  • Feature-bundled workflows to get things done on the device you’re looking at are necessities, not nice pairings like chocolate and peanut butter.
  • ...1 more annotation...
  • Pellucid Analytics takes a different strategy to rebuilding PowerPoint. Instead of looking at PowerPoint as a design tool, Pellucid fixes the design and enables archive search for thousands of financial accounting slide templates that an analyst would need to fill a pitch book such as ROE, EBITDA and other fun acronyms. Since the formatting is already set, analysts can just enter company names and based on the data sources that the bank they work for has licensed, Pellucid can fill in any of that data automatically and keep it up to date. However, the concept of live data in presentations is a shock to most bankers, so Adrian Crockett of Pellucid admits that it’s one of the first things he has to explain to new users. Of course, Pellucid offers the ability to snapshot data for use in later presentations. But Adrian stressed that in addition to Pellucid’s approach to removing grunt work for analysts, it is giving senior bankers access to live data right in the presentation that would normally require VPN access, logins, app switching and all other sorts of headaches to be able to access, especially on tablets.
Gary Edwards

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

  • 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
       
      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.
  •  
    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

GROKLAW - Flock - 0 views

  • As you know the so-called OpenDocument Foundation has been telling the world that CDF is a better approach than ODF. Updegrove met with W3C's Chris Lilley, the "go-to guy guy at W3C to learn what W3C's CDF standard is all about." Lilley says CDF can't replace ODF. It's not suitable for use as an office format, and he's mystified by the pronouncements of the Foundation. Here's what Updegrove reports: To find out the facts, I interviewed Chris Lilley, the W3C lead for the CDF project, and his answer couldn't have been more clear: "The one thing I'd really want your readers to know is that CDF was not created to be, and isn't suitable for use as, an office format." In fact, it isn't even an format at all - although it has been matched for export purposes with another W3C specification, called WICD - but WICD is a non-editable format intended for viewing only. Moreover, no one from the Foundation has joined W3C, nor explained to W3C what the Foundation's founders have in mind. It is highly unfortunate that the founders of a tax exempt organization that solicited donations, "To support the community of volunteers in promoting, improving and providing user assistance for ODF and software designed to operate on data in this format," should publicly announce that it believes that ODF will fail. By endorsing a standard that has no rational relationship to office formats at all, they can only serve to confuse the marketplace and undermine the efforts of the global community they claimed to serve. So, there you have it, straight from the horse's mouth. CDF can't replace ODF, according to Lilley. It wasn't designed to be used as an office format. It's good for other things. So, was all this media push really about ODF? Or about damaging it with FUD and giving support to Microsoft's assertion that the world craves more than one office format standard so we can all struggle with interoperability complexity for the rest of our born days? And is it a coincidence it all happened on the eve of the next vote in February on Microsoft's competing MSOOXML? Was Microsoft behind this? Or did they just get lucky? Microsoft representatives, like Jason Matusow, certainly gave support to what the 3-man crew was saying, so much so that ZDNet's Mary Jo Foley wrote that, "the ODF camp might unravel before Microsoft’s rival Office Open XML (OOXML) comes up for final international standardization vote early next year." Dream on. ODF is doing fine. It's the OpenDocument Foundation that is shutting down. But here's my question: did the Microsoft reps not understand the tech, that CDF can't replace ODF? How trust-inspiring do you find that? Or did they think that *we'd* never figure it out? Whatever the story might be, unfortunately for Microsoft, people aren't as dumb as Microsoft needs them to be. FUD has a very limited shelf life in the Internet age. There is always somebody who knows better. And they'll tell the world.
  •  
    This is priceless!  The ODF Community is now attacking the W3C and CDF.  Watch what happens next inside IBM and Sun who are the primary supporters of CDF.  You see, the thing about a mob is that there comes a point when you can no longer control them.  We've reached 451 Fahrenheit.  somebody is goign regret ever having lit that match.
Gary Edwards

NYS Open Records Discussion Must Recognize Technical Requirements - 0 views

  •  
    While the workgroup failed to decide between "choice" (Microsoft's mantra) and "openness" (the ODF mantra), predictably punting this question to a new Electronic Records Committee, it did issue a number of interesting findings, the most important of which reads as follows: In the office suite format debate, there currently is no compelling solution for the State's openness needs. The State needs open standards and formats. Simultaneously, the State needs electronic records to be preserved in their original formats whenever possible. Many Request for Public Comments commenters, particularly in response to the e-discovery questions, stated preserving a record in the same format as it was created results in a more faithful record and diminishes the possibility of expensive e-discovery disputes. This is important to ensure future generations of New Yorkers can access the permanently valuable electronic records being created today. Moreover, State Archives emphasizes creating records in open formats makes it easier to preserve their essential characteristics and demonstrates they are authentic (i.e., they were created in the course of State government business and have not been altered without proper authorization). I imagine that the workgroup must have found some level of solace in arriving at the one conclusion that all the experts seem to agree on: that electronic documents should be published using the same format in which they are created. If this principle held true for state documents, it would reduce the job of the new Electronic Records Committee to deciding between three alternatives: (1) require all state agencies to create and publish their documents in OOXML, (2) require all state agencies to create and publish their documents in ODF, or (3) allow each agency to decide which of these formats, OOXML or ODF, they will use in creating and publishing their documents. Unfortunately, this central assumption is incorrect, and adopting it as a basi
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

Study Shows Office Alternatives Failing to Sway Microsoft Users -- Microsoft Certified ... - 0 views

  •  
    Interesting report from Forrester on Desktop Productivity.  It seems everyone is asking about alternatives to MSOffice, but coming away empty handed.  Sounds like everyone would like to drop MSOffice, but find the alternatives wanting.  IMHO, the Web based alternatives are long on collaboration but short on productivity.   Compound Documents, Reports and Forms are the fuel that powers legacy workgroup productivity environments.  Web Productivity platforms have a long way to go before they can provide effective, worker facing authoring systems capable of replacing binding and messaging internals such as OLE, ODBC, MAPI, ActiveX, COM and DCOM.   There also seems to be considerable confusion about the difference between Web based authoring alternatives to MSOffice, and Web based Productivity Platforms.  MSOffice is the authoring system for desktop/WorkGroup productivity environments.  But having this authoring system wouldn't mean much if not for the workgroup connectivity and exchange platform behind it that makes highly productive digital business processes and systems possible. Linked Data, messaging, collaboration, and connectivity API's and HTML+ (HTML5, CSS3, JSON, Canvas/SVG, JavaScript) are  showing up everywhere.  But they are not exclusive to Web based authoring systems.  Any desktop authoring system should be able to take advantage of the emerging productivity platform.   So what's the problem with OpenOffice, Symphony, Zoho and gDocs?  OOo and Symphony can't speak language of the Web; HTML+.  Browser based Zoho and gDocs lack the completeness of a Web productivity environment capable of hosting the business processes currently bound to the Windows WorkGroup productivity environment.  There is no indication that the experts at Forrester understand what should be obvious.   excerpt: According to a new Forrester Research report, IT orgs are still choosing Microsoft Office over its competitors.   Two factors appear to be stumbling bloc
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

PlexNex: Analyzing the Microsoft Office Open XML License - 0 views

  • There are many other warts in the Microsoft covenant not to sue. E.g., the covenant applies only to Ecma Office Open XML; it does not apply to any future version, including a version that might be approved by ISO or a variant that might be actually implemented by Microsoft in MS Office. So Microsoft makes no guarantee that it will not move the goal posts at any time.
  •  
    Whoa!  This has already happened.  In his blog titled, "The Formats of Excel 2007",  XML expert Rob Weir demonstrates for us that MSOffice 2007 Excel has a new file format.  Rob demonstrates that there are four file format choices in Excel; EOOXML, Legacy XLS binary, and two  new binary extensions of EOOXML: "Excel Macro-Enabled Workbook" - xlsxm, and "Excel Binary Workbook" - xlsb.

    The new binaries are proprietary extensions to EOOXML.  xlsb in particular looks to be something known as a XML Binary InfoSet..  XBiS is a compressed form of an XML file used in situations where bandwidth and device cpu constraints demand such an extreme.  We can't be sure about xlsb, but it looks like a duck, walks like a duck, quacks like a duck and thherefore....

    This must be some kind of record.  EOOXML isn't yet 30 days old and Micrsoft has eXtended it with a proprietary binary representation not available to the rest of the world.  And XBiS was designed so that implementations would be open and application and platform independent.  But that's not what we see with Microsoft's xlsb.

    What Marbux is pointing out here is that only Micrsoft has the legal rights to do this proprietary eXtension of EOOXML.  Beat the drums.  Sound the alarms.  Hide the women and children.  Nothing has changed.  The longboats are fancier, there are more of them. The swords of the pillagers remain just as sharp.  Their determination and drive just as strong.

    Some quick backgroud references:  Compression, XML</b
  • ...2 more comments...
  •  
    Whoa!  This has already happened.  In his blog titled, "The Formats of Excel 2007",  XML expert Rob Weir demonstrates for us that MSOffice 2007 Excel has a new file format.  Rob demonstrates that there are four file format choices in Excel; EOOXML, Legacy XLS binary, and two  new binary extensions of EOOXML: "Excel Macro-Enabled Workbook" - xlsxm, and "Excel Binary Workbook" - xlsb.

    The new binaries are proprietary extensions to EOOXML.  xlsb in particular looks to be something known as a XML Binary InfoSet..  XBiS is a compressed form of an XML file used in situations where bandwidth and device cpu constraints demand such an extreme.  We can't be sure about xlsb, but it looks like a duck, walks like a duck, quacks like a duck and thherefore....

    This must be some kind of record.  EOOXML isn't yet 30 days old and Micrsoft has eXtended it with a proprietary binary representation not available to the rest of the world.  And XBiS was designed so that implementations would be open and application and platform independent.  But that's not what we see with Microsoft's xlsb.

    What Marbux is pointing out here is that only Micrsoft has the legal rights to do this proprietary eXtension of EOOXML.  Beat the drums.  Sound the alarms.  Hide the women and children.  Nothing has changed.  The longboats are fancier, there are more of them. The swords of the pillagers remain just as sharp.  Their determination and drive just as strong.

    Some quick backgroud references:  Compression, XML</b
  •  
    There are many other warts in the Microsoft covenant not to sue. E.g., the covenant applies only toEcmaOffice Open XML; it does not apply to any future version, including a version that might be approved by ISO or a variant that might be actually imple
  •  
    There are many other warts in the Microsoft covenant not to sue. E.g., the covenant applies only toEcmaOffice Open XML; it does not apply to any future version, including a version that might be approved by ISO or a variant that might be actually imple
  •  
    There are many other warts in the Microsoft covenant not to sue. E.g., the covenant applies only toEcmaOffice Open XML; it does not apply to any future version, including a version that might be approved by ISO or a variant that might be actually imple
Gary Edwards

How Microsoft Ratted Itself Out Of Office | Michael Hickins | BNET - 0 views

  •  
    Another good article form Michael Hickins, this time linking the success of Google Wave to the success of Microsoft OOXML. Rob Weir jumps in to defend , well, i'm not sure. I did however respond. Excerpt: Developers hoping to hitch a ride on Google's Wave have discovered that Microsoft may have unwittingly helped them resolve the single greatest problem they needed to overcome in order to challenge the dominance of Office. When Microsoft set out to create Office 2007 using a brand new code base - Office Open XML (OOXML) - it needed to accomplish two goals: make it compatible with all previous versions of Office, and have it accepted as a standard file format for productivity tools so that governments could continue using it while complying with rules forcing them to use standards-based software. ..... Depending on your perspective, either Microsoft has sowed the seeds of its own undoing, or international standards bodies succeeded in forcing Microsoft to open itself up. Either way, Microsoft has given away the key to compatibility with Office documents, allowing all comers to overcome the one barrier that has heretofore prevented customers from dumping Microsoft's Office suite.
Gary Edwards

Slamming the door shut on MS OOXML - 0 views

  • 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.
  •  
    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.

1 - 20 of 145 Next › Last »
Showing 20 items per page