Group items tagged Google Docs - Document Wars

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

www.cmswire.com/...crosoft-office-io14-025692.php

wordsdk offic-365 Cloud-Productivity-Platform

shared by Gary Edwards on 20 Aug 14 - No Cached

Gary Edwards on 20 Aug 14

"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

<div class="cArrow"> </div><div class="cContentInner">"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</div>

...

Cancel

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

betanews.com/...sharepoint-online-cloud-review

ODF document-wars Cloud-Computing

shared by Gary Edwards on 27 Mar 14 - No Cached

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

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

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

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

Cancel
We liked Google Drive's real time collaboration functionality, but the way it treated non-Docs files was pretty pitiful.
...

Cancel
Dropbox for Business provides the best headroom for growth, but it's starting monthly price is too much to swallow.
...

Cancel
And Box and Egnyte don't bring much more to the table besides bona fide cloud storage and sync;
...

Cancel
SharePoint Online offers a rich ecosystem that we can grow on.
...

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

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

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

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

Cancel

Gary Edwards on 27 Mar 14

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?

<div class="cArrow"> </div><div class="cContentInner">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?</div>

...

Cancel

Google Brings Native MS Office Editing Features To Its iOS Productivity Apps - 0 views

techcrunch.com/...y-apps-launches-slides-for-ios

wordSDK Office-365 Cloud-Productivity-Platform

shared by Gary Edwards on 29 Aug 14 - No Cached

Google’s new Material Design user interface language and all the Microsoft Office conversion goodness the company acquired when it bought Quickoffice in 2012.
...

Cancel
Google is closing the loop on bringing support for natively editing Microsoft Office files to all of productivity apps today.
...

Cancel

Gary Edwards on 29 Aug 14

"Google is closing the loop on bringing support for natively editing Microsoft Office files to all of productivity apps today. The company's iOS apps for Docs and Sheets are getting a couple of minor new features and design updates today, but most importantly, these apps will now also be able to natively open, edit and save files from Microsoft's Office suite. After launching the original standalone apps for Google Docs and Sheets on iOS a few months ago, it was only a matter of time before Google would also free its PowerPoint competitor Slides from the Google Drive app. Today is that day. Google Slides is now available as a standalone app for the iPhone, iPad and iPod touch. 2014-08-25_1104Just like the Docs and Sheets apps and their counterparts on Android (the standalone Slides app launched there two months ago), the new Slides app will feature some aspects of Google's new Material Design user interface language and all the Microsoft Office conversion goodness the company acquired when it bought Quickoffice in 2012." ........................................................... Hey, Google is pulling the Cloud version of "bait and switch". The bait is calling a standalone application for iOS "native". The switch is that Microsoft is using the term "native" to describe the editing of MS Office native documents. Google is trying to market a native, written explicitly for iOS application, presenting it as "supporting native document editing and collaboration". Wow. They've got nothing!! This is just market spin. And the article's title suggests that they know exactly what they are doing with this egregious misrepresentation. There is no doubt in my mind that Microsoft has committed to the "Office 365 - native document" narrative. Its designed to totally obliterate Googe, Dropbox, Box, iCloud and anyone trying to offer Cloud based business solutions. They are going to crush Google, taking both Android and Booble Apps / GoogleDrive out of th

<div class="cArrow"> </div><div class="cContentInner">"Google is closing the loop on bringing support for natively editing Microsoft Office files to all of productivity apps today. The company's iOS apps for Docs and Sheets are getting a couple of minor new features and design updates today, but most importantly, these apps will now also be able to natively open, edit and save files from Microsoft's Office suite. After launching the original standalone apps for Google Docs and Sheets on iOS a few months ago, it was only a matter of time before Google would also free its PowerPoint competitor Slides from the Google Drive app. Today is that day. Google Slides is now available as a standalone app for the iPhone, iPad and iPod touch. 2014-08-25_1104Just like the Docs and Sheets apps and their counterparts on Android (the standalone Slides app launched there two months ago), the new Slides app will feature some aspects of Google's new Material Design user interface language and all the Microsoft Office conversion goodness the company acquired when it bought Quickoffice in 2012." ........................................................... Hey, Google is pulling the Cloud version of "bait and switch". The bait is calling a standalone application for iOS "native". The switch is that Microsoft is using the term "native" to describe the editing of MS Office native documents. Google is trying to market a native, written explicitly for iOS application, presenting it as "supporting native document editing and collaboration". Wow. They've got nothing!! This is just market spin. And the article's title suggests that they know exactly what they are doing with this egregious misrepresentation. There is no doubt in my mind that Microsoft has committed to the "Office 365 - native document" narrative. Its designed to totally obliterate Googe, Dropbox, Box, iCloud and anyone trying to offer Cloud based business solutions. They are going to crush Google, taking both Android and Booble Apps / GoogleDrive out of th</div>

...

Cancel

Official Google Blog: Pagination comes to Google Docs - 0 views

googleblog.blogspot.com/...tion-comes-to-google-docs.html

shared by Gary Edwards on 12 Apr 11 - No Cached

Gary Edwards on 12 Apr 11

Although you need Chrome for the new Google Docs pagination feature, the key here is that gDocs now supports the CSS3 pagination module! excerpt: Today, we're doing another first for web browsers by adding a classic word processing feature-pagination, the ability to see visual pages on your screen. We're also using pagination and some of Chrome's capabilities to improve how printing works in Google Docs. Native Printing: Pagination also changes what's possible with printing in modern browsers. We've worked closely with the Chrome team to implement a recent web standard, CSS3, so we can support a feature called native printing. Before, if you wanted to print your document we'd need to first convert it into a PDF, which you would then need to open and print yourself. With native printing, you can print directly from your browser and the printed document will always exactly match what you see on your screen.

<div class="cArrow"> </div><div class="cContentInner">Although you need Chrome for the new Google Docs pagination feature, the key here is that gDocs now supports the CSS3 pagination module! excerpt: Today, we're doing another first for web browsers by adding a classic word processing feature-pagination, the ability to see visual pages on your screen. We're also using pagination and some of Chrome's capabilities to improve how printing works in Google Docs. Native Printing: Pagination also changes what's possible with printing in modern browsers. We've worked closely with the Chrome team to implement a recent web standard, CSS3, so we can support a feature called native printing. Before, if you wanted to print your document we'd need to first convert it into a PDF, which you would then need to open and print yourself. With native printing, you can print directly from your browser and the printed document will always exactly match what you see on your screen.</div>

...

Cancel

Jive Buys Microsoft Office Collaboration Plugin OffiSync For Up To $30 Million - 0 views

techcrunch.com/...-offisync-for-up-to-30-million

msoffice wikiWORD jive-OfficeSync

shared by Gary Edwards on 23 May 11 - No Cached

Gary Edwards on 23 May 11

excerpt: OffiSync offers a a plugin for Microsoft Office that serves as a bridge between Office and Google Docs. When it first launched, the app's primary feature was to save Office documents to your Google account. It's since integrated Google Image Serach into Office, and added support for Google Sites. The application allows you to do Office-to-Office collaboration, and you can also have users editing the same document from Google Docs' online interface. Changes aren't synced as you type in each character, but rather each time you hit the 'save' button. Offisync is offered under a freemium model, but recently tweaked its pricing to offer more free features. Jive's CEO Tony Zingale says that this is a game changing acquisition for Jive, which combines computing with social collaboration to offer fully-featured social networks for businesses. Its suite of applications help businesses collaborate on a variety of tasks, including holding discussions, communication, sharing documents, blogging, running polls, and social networking features and more. "With OffiSync, Jive has the opportunity to become the most widely adopted Social Business platform for over 600 million Microsoft users, giving them the ability to bring social to the way they work.

<div class="cArrow"> </div><div class="cContentInner">excerpt: OffiSync offers a a plugin for Microsoft Office that serves as a bridge between Office and Google Docs. When it first launched, the app's primary feature was to save Office documents to your Google account. It's since integrated Google Image Serach into Office, and added support for Google Sites. The application allows you to do Office-to-Office collaboration, and you can also have users editing the same document from Google Docs' online interface. Changes aren't synced as you type in each character, but rather each time you hit the 'save' button. Offisync is offered under a freemium model, but recently tweaked its pricing to offer more free features. Jive's CEO Tony Zingale says that this is a game changing acquisition for Jive, which combines computing with social collaboration to offer fully-featured social networks for businesses. Its suite of applications help businesses collaborate on a variety of tasks, including holding discussions, communication, sharing documents, blogging, running polls, and social networking features and more. "With OffiSync, Jive has the opportunity to become the most widely adopted Social Business platform for over 600 million Microsoft users, giving them the ability to bring social to the way they work. </div>

...

Cancel

Microsoft Watch Finally Gets it - It's the Business Applications!- Obla De OBA Da - 0 views

www.microsoft-watch.com/...obla_de_oba_da.html

odef odf officeopenxml ooxml opendocument vista-stack

shared by Gary Edwards on 12 Dec 07 - Cached

To be fair, Microsoft seeks to solve real world problems with respect to helping customers glean more value from their information. But the approach depends on enterprises adopting an end-to-end Microsoft stack—vertically from desktop to server and horizontally across desktop and server products. The development glue is .NET Framework, while the informational glue is OOXML.
- Gary Edwards on 12 Dec 07
  
  OOXML is the transport - a portable XML document model where the "document" is the interface into content/data/ and media streaming.
  
  The binding model for OOXML is "Smart Documents", and it is proprietary!
  
  Smart Documents is how data, streaming media, scripting-routing-workflow intelligence and metadata is added to any document object.
  
  Think of the ODF binding model using XForms, XML/RDF and RDFA metadata. One could even use Jabber XMP as a binding model, which is how we did the Comcast SOA based Sales and Inventory Management System prototype.
  
  Interestingly, Smart Documents is based on pre written widgets that can simply be dragged, dropped and bound to any document object. The Infopath applicaiton provides a highly visual means for end users to build intelligent self routing forms. But Visual Studio .NET, which was released with MSOffice 2007 in December of 2006. makes it very easy for application and line of business integration developers to implement very advanced data binding using the Smart Document widgets.
  
  I would also go as far to say that what separates MSOOXML from Ecma 376 is going to be primarily Smart Documents.
  
  Yes, there are .NET Framework Libraries and Vista Stack dependencies like XAML that will also provide a proprietary "Vista Stack" only barrier to interoperability, but Smart Documents is a killer.
  
  One company that will be particularly hurt by Smart Documents is Google. The reason is that the business value of Google Search is based on using advanced and closely held proprietary algorithms to provide metadata structure for unstrucutred documents.
  
  This was great for a world awash in unstructured documents. By moving the "XML" structuring of documents down to the author - workgroup - workflow application level though, the world will soon enough be awash in highly structured documents that have end user metadata defining document objects and
  
  <div class="cArrow"> </div><div class="cContentInner">OOXML is the transport - a portable XML document model where the "document" is the interface into content/data/ and media streaming.<br><br>The binding model for OOXML is "Smart Documents", and it is proprietary! <br><br>Smart Documents is how data, streaming media, scripting-routing-workflow intelligence and metadata is added to any document object. <br><br>Think of the ODF binding model using XForms, XML/RDF and RDFA metadata. One could even use Jabber XMP as a binding model, which is how we did the Comcast SOA based Sales and Inventory Management System prototype. <br><br>Interestingly, Smart Documents is based on pre written widgets that can simply be dragged, dropped and bound to any document object. The Infopath applicaiton provides a highly visual means for end users to build intelligent self routing forms. But Visual Studio .NET, which was released with MSOffice 2007 in December of 2006. makes it very easy for application and line of business integration developers to implement very advanced data binding using the Smart Document widgets. <br><br>I would also go as far to say that what separates MSOOXML from Ecma 376 is going to be primarily Smart Documents.<br><br> Yes, there are .NET Framework Libraries and Vista Stack dependencies like XAML that will also provide a proprietary "Vista Stack" only barrier to interoperability, but Smart Documents is a killer. <br><br>One company that will be particularly hurt by Smart Documents is Google. The reason is that the business value of Google Search is based on using advanced and closely held proprietary algorithms to provide metadata structure for unstrucutred documents.<br><br>This was great for a world awash in unstructured documents. By moving the "XML" structuring of documents down to the author - workgroup - workflow application level though, the world will soon enough be awash in highly structured documents that have end user metadata defining document objects and </div>
  
  ...
  
  Cancel
...

Cancel
Microsoft seeks to create sales pull along the vertical stack between the desktop and server.
- Gary Edwards on 12 Dec 07
  
  The vertical stack is actually desktop - server - device - web based. The idea of a portable XML document is that it must be able to transition across the converged application space of this sweeping stack model.
  
  Note that ODF is intentionally limited to the desktop by it's OASIS Charter statement. One of the primary failings of ODF is that it is not able to be fully implemented in this converged space. OOXML on the other hand was created exactly for this purpose!
  
  So ODF is limited to the desktop, and remains tightly bound to OpenOffice feature sets. OOXML differs in that it is tightly bound to the Vista Stack.
  
  So where is an Open Stack model to turn to?
  
  Good question, and one that will come to haunt us for years to come. Because ODF cannot move into the converged space of desktop to server to device to the web information systems connected through portable docuemnt/data transport, it is unfit as a candidate for Universal File Format.
  
  OOXML is unfi as a UFF becuase it is application - platform and vendor bound.
  
  For those of us who believe in an open and unencumbered universal file format, it's back to the drawing board.
  
  XHTML+ (XHTML + CSS3 + RDF) is looking very good. The challenge is proving that we can build plugins for MSOffice and OpenOffice that can fully implement XHTML+. Can we conver the billions of binary legacy documents and existing MSOffice bound business processes to XHTML+?
  
  I think so. But we can't be sure until the da Vinci proves this conclusively.
  
  One thign to keep in mind though. The internal plugins have already shown that it is possible to do multiple file formats. OOXML, ODF, and XML encoded RTF all have been shown to work, and do so with a level of two way conversion fidelity demanded by existing business processes.
  
  So why not try it with XHTML+, or ODEF (the eXtended version of ODF en
  
  <div class="cArrow"> </div><div class="cContentInner">The vertical stack is actually desktop - server - device - web based. The idea of a portable XML document is that it must be able to transition across the converged application space of this sweeping stack model.<br><br>Note that ODF is intentionally limited to the desktop by it's OASIS Charter statement. One of the primary failings of ODF is that it is not able to be fully implemented in this converged space. OOXML on the other hand was created exactly for this purpose! <br><br>So ODF is limited to the desktop, and remains tightly bound to OpenOffice feature sets. OOXML differs in that it is tightly bound to the Vista Stack.<br><br>So where is an Open Stack model to turn to?<br><br>Good question, and one that will come to haunt us for years to come. Because ODF cannot move into the converged space of desktop to server to device to the web information systems connected through portable docuemnt/data transport, it is unfit as a candidate for Universal File Format.<br><br>OOXML is unfi as a UFF becuase it is application - platform and vendor bound.<br><br>For those of us who believe in an open and unencumbered universal file format, it's back to the drawing board.<br><br>XHTML+ (XHTML + CSS3 + RDF) is looking very good. The challenge is proving that we can build plugins for MSOffice and OpenOffice that can fully implement XHTML+. Can we conver the billions of binary legacy documents and existing MSOffice bound business processes to XHTML+?<br><br>I think so. But we can't be sure until the da Vinci proves this conclusively.<br><br>One thign to keep in mind though. The internal plugins have already shown that it is possible to do multiple file formats. OOXML, ODF, and XML encoded RTF all have been shown to work, and do so with a level of two way conversion fidelity demanded by existing business processes. <br><br>So why not try it with XHTML+, or ODEF (the eXtended version of ODF en</div>
  
  ...
  
  Cancel
...

Cancel
Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats.
- Gary Edwards on 12 Dec 07
  
  This backwards compatibility with the existing binary file formats isn't the big deal Micrsoft makes it out to be. ODF 1.0 includes a "Conformance Clause", (Section 1.5) that was designed and included in the specification exactly so that the billions of binary legacy documents could be converted into ODF XML.
  
  The problem with the ODF Conformance Clause is that the leading ODF application, OpenOffice, does not fully support and implement the Conformance Clause.
  
  The only foreign elements supported by OpenOffice are paragraphs and text spans. Critically important structural document characteristics such as lists, fields, tables, sections and page breaks are not supported!
  
  This leads to a serious drop in conversion fidelity wherever MS binaries are converted to OpenOffice ODF.
  
  Note that OpenOffice ODF is very different from MSOffice ODF, as implemented by internal conversion plugins like da Vinci. KOffice ODF and Googel Docs ODF are all different ODF implementations. Because there are so many different ways to implement ODF, and still have "conforming" ODF documents, there is much truth to the statement that ODF has zero interoperabiltiy.
  
  It's also true that OOXML has optional implementation areas. With ODF we call these "optional" implementation areas "interoperabiltiy break points" because this is exactly where the document exchange presentation fidelity breaks down, leaving the dominant market ODF applicaiton as the only means of sustaining interoperabiltiy.
  
  With OOXML, the entire Vista Stack - Win32 dependency layer is "optional". No doubt, all MSOffice - Exchange/SharePoint Hub applications will implement the full sweep of proprietary dependencies. This includes the legacy Win32 API dependencies (like VML, EMF, EMF +), and the emerging Vista Stack dependencies that include Smart Documents, XAML, .NET 3.0 Libraries, and DrawingML.
  
  MSOffice 2007 i
  
  <div class="cArrow"> </div><div class="cContentInner">This backwards compatibility with the existing binary file formats isn't the big deal Micrsoft makes it out to be. ODF 1.0 includes a "Conformance Clause", (Section 1.5) that was designed and included in the specification exactly so that the billions of binary legacy documents could be converted into ODF XML.<br><br>The problem with the ODF Conformance Clause is that the leading ODF application, OpenOffice, does not fully support and implement the Conformance Clause. <br><br>The only foreign elements supported by OpenOffice are paragraphs and text spans. Critically important structural document characteristics such as lists, fields, tables, sections and page breaks are not supported!<br><br>This leads to a serious drop in conversion fidelity wherever MS binaries are converted to OpenOffice ODF.<br><br>Note that OpenOffice ODF is very different from MSOffice ODF, as implemented by internal conversion plugins like da Vinci. KOffice ODF and Googel Docs ODF are all different ODF implementations. Because there are so many different ways to implement ODF, and still have "conforming" ODF documents, there is much truth to the statement that ODF has zero interoperabiltiy.<br><br>It's also true that OOXML has optional implementation areas. With ODF we call these "optional" implementation areas "interoperabiltiy break points" because this is exactly where the document exchange presentation fidelity breaks down, leaving the dominant market ODF applicaiton as the only means of sustaining interoperabiltiy.<br><br>With OOXML, the entire Vista Stack - Win32 dependency layer is "optional". No doubt, all MSOffice - Exchange/SharePoint Hub applications will implement the full sweep of proprietary dependencies. This includes the legacy Win32 API dependencies (like VML, EMF, EMF +), and the emerging Vista Stack dependencies that include Smart Documents, XAML, .NET 3.0 Libraries, and DrawingML.<br><br>MSOffice 2007 i</div>
  
  ...
  
  Cancel
...

Cancel
...6 more annotations...
Microsoft's backwards compatibility priority means the company made XML-based format decisions that compromise the open objectives of XML. Open Office XML is neither open nor XML.
- Gary Edwards on 12 Dec 07
  
  True, but a tricky statement given that the proprietary OOXML implementation is "optional". It is theoretically possible to implement Ecma 376 without the prorpietary dependencies of MSOffice - Exchange/SharePoint Hub - Vista Stack "OOXML".
  
  In fact, this was first demonstrated by the legendary document processing - plugin architecture expert, Florian Reuter.
  
  Florian has the unique distinction of being the primary architect for two major plugins: the da Vinci ODF plugin for MSOffice, and, the Novell OOXML Translator plugin for OpenOffice!
  
  It is the Novell OOXML Translator Plugin for OpenOffice that first demonstrated that Ecma 376 could be cleanly implemented without the MSOffice application-platform-vendor specific dependencies we find in every MSOffice OOXML document.
  
  So while Joe is technically correct here, that OOXML is neither open nor XML, there is a caveat. For 95% of all desktops and near 100% of all desktops in a workgroup, Joe's statment holds true. For all practical concerns, that's enough. For Microsoft's vaunted marketing spin machine though, they will make it sound as though OOXML is actually open and application-platform-vendor independent.
  
  <div class="cArrow"> </div><div class="cContentInner">True, but a tricky statement given that the proprietary OOXML implementation is "optional". It is theoretically possible to implement Ecma 376 without the prorpietary dependencies of MSOffice - Exchange/SharePoint Hub - Vista Stack "OOXML".<br><br>In fact, this was first demonstrated by the legendary document processing - plugin architecture expert, Florian Reuter.<br><br>Florian has the unique distinction of being the primary architect for two major plugins: the da Vinci ODF plugin for MSOffice, and, the Novell OOXML Translator plugin for OpenOffice!<br><br>It is the Novell OOXML Translator Plugin for OpenOffice that first demonstrated that Ecma 376 could be cleanly implemented without the MSOffice application-platform-vendor specific dependencies we find in every MSOffice OOXML document.<br><br>So while Joe is technically correct here, that OOXML is neither open nor XML, there is a caveat. For 95% of all desktops and near 100% of all desktops in a workgroup, Joe's statment holds true. For all practical concerns, that's enough. For Microsoft's vaunted marketing spin machine though, they will make it sound as though OOXML is actually open and application-platform-vendor independent.<br><br><br></div>
  
  ...
  
  Cancel
...

Cancel
Microsoft got there first to protect Office.
- Gary Edwards on 12 Dec 07
  
  No. I disagree. Microsoft needs to move to XML structured documents regardless of what others are doing. The binary document model is simply unable to be useful to any desktop- to server- to device- to the web- transport!
  
  Many wonder what Microsoft's SOA strategy is. Well, it's this: the Vista Stack based on OOXML-Smart Documents-.NET.
  
  The thing is, Microsoft could not afford to market a SOA solution until all the proprietary solutions of the Vista Stack were in place.
  
  The Vista Stack looks like this:
  
  ..... The core :: MSOffice <> OOXML <> IE <> The Exchange/SharePoint Hub
  
  ..... The services :: E/S HUb <> MS SQL Server <> MS Dynamics <> MS Live <> MS Active Directory Server <> MSOffice RC Front End
  
  The key to the stack is the OOXML-Smart Documents capture of EXISTING MSOffice bound business processes and documents.
  
  The trick for Microsoft is to migrate these existing business processes and documents to the E/S Hub where line of business developers can re engineer aging desktop LOB apps.
  
  The productivity gains that can be had through this migration to the E/S Hub are extraordinary.
  
  A little over a year ago an E/S Hub verticle market application called "Agent Achieve" came out for the real estate industry. AA competed against a legacy of twenty years of contact management based - MLS data connected desktop shrinkware applications. (MLS-Multiple Listing Service)
  
  These traditional desktop client/server productivity apps defined the real estate business process as far as it could be said to be "digital". For the most part, the real estate transaction industry remains a paper driven process. The desktop stuff was only useful for managing clients and lead prospecting. No one could crack the electronic documents - electonic business transaction model. This will no doubt change with the emer
  
  <div class="cArrow"> </div><div class="cContentInner">No. I disagree. Microsoft needs to move to XML structured documents regardless of what others are doing. The binary document model is simply unable to be useful to any desktop- to server- to device- to the web- transport! <br><br>Many wonder what Microsoft's SOA strategy is. Well, it's this: the Vista Stack based on OOXML-Smart Documents-.NET. <br><br>The thing is, Microsoft could not afford to market a SOA solution until all the proprietary solutions of the Vista Stack were in place. <br><br>The Vista Stack looks like this: <br><br>..... The core :: MSOffice <> OOXML <> IE <> The Exchange/SharePoint Hub <br><br>..... The services :: E/S HUb <> MS SQL Server <> MS Dynamics <> MS Live <> MS Active Directory Server <> MSOffice RC Front End <br><br>The key to the stack is the OOXML-Smart Documents capture of EXISTING MSOffice bound business processes and documents. <br><br>The trick for Microsoft is to migrate these existing business processes and documents to the E/S Hub where line of business developers can re engineer aging desktop LOB apps. <br><br>The productivity gains that can be had through this migration to the E/S Hub are extraordinary. <br><br>A little over a year ago an E/S Hub verticle market application called "Agent Achieve" came out for the real estate industry. AA competed against a legacy of twenty years of contact management based - MLS data connected desktop shrinkware applications. (MLS-Multiple Listing Service) <br><br>These traditional desktop client/server productivity apps defined the real estate business process as far as it could be said to be "digital". For the most part, the real estate transaction industry remains a paper driven process. The desktop stuff was only useful for managing clients and lead prospecting. No one could crack the electronic documents - electonic business transaction model. This will no doubt change with the emer</div>
  
  ...
  
  Cancel
...

Cancel
Microsoft can offer businesses many of the informational sharing and mining benefits associated with the markup language while leveraging Office and supporting desktop and server products as the primary consumption conduit.
- Gary Edwards on 12 Dec 07
  
  Okay, now Joe has the Micrsoft SOA bull by the horns. Why doesn't he wrestle the monster down?
  
  <div class="cArrow"> </div><div class="cContentInner">Okay, now Joe has the Micrsoft SOA bull by the horns. Why doesn't he wrestle the monster down?<br></div>
  
  ...
  
  Cancel
...

Cancel
By adapting XML
- Gary Edwards on 12 Dec 07
  
  The requirements of these E/S Hub systems are XP, XP MSOffice 2003 Professional, Exchange Server with OWL (Outlook on the Web) , SharePoint Server, Active Directory Server, and at least four MS SQL Servers!
  
  In Arpil of 2006, Microsoft issued a harsh and sudden End-of-Life for all Windows 2000 - MSOffice 2000 systems in the real estate industry (although many industries were similarly impacted). What happened is that on a Friday afternoon, just prior to a big open house weekend, Microsoft issued a security patch for all Exchange systems. Once the patch was installed, end users needed IE 7.0 to connect to the Exchange Server Systems.
  
  Since there is no IE 7.0 made for Windows 2000, those users relying on E/S Hub applications, which was the entire industry, suddenly found themselves disconnected and near out of business.
  
  Amazingly, not a single user complained! Rather than getting pissed at Microsoft for the sudden and very disruptive EOL, the real estate users simply ran out to buy new XP-MSOffice 2003 systems. It was all done under the rational that to be competitive, you have to keep up with technology systems.
  
  Amazing. But it also goes to show how powerfully productive the E/S Hub applications can be. This wouldn't have happened if the E/S Hub applications didn't have a very high productivity value.
  
  When we visited Massachusetts in June of 2006, to demonstrate and test the da Vinci ODF plugin for MSOffice, we found them purchasing en mass E/S Hubs! These are ODF killers! Yet Microsoft sales people had convinced Massachusetts ITD that Exchange/SahrePoint was a simple to use eMail-calendar-portal system. Not a threat to anyone!
  
  The truth is that in the E/S Hub ecosystem, OOXML is THE TRANSPORT. ODF is a poor, second class attachment of no use at the application - document processing chain level.
  
  Even if Massachusetts had mandated ODF, they were only one E/S Hub Court Doc
  
  <div class="cArrow"> </div><div class="cContentInner"> The requirements of these E/S Hub systems are XP, XP MSOffice 2003 Professional, Exchange Server with OWL (Outlook on the Web) , SharePoint Server, Active Directory Server, and at least four MS SQL Servers! <br> <br> In Arpil of 2006, Microsoft issued a harsh and sudden End-of-Life for all Windows 2000 - MSOffice 2000 systems in the real estate industry (although many industries were similarly impacted). What happened is that on a Friday afternoon, just prior to a big open house weekend, Microsoft issued a security patch for all Exchange systems. Once the patch was installed, end users needed IE 7.0 to connect to the Exchange Server Systems. <br> <br> Since there is no IE 7.0 made for Windows 2000, those users relying on E/S Hub applications, which was the entire industry, suddenly found themselves disconnected and near out of business. <br> <br> Amazingly, not a single user complained! Rather than getting pissed at Microsoft for the sudden and very disruptive EOL, the real estate users simply ran out to buy new XP-MSOffice 2003 systems. It was all done under the rational that to be competitive, you have to keep up with technology systems.<br> <br> Amazing. But it also goes to show how powerfully productive the E/S Hub applications can be. This wouldn't have happened if the E/S Hub applications didn't have a very high productivity value. <br> <br> When we visited Massachusetts in June of 2006, to demonstrate and test the da Vinci ODF plugin for MSOffice, we found them purchasing en mass E/S Hubs! These are ODF killers! Yet Microsoft sales people had convinced Massachusetts ITD that Exchange/SahrePoint was a simple to use eMail-calendar-portal system. Not a threat to anyone! <br> <br> The truth is that in the E/S Hub ecosystem, OOXML is THE TRANSPORT. ODF is a poor, second class attachment of no use at the application - document processing chain level. <br> <br> Even if Massachusetts had mandated ODF, they were only one E/S Hub Court Doc</div>
  
  ...
  
  Cancel
...

Cancel
Microsoft will vie for the whole business software stack, a strategy that I believe will be indisputable by early 2009 at the latest.
- Gary Edwards on 12 Dec 07
  
  Finally, someone who understands the grand strategy of levergaing the desktop monopoly into the converged space of server, device and web information systems.
  
  What Joe isn't watching is the way the Exchange/SharePoint Server connects to MS SQL Server, Active Directory Server, MS LIve and MS Dynamics.
  
  Also, Joe does not see the connection between OOXML as the portable XML document/data transport, and the insidiously proprietary Smart Documents metadata - data binding system that totally separates MSOOXML from Ecma 376 OOXML!
  
  <div class="cArrow"> </div><div class="cContentInner">Finally, someone who understands the grand strategy of levergaing the desktop monopoly into the converged space of server, device and web information systems. <br><br>What Joe isn't watching is the way the Exchange/SharePoint Server connects to MS SQL Server, Active Directory Server, MS LIve and MS Dynamics. <br><br>Also, Joe does not see the connection between OOXML as the portable XML document/data transport, and the insidiously proprietary Smart Documents metadata - data binding system that totally separates MSOOXML from Ecma 376 OOXML!<br> </div>
  
  ...
  
  Cancel
...

Cancel
I'm convinced that Office as a platform is an eventual dead end. But Microsoft is going to lead lots of customers and partners down that platform path.
- Gary Edwards on 12 Dec 07
  
  Yes, but the new platform for busines process development is that of MSOffice <> Exchange/SharePoint Hub.
  
  The OOXML-Smart Docs transport replaces the old binary document with OLE and VBA Scripts and Macros functionality. Which, for the sake of brevity we can call the lead Win32 API dependencies.
  
  One substantial difference is that OOXML-Smart Docs is Vista Stack ready, while the Win32 API dependencies were desktop bound.
  
  Another way of looking at this is to see that the old MSOffice platform was great for desktop application integration. As long as the complete Win32 API was available (Windows + MSOffice + VBA run times), this platform was great for workgroups. The Line of Business integrated apps were among the most brittle of all client/server efforts, bu they were the best for that generation.
  
  The Internet offers everyone a new way of integrating data, content and streaming media. Web applications are capable of loosly coupled serving and consuming of other application services. Back end systems can serve up data in a number of ways: web services as SOAP, web services as AJAX/REST, or XML data streams as in HTTPXMLRequest or Jabber P2P model.
  
  On the web services consumption side, it looks like AJAX/REST will be the block buster choice, if the governance and security issues can be managed.
  
  Into this SOA mash Microsoft will push with a sweeping integrated stack model. Since the Smart Docs part of the OOXML-Samrt Docs transport equation is totally proprietary, but used throughout the Vista Stack, it will provide Microsoft with an effective customer lockin - OSS lockout point.
  
  <div class="cArrow"> </div><div class="cContentInner">Yes, but the new platform for busines process development is that of MSOffice <> Exchange/SharePoint Hub.<br><br>The OOXML-Smart Docs transport replaces the old binary document with OLE and VBA Scripts and Macros functionality. Which, for the sake of brevity we can call the lead Win32 API dependencies.<br><br>One substantial difference is that OOXML-Smart Docs is Vista Stack ready, while the Win32 API dependencies were desktop bound.<br><br>Another way of looking at this is to see that the old MSOffice platform was great for desktop application integration. As long as the complete Win32 API was available (Windows + MSOffice + VBA run times), this platform was great for workgroups. The Line of Business integrated apps were among the most brittle of all client/server efforts, bu they were the best for that generation.<br><br>The Internet offers everyone a new way of integrating data, content and streaming media. Web applications are capable of loosly coupled serving and consuming of other application services. Back end systems can serve up data in a number of ways: web services as SOAP, web services as AJAX/REST, or XML data streams as in HTTPXMLRequest or Jabber P2P model.<br><br>On the web services consumption side, it looks like AJAX/REST will be the block buster choice, if the governance and security issues can be managed.<br><br>Into this SOA mash Microsoft will push with a sweeping integrated stack model. Since the Smart Docs part of the OOXML-Samrt Docs transport equation is totally proprietary, but used throughout the Vista Stack, it will provide Microsoft with an effective customer lockin - OSS lockout point.<br><br> </div>
  
  ...
  
  Cancel
...

Cancel

PC Pro: News: Google Docs accommodates Office 2007 file formats - 0 views

www.pcpro.co.uk/...-office-2007-file-formats.html

Google Docs OOXML

shared by Paul Merrell on 02 Jun 09 - Cached

Google has added support for the DOCX and XLSX file formats to the Google Docs office suite.
...

Cancel
Google has now rectified this situation following the ratification of the Open XML standard last year, but anybody looking to import the PPTX files used by PowerPoint 2007 will need to wait. The files can be converted into a Google Docs-friendly format, but you'll lose formatting, themes and transition effects.
...

Cancel

Microsoft Finds Fault With Google Upgrade -- Redmondmag.com - 2 views

redmondmag.com/...ttles-google-docs-upgrade.aspx

Google Microsoft ODF

shared by Paul Merrell on 16 Apr 10 - Cached

Google's announcement this week that it had improved its Google Docs Web apps drew ridicule from a Microsoft official on Wednesday.
...

Cancel
Kisslo also accused Google of not following the OpenDocument Format (ODF) spec with fidelity in Google Docs applications. The Google spokesperson called that claim "ironic" for Microsoft. (Microsoft has had its own issues staying true to the ISO/IEC-standardized version of its Office Open XML document format spec. However, the company did previously announce support for ODF in Office 2007.) This seemingly minor spat between the two companies has deep implications. At stake may be much of Microsoft's empire, based on its two cash cows: Microsoft Office and Windows.
...

Cancel

FAA May Ditch Microsoft's Windows Vista And Office For Google And Linux Combo - Technol... - 0 views

www.informationweek.com/...showArticle.jhtml

iso microsoft odf ooxml xml

shared by Gary Edwards on 12 Dec 07 - Cached

Bowen's compatibility concerns, combined with the potential cost of upgrading the FAA's 45,000 workers to Microsoft's next-generation desktop environment, could make the moratorium permanent. "We're considering the cost to deploy [Windows Vista] in our organization. But when you consider the incompatibilities, and the fact that we haven't seen much in the way of documented business value, we felt that we needed to do a lot more study," said Bowen. Because of Google Apps' sudden entry into the desktop productivity market
...

Cancel

Gary Edwards on 12 Dec 07

The FAA issues their "NO ViSTA" mandate, hinting that it might be permanent if they can come up with MSOffice alternatives. They are looking at Google Apps!

Okay, so plan B does have legs. The recent failure of ISO/IEC to stand up to the recidivist reprobate from Redmond is having repercussions. Who would have ever thought ISO would fold so quickly without ceremony? One day there are 20 out of 30 JTCS1 national bodies (NB's) objecting to Micrsoft's proprietary XML proposal, the MOOX Ecma 376 specfication, and the next ISO is approving without comment the placing of MOOX into the ISO fast track where approval is near certain. With fast track, the technical objections and contradictions are assumed to be the provence of Ecma, and not the JTCS1 experts group.

Apparently the USA Federal Government divisions had a plan B contingency for just such a case. And why not? Microsoft was able to purchase a presidential pardon for their illegal anti trust violations. If they can do that, what's to stop them from purchasing an International Standard? Piece of cake!

But Google Apps? And i say that as one who uses Google Docs every day.

The problem of migrating away from MSOffice and MOOX to ODF or some other "open" XML portable file format is that there are two barriers one must cross.

The first barrier is that of converting the billions of MS binary docuemnts into ODF XML.

The second is that of replacing the MSOffice bound business processes that drive critical day to day business operabions.

Google Apps is fine for documents that benefit from collaborative computing activities. But there is no way one can migrate MSOffice bound business processes - the workgroup-worflow documents to Google Apps. For one thing Google Apps is unable to facillitate important issues like XForms. Nor can they round trip an ODF document with the needed fidelity a

<div class="cArrow"> </div><div class="cContentInner">The FAA issues their "NO ViSTA" mandate, hinting that it might be permanent if they can come up with MSOffice alternatives. They are looking at Google Apps!<br><br>Okay, so plan B does have legs. The recent failure of ISO/IEC to stand up to the recidivist reprobate from Redmond is having repercussions. Who would have ever thought ISO would fold so quickly without ceremony? One day there are 20 out of 30 JTCS1 national bodies (NB's) objecting to Micrsoft's proprietary XML proposal, the MOOX Ecma 376 specfication, and the next ISO is approving without comment the placing of MOOX into the ISO fast track where approval is near certain. With fast track, the technical objections and contradictions are assumed to be the provence of Ecma, and not the JTCS1 experts group.<br><br>Apparently the USA Federal Government divisions had a plan B contingency for just such a case. And why not? Microsoft was able to purchase a presidential pardon for their illegal anti trust violations. If they can do that, what's to stop them from purchasing an International Standard? Piece of cake!<br><br>But Google Apps? And i say that as one who uses Google Docs every day.<br><br>The problem of migrating away from MSOffice and MOOX to ODF or some other "open" XML portable file format is that there are two barriers one must cross.<br><br>The first barrier is that of converting the billions of MS binary docuemnts into ODF XML. <br><br>The second is that of replacing the MSOffice bound business processes that drive critical day to day business operabions. <br><br>Google Apps is fine for documents that benefit from collaborative computing activities. But there is no way one can migrate MSOffice bound business processes - the workgroup-worflow documents to Google Apps. For one thing Google Apps is unable to facillitate important issues like XForms. Nor can they round trip an ODF document with the needed fidelity a</div>

...

Cancel

We Can No Longer Unbundle Microsoft Office - 0 views

techcrunch.com/...cannot-unbundle-office-anymore

wordsdk Office-365 office-formats Office-Productivity

shared by Gary Edwards on 11 Aug 14 - No Cached

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 on 11 Aug 14
  
  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.
  
  <div class="cArrow"> </div><div class="cContentInner">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.</div>
  
  ...
  
  Cancel
...

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

Cancel
Feature-bundled workflows to get things done on the device you’re looking at are necessities, not nice pairings like chocolate and peanut butter.
...

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

Cancel

Google should switch to ODF to gain market in Europe | The Mukt - 2 views

www.themukt.com/...-switch-odf-gain-market-europe

ODF OOXML Microsoft

shared by Gary Edwards on 25 Jul 14 - No Cached

Gary Edwards on 25 Jul 14

"Microsoft is definitely not happy with the UK government's decision to use ODF for government documents. The UK has made the right decision as Microsoft's file formats create a vendor lock where only Microsoft can offer software, cutting out every single player on planet earth. Microsoft works really hard to make its documents almost incompatible with every word processor out there. If you have created document in MS file formats, using Microsoft software, you have created document which will lose data if opened with non-Microsoft software. You may blame LibreOffice, openOffice, Calligra or Google Docs for 'losing some data', but the blame goes to Microsoft. So the best solution is to move away from Microsoft file-formats, so that you can break this vicious cycle. But how many people use ODF? Not many that I know of. The reason is simple, Microsoft pushes its own X formats which it claims to implement the OOXML specification. That's not surprising. What's surprising is that Google also pushes X formats and has one of the most pathetic supports for ISO approved open standards ODF."

<div class="cArrow"> </div><div class="cContentInner">"Microsoft is definitely not happy with the UK government's decision to use ODF for government documents. The UK has made the right decision as Microsoft's file formats create a vendor lock where only Microsoft can offer software, cutting out every single player on planet earth. Microsoft works really hard to make its documents almost incompatible with every word processor out there. If you have created document in MS file formats, using Microsoft software, you have created document which will lose data if opened with non-Microsoft software. You may blame LibreOffice, openOffice, Calligra or Google Docs for 'losing some data', but the blame goes to Microsoft. So the best solution is to move away from Microsoft file-formats, so that you can break this vicious cycle. But how many people use ODF? Not many that I know of. The reason is simple, Microsoft pushes its own X formats which it claims to implement the OOXML specification. That's not surprising. What's surprising is that Google also pushes X formats and has one of the most pathetic supports for ISO approved open standards ODF."</div>

...

Cancel

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

www.consortiuminfo.org/...article.php

iso oasis odf officeopenxml ooxml opendocument xml

shared by Gary Edwards on 12 Dec 07 - Cached

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

Cancel

Gary Edwards on 12 Dec 07

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

<div class="cArrow"> </div><div class="cContentInner">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.<br><br>Andy points out some interesting things; such as the "Charter" similarities between MS XML-PDF and MS OOXML submisssions to Ecma:<br><br> 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]<br><br>If that sounds familiar, it should, because it echoes the absolute directive of the original OOXML technical committee charter, wh</div>

...

Cancel

ODF Plugfest: Making office tools interoperable [LWN.net] - 0 views

lwn.net/410387

webodf ODF1.2 ODF HTML+ WebKit Gecko QTWebKit

shared by Gary Edwards on 30 Oct 10 - No Cached

ODF on the web An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers. The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the <office:styles> and <office:automatic-styles> elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5. The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is for better desktop integration, and an ODFKit implementation. This means that WebODF is an easy way to add ODF support to almost any application, be it in HTML, Gtk, or QML. KO GmbH has received funding from NLnet to improve the current WebODF prototype and see how far the idea goes. Interested readers can try the online demo.
...

Cancel

Gary Edwards on 30 Oct 10

WebODF... An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers. The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the and elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5. The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is for better desktop integration, and an ODFKit implementation. This means that WebODF is an easy way to add ODF support to almost any application, be it in HTML, Gtk, or QML. KO GmbH has received funding from NLnet to improve the current WebODF prototype and see how far the idea goes. Interested readers can try the online demo.

<div class="cArrow"> </div><div class="cContentInner">WebODF... An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers. The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the and elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5. The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is for better desktop integration, and an ODFKit implementation. This means that WebODF is an easy way to add ODF support to almost any application, be it in HTML, Gtk, or QML. KO GmbH has received funding from NLnet to improve the current WebODF prototype and see how far the idea goes. Interested readers can try the online demo.</div>

...

Cancel

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

www.itwriting.com/blog

cdf microsoft mooxml odf odf-ix officeopenxml opendocument paoli

shared by Gary Edwards on 12 Dec 07 - Cached

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

Cancel
“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 on 12 Dec 07
  
  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.
  
  <div class="cArrow"> </div><div class="cContentInner">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.</div>
  
  ...
  
  Cancel
...

Cancel
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 on 12 Dec 07
  
  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.
  
  <div class="cArrow"> </div><div class="cContentInner">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.</div>
  
  ...
  
  Cancel
...

Cancel
...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 on 12 Dec 07
  
  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~
  
  <div class="cArrow"> </div><div class="cContentInner">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.<br><br> In fact, ODF version of the extremely large test file beat the OOXML load by 12 seconds. <br><br> 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.<br><br> 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. <br><br> 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.<br><br> ~ge~</div>
  
  ...
  
  Cancel
...

Cancel
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 on 12 Dec 07
  
  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~
  
  <div class="cArrow"> </div><div class="cContentInner">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!!!!<br><br> "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. <br><br> Sun made it clear that they would viciously oppose any other efforts to establish interoperability with existing Microsoft documents, applications, processes effort.<br><br> Point taken.<br><br> ~ge~</div>
  
  ...
  
  Cancel
...

Cancel
the idea that Sun is preparing a reference implementation of OOXML is laughable.
- Gary Edwards on 12 Dec 07
  
  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~
  
  <div class="cArrow"> </div><div class="cContentInner">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. <br><br> 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. <br><br> ~ge~</div>
  
  ...
  
  Cancel
...

Cancel
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 on 12 Dec 07
  
  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~
  
  <div class="cArrow"> </div><div class="cContentInner">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!<br><br> 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. <br><br> Watch out Google!<br><br> ~ge~</div>
  
  ...
  
  Cancel
...

Cancel
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 on 12 Dec 07
  
  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~
  
  <div class="cArrow"> </div><div class="cContentInner">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.<br><br> 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.<br><br> ~ge~</div>
  
  ...
  
  Cancel
...

Cancel

Gary Edwards on 12 Dec 07

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

<div class="cArrow"> </div><div class="cContentInner">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.<br><br>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.<br><br>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. <br><br>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!!!!!!!!!!<br><br>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.<br><br>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!!!!!!!!<br><br>Now i will admit that this is one very difficult issue to understand. If not f</div>

...

Cancel
Gary Edwards on 12 Dec 07

Great interview. Tim can obviously run circles around poor Jean Paoli.

<div class="cArrow"> </div><div class="cContentInner">Great interview. Tim can obviously run circles around poor Jean Paoli.</div>

...

Cancel

Microsoft playing three card monte with XML conversion, with Sun as the "outside man" w... - 0 views

blogs.zdnet.com/open-source

backwards-compatibility iso microsoft odf ooxml xml

shared by Gary Edwards on 12 Dec 07 - Cached

In a highly informative post to his Open Stack blog Wednesday, Edwards explains how three key features are necessary for organizations to convert to open formats. These are: Conversion Fidelity - the billions of binaries problem Round Trip Fidelity - the MSOffice bound business processes, line of business integrated apps, and assistive technology type add-ons Application Interop - the cross platform, inter application, cross information domain problem
...

Cancel

Gary Edwards on 12 Dec 07

Dana Blankenhorn posted this article back in March of 2007. It was right at the time when the OASIS ODF TC and Metadata XML/RDF SC (Sub Committee) were going at it hammer and tong concerning three very important file format characteristics needed to fulfill a real world interoperability expectation:

.... Compatibility - file format level interop -
::: backwards compatibility / compatibility with existing file formats, including the legacy of billions of binary Microsoft documents

....... Interoperability - application level interop-
:::::: application interoperability including interop with all Microsoft applications

<div class="cArrow"> </div><div class="cContentInner"> Dana Blankenhorn posted this article back in March of 2007. It was right at the time when the OASIS ODF TC and Metadata XML/RDF SC (Sub Committee) were going at it hammer and tong concerning three very important file format characteristics needed to fulfill a real world interoperability expectation:<br><br>.... Compatibility - file format level interop -<br>::: backwards compatibility / compatibility with existing file formats, including the legacy of billions of binary Microsoft documents<br><br>....... Interoperability - application level interop-<br>:::::: application interoperability including interop with all Microsoft applications<br><br></div>

...

Cancel

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

Cancel

Gary Edwards on 12 Dec 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

<div class="cArrow"> </div><div class="cContentInner">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.<br><br>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.<br><br>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.<br><br>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. <br><br>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</div>

...

Cancel

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

www.groklaw.net/comment.php

odf ooxml html webkit groklaw alex-brown document-wars

shared by Gary Edwards on 15 Apr 09 - Cached

The problem with that, as I understand it, is that the transitional spec is pretty much unimplementable by anybody except MS
- Jesper Lund Stocholm on 15 Apr 09
  
  Well, herein lies the problem, dude ... you don't understand it.
  
  <div class="cArrow"> </div><div class="cContentInner">Well, herein lies the problem, dude ... you don't understand it.</div>
  
  ...
  
  Cancel
...

Cancel

Gary Edwards on 16 Apr 09

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

<div class="cArrow"> </div><div class="cContentInner">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</div>

...

Cancel
Gary Edwards on 16 Apr 09

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

<div class="cArrow"> </div><div class="cContentInner">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: <a href="http://tinyurl.com/document-wars" rel="nofollow" target="_blank">http://tinyurl.com/document-wars</a></div>

...

Cancel

WebODF - 1 views

webodf.org

WebODF WebKit HTML+

shared by Gary Edwards on 01 Jun 11 - No Cached

Gary Edwards on 01 Jun 11

WebODF is a JavaScript library that makes it easy to add Open Document Format (ODF) support to your website and to your mobile or desktop application. It uses HTML and CSS to display ODF documents. WebODF is a Free Software project. All code is available under the AGPL. This means that you can use the code free of charge, investigate how it works, and share it with others. Description of WebODF From LWN: ODF on the web An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers. The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the and elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5. The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is

<div class="cArrow"> </div><div class="cContentInner">WebODF is a JavaScript library that makes it easy to add Open Document Format (ODF) support to your website and to your mobile or desktop application. It uses HTML and CSS to display ODF documents. WebODF is a Free Software project. All code is available under the AGPL. This means that you can use the code free of charge, investigate how it works, and share it with others. Description of WebODF From LWN: ODF on the web An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers. The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the and elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5. The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is </div>

...

Cancel

Adobe's Latest Acquisition Creates Buzz Around Office Docs - Flock - 0 views

www.wired.com/...adobe_acquisition

interoperability msoffice msoffice-live office20

shared by Gary Edwards on 12 Dec 07 - Cached

Adobe's foray into online productivity is unlikely to keep Microsoft's Steve Ballmer awake at night. But document sharing and collaboration features are central to Google's web-based office suite.
...

Cancel

Gary Edwards on 12 Dec 07

For a Web 2.0 application, Buzzword is very slick. It's more sophisticated and feature rich than Glide Writer, which is also written on Adobe Flex. Glide however offers an incredible array of portable office 2.0 features. It's the whole enchilada. And, Glide runs on iPhone!

Another interesting plus for Glide is that Google uses Glide Presentations for their on line PowerPoint alternative. Which is to say, Google is likely to purchase Glide while Adobe tries to build on Buzzword.

One of the disturbing things for me is that Buzzword uses a proprietary file format! In the future they will provide conversion to ODF, but that will probably be based on the OpenOffice conversion engine. Which everyone in the Web 2.0, Office 2.0, enterprise 2.0 space uses. Including Google.

The thing is, the OpenOffice conversion engine lacks the conversion fidelity to crack into existing MSOffice bound business processes.

Because they can't crack into these existing MSOffice bound business processes, the entire Office 2.0 sector is at risk. All it takes is a competing entry from Microsoft, and the entire sector will ge twiped out by the superior interoperability - integration advantage to the MSOffice - Outlook desktop that Microsoft owns and carefully guards.

Oh wait. That just happened today with the announcement of MSOffice Live! Suspiciously timed to take the oxygen out of Adobe's announcement too.

~ge~

<div class="cArrow"> </div><div class="cContentInner">For a Web 2.0 application, Buzzword is very slick. It's more sophisticated and feature rich than Glide Writer, which is also written on Adobe Flex. Glide however offers an incredible array of portable office 2.0 features. It's the whole enchilada. And, Glide runs on iPhone!<br><br>Another interesting plus for Glide is that Google uses Glide Presentations for their on line PowerPoint alternative. Which is to say, Google is likely to purchase Glide while Adobe tries to build on Buzzword.<br><br>One of the disturbing things for me is that Buzzword uses a proprietary file format! In the future they will provide conversion to ODF, but that will probably be based on the OpenOffice conversion engine. Which everyone in the Web 2.0, Office 2.0, enterprise 2.0 space uses. Including Google.<br><br>The thing is, the OpenOffice conversion engine lacks the conversion fidelity to crack into existing MSOffice bound business processes. <br><br>Because they can't crack into these existing MSOffice bound business processes, the entire Office 2.0 sector is at risk. All it takes is a competing entry from Microsoft, and the entire sector will ge twiped out by the superior interoperability - integration advantage to the MSOffice - Outlook desktop that Microsoft owns and carefully guards.<br><br>Oh wait. That just happened today with the announcement of MSOffice Live! Suspiciously timed to take the oxygen out of Adobe's announcement too.<br><br>~ge~<br><br><br><br></div>

...

Cancel

Universal Interoperability Framework for OpenDocument - 0 views

docs.google.com/Doc

cdf interop interoperability iso odef odf opendocument

shared by Gary Edwards on 12 Dec 07 - Cached

SUMMARY: The OpenDocument Foundation proposes that the OASIS Office TC begin now to create an interoperability framework for inclusion in OpenDocument v. 1.2. This document, one of a series of planned proposals, proposes first steps towards a comprehensive interoperability framework and OpenDocument conformance requirements.  This proposal is designed to bring ODF v. 1.2 into compliance with current ISO Interoperability Requirements.
...

Cancel

Gary Edwards on 12 Dec 07

The OpenDocument Foundation "Universal Interoperability Framework" Proposal has not been submitted to the OASIS ODF TC as of this bookmarking. But this version is complete except for a closing summation.

<div class="cArrow"> </div><div class="cContentInner">The OpenDocument Foundation "Universal Interoperability Framework" Proposal has not been submitted to the OASIS ODF TC as of this bookmarking. But this version is complete except for a closing summation.<br></div>

...

Cancel

Group items tagged

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

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

Google Brings Native MS Office Editing Features To Its iOS Productivity Apps - 0 views

Official Google Blog: Pagination comes to Google Docs - 0 views

Jive Buys Microsoft Office Collaboration Plugin OffiSync For Up To $30 Million - 0 views

Microsoft Watch Finally Gets it - It's the Business Applications!- Obla De OBA Da - 0 views

PC Pro: News: Google Docs accommodates Office 2007 file formats - 0 views

Microsoft Finds Fault With Google Upgrade -- Redmondmag.com - 2 views

FAA May Ditch Microsoft's Windows Vista And Office For Google And Linux Combo - Technol... - 0 views

We Can No Longer Unbundle Microsoft Office - 0 views

Google should switch to ODF to gain market in Europe | The Mukt - 2 views

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

ODF Plugfest: Making office tools interoperable [LWN.net] - 0 views

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

Microsoft playing three card monte with XML conversion, with Sun as the "outside man" w... - 0 views

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

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

WebODF - 1 views

Adobe's Latest Acquisition Creates Buzz Around Office Docs - Flock - 0 views

Universal Interoperability Framework for OpenDocument - 0 views

Related searches