Skip to main content

Home/ Document Wars/ Group items matching "fix" in title, tags, annotations or url

Group items matching
in title, tags, annotations or url

Sort By: Relevance | Date Filter: All | Bookmarks | Topics Simple Middle
2More

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

  •  
    This quote from Chalres Schultz is ridiculous. Because Novell is not allowed to commit code to OpenOffice, they must maintain a separate code base of extensions and improvements. With each build of OpenOffice, Novell must reintegrate their changes into the code base, making for a managerial nightmare. When Novell does have improvements that Sun wants though, there is no end to the hoops of fire the Sun developers will jump through to get it. The Field Enhancement routine written by Novell's Florian Router is one of those improvements that Sun had to have. Sun even went so far as to arguing for changes in the way ODF implements fields to accomodate the Novell improvements! It's important to note however that Sun did not support the ODF Field Enhancements UNTIL Novell agreed to donate Florian's code to OpenOffice!!!!!! Proving conclusively what i have been arguing for years: Sun does not allow for any changes to ODF unless and until those changes can be implemented by OpenOffice. The ODF Field Enhancements needed by Florian's fix to OpenOffice were originally proposed on July 12th, 2006, when Florian was the CTO of the OpenDocument Foundation. These changes to the way ODF implements fields were needed by the da Vinci plug-in as part of our efforts to save ODF in Massachusetts. so here we have a rather direct example of Sun refusing improvements to ODF when needed by another application (da Vinci), but supporting those exact same changes when it is OpenOffice that can be improved!!! The arguments that the OpenOffice.org Community isn't open also apply to the OASIS ODF TC work!!!!!!
  •  
    Good catch by Eric!
    This link is to the infamous Sun statement of support for MS OOXML issued by Jon Bosak when ISO DIS 2900 was voted on by the US delegation to ISO.
    The statement is important because it directly references the core issue: MS OOXML was written for MSOffice and the billions of binary docuemnts bound to that application suite. ODF on the other hand was written to OpenOffice.
    Because ODF was not designed for the conversion of those billions of MSOffice documents, conversion is next to impossible. The implementation of ODF in MSOffice is next to impossible. The loss of information, especially the presentation-layout information, is so severe as to be intolerable in the real world.
    This leaves the real world, where MSOffice dominates over 550 million desktops, unable to implement ODF. In light of this real world problem, Sun's Bosak urges support for MS OOXML as an ISO standard!!!
    So we have this situation at OASIS ODF where Sun is in control of both ODF and OpenOffice, refusing in all cases to compromise the linkage or accomodate the much needed interoperability enhancemnts seeking to improve the conversion of billions of documents to ODF. And publicly supporting MS OOXML as the only pragmatic alternative to the situation Sun is responsible for!
2More

The Harmonization Myth: ISO Approval of Open XML Will Hurt Interoperability - 0 views

  • This myth is rather silly if you think about it. Here is why… When people talk about interoperability and Open XML they do so primarily in the context of ODF. The story goes something like this: 1. Open XML is not interoperable with ODF 2. Open XML should be interoperable with ODF because ODF is already an ISO standard! 3. Hence: Open XML is no good, because it is not interoperable with ODF and therefore Open XML should not be an ISO standard!!!
    • Gary Edwards
       
      Forget ISO approval of OOXML. I would rather see ISO enforce the current directive that ODF be brought into compliance with existing ISO Interoperability requirements. Then and only then should ISO then consider OOXML.
      The reason for this approach? If ODF wiere compliant with existing ISO Interop Requirements, there would probably be some hope of harmonizing ODF and OOXML. Until ODF is stripped of it's application specific settings, and fully documented, we can hardly beging the process of figuring out harmonization.
      ODF 1.0 has four gapping holes that must be tended to before ISO proceeds any furhter with either ODF or OOXML. The holes are that ODF numbered lists, formulas and the presentation layer (styles) are woefully underspecified. The fourth problem is that ODF is seriously lacking an interoperability framework.
      These ODF problems can of course be traced back to the fact that ODF is application specific and bound to the "semantics and capabilities" of OpenOffice. That creates all kinds of problems. OOXML on the other hand is even worse. OOXML is application, platform and vendor specific!!!! If ODF were brought up to snuff, we could reasonably start work on harmonization. Thereby eliminating the need to standardize two file formats for the same purposes. Until ODF is fixed, what's the world to do?
      ~ge~
7More

ODF and OOXML - The Final Act - 0 views

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

Notes on Breaking the Web to Ride the Fifth Wave - 1 views

  • garyedwards's Discussions Breaking the Web Talkback: Google: OOXML 'insufficient and unnecessary'
  •  
    Somehow i got involved in this discussion and ended up posting a number of comments explaining the how and why behind Microsoft's push for ISO approval of MS-OOXML. I have been working on a paper titled, "Breaking the Web to Ride the Great Wave". Breaking the Web is what will happen once ISO approves MS-OOXML. The MIcrosoft Stack of Web Servers (Exchange, SharePoint, MS-SQL Server) are integrated into the MSOffice-Outlook desktop. The MS desktop dominates much of the document workflows and business processes of the commercial world. ISO approval of the MSOffice specific MS-OOXML will legitamize MSOffice as an editor of standardized web ready docuemnts. But how MS-OOXML docuemnts become "Web REady" is tricky. In the December 2007 MSOffice SDK beta, we see how this is done. The SDK provides a conversion component for the quick high fidelity conversion of MS-OOXML documents to XAML. XAML is a proprietary part of the WPF (Windows Presentation Foundation) layer of the .NET framework, and is easily paried with Silverlight. Sometimes XAML is referred to as "fixed/flow". XAML is an MS proprietary replacement for the W3C's (X)HTML. Billions of MSOffice docuemnts will make their way to the Web using this SDK converter. The path for transitioning the monopolist hold on desktop business processes to the monopolist stack of web servers is set with this converter. ISO approval of MS-OOXML will enable Microsoft to dodge brining their desktop editor into compliance with advancing W3C standards such as (X)HTML, CSS 3, XForms, SVG and RDF. Instead of these open standards, transitioning business processes will be locked into MS only dependencies; XAML, Silverlight, WinForms, and Smart Tags. The breaking of the web results in a consumer/business cloud dependent on MS proprietary technologies that are out of the reach of Firefox, Apache, Java, and Adobe technologies. Google won't be able to penetrate the business stack, and will be kept very busy trying to defen
13More

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

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

We Can No Longer Unbundle Microsoft Office - 0 views

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