Skip to main content

Home/ Document Wars/ Group items tagged formats

Rss Feed Group items tagged

Gary Edwards

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

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

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

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

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

CDF: The common format you've never heard of - O'Reilly XML Blog - Flock - 0 views

  • Quick! Do you use the Compound Document Format?! You, know, CDF … surely you use CDF, right? Chances are pretty good that you have no idea about what I’m talking about. Everyone knows Microsoft’s word document format and Adobe’s PDF, chances are pretty good that if you’re reading this on XML.com you’ve heard of ODF and OOXML, especially after the fairly rancorous discussions about ISO status for these two formats. Yet CDF, hmmmm … that’s a rough one. Didn’t it belong to Corel, once upon a time?
  • CDF was in the news recently with the implosion of the Open Document Foundation, originally established to endorse ODF, though in its death throes it briefly highlighted the CDF format as perhaps a better format for documents than either OOXML or ODF. This is admittedly one of those areas where it may be justified in looking at XHTML especially and going “huh”? How can that be a full document format - it’s used for web pages, after all - you wouldn’t want to use it to mark up a full book, would you? Document formats are a lot like religions - people are ready to defend them to the death if need be, yet at the same time it becomes easy to dismiss certain religions that don’t even seem to be religions at all (such as my personal favorite, the rather philosophical Tao). Could you mock up a brochure in XHTML and CSS? Actually, it turns out that its surprisingly easy to do just that - especially if you throw a little SVG into the mix and allow the possibility of embedding XHTML within SVG (for all those odd little bits of rotation and other special effects).
Gary Edwards

Open Document Foundation Gives Up | Linux Magazine - 0 views

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

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

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

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

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

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

    In Massachusetts, the Foundation took
Gary Edwards

Harmonizing ODF and OOXML using NameSpaces | Tim Bray's Thought Experiment - 0 views

  • First, what if Microsoft really is doing the right thing? Second, how can we avoid having two incompatible file formats? [Update: There’s been a lot of reaction to this piece, and I addressed some of those points here.]
  • On the technology side, the two formats are really more alike than they are different. But, there are differences: O12X’s design center, Microsoft has said repeatedly, is capturing the exact semantics of the billions of existing Microsoft Office documents. ODF’s design center is general-purpose reusability, and leveraging existing standards like SVG and MathML and so on.
    • Gary Edwards
       
      OOXML, or to put it more accurately "O12X" as Tim suggests, is designed to capture the exact semantics of MSOffice 12. In fact, OOXML is an XML encoding of the MSOffice 12 in-memory-binary-representation dump. When it comes to representing older versions of MSOffice documents, OOXML must use legacy compatibility settings" to capture the semantics. And it's not an exacting science to say the least. The thing is, OpenOffice ODF uses the same technique resulting in application specific ODF documents with over 150 un docuemnted, unspecified "compatibility settings". After years of requests from the OASIS ODF Technical Committee to document these application specific settings, Sun has yet to provide any kind of response. And this kills ODF interoperability. Especially concerning KOffice. There is also the issue of OASIS ODF high-jacked namespaces. When ODF applications reference a namespace, the actual URL is high-jacked with http://oasis-open.org/???? replacing the proper namespace of http://W3C.org/???? This high-jacking impacts the oDF reuse of important W3C technologies such as XForms, SVG, MathML, and SMiL. So where's the problem you ask? Well, when a developer imports or tries to process an OpenOffice ODF document, they rely on say the W3C XForms specification for their understanding. OpenOffice however seriously constrains the implementation of XForms, SVG, MathML, RDFa and RDF/XML. This should be reflected in the new namespace. However, if you follow the high-jacked URL, you'll find that there is nothing there. There is no specification describing how OpenOffice implements XForms in ODF! This breaks developer libraries, breaks ODF interoperability between ODF applications, and, offends the W3C to no end. So i think it might be fair to say that at this point, neither ODF or OOXML have come close to fulfilling their design objectives.
  • The capabilities of ODF and O12X are essentially identical for all this basic stuff. So why in the flaming hell does the world need two incompatible formats to express it? The answer, obviously, is, “it doesn’t”.
    • Gary Edwards
       
      Exactly!! Except for one thing that Tim misses: the presentation layers of both ODF and OOXML are application specific. It is also the application specific nature of OpenOffice ODF presnetation layer that prevents interoperability with KOffice ODF! There is near zero interop between OpenOffice and KOffice, and KOffice has been a contributing member of the OASIS ODF TC for FIVE YEARS! It's the presentation layer Tim. ODF and OOXML are application specific formats because their presentation layers are woefully applicaiton specific and entirely reflective of each applications layout engine and feature set implementation model. I often imagine what ODF would be like if back in 2001, Sun had chosen to implement CSS as the OpenOffice presentation layer instead of the quirky but innovative, and 100% application specific automatic-styles presentation layer we now see in ODF. Unlike ODF's "automatic-styles", CSS is a totally application independent presentation model prized exactly for it's universal interoperability!
  • ...1 more annotation...
  • The ideal outcome would be a common shared office-XML dialect for the basics—and it should be ODF (or a subset), since that’s been designed and debugged—then another extended vocabulary to support Microsoft features , whether they’re cool new whizzy features or mouldy old legacy features (XML Namespaces are designed to support exactly this kind of thing). That way, if you stayed with the basic stuff you’d never need to worry about software lock-in; the difference between portable and proprietary would be crystal-clear. And, for the basic stuff that everybody uses, there’d be only one set of tags. This outcome is technically feasible. Who could possibly be against it?
    • Gary Edwards
       
      Bingo! ODF and OOXML should strip off the application specific complexities and seek a neutral generic XML representation of basic document structures common to ALL documents. Then, use the XML NameSpace mechanism to extend (with proper descriptions) the generic to include the volumes of application specific features that now fill each format. One thing i disagree with Tim about. And that's that the interop of ODF and OOXML is hopelessly broken. The OpenDocument Foundation tried for over a year to close the compatibility gap between ODF and MSOffice binary - xml documents. The OASIS ODF TC would have none of it. IBM and Sun are set on a harsh course of highly disruptive and costly rip-out-and-replace of MSOffice based on government mandates for ODF. There is no offer of compromise to be had. On the Microsoft side, even if they did want to compromise (a big IF), there is that problem of over 550 million MSOffice workgroup-workflow desktops to contend with. The thing is, the only way to harmonize, merge, convert or translate between two application specific formats is to actually harmonize the applications themselves. While the generic subset is a worthy goal, the process would be fraught with real world concerns that the existing application workflows are not disrupted. My proposal? Demand that ODF and OOXML application vendors provide format options for PDF, and the W3C's family of formats: (X)HTML5, (X)HTML - CSS, and CDF (XHTML-CSS-XForms-SVG-SMil-MathML). That will do it. We might never see the quality of interoperability we had hoped for in a desktop application to application scenario. But we can and should fully expect high quality interop at the higher level of the Web. You can convert an application specific format to a generic like CDF. By setting up conversion channels to the same CDF profile within MSOffice, OpenOffice, KOffice, Symphony, and Google Docs, we can achieve the universal interoperabil
Gary Edwards

LibreOffice 4.3 boosts document compatibility | InfoWorld - 0 views

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

The Document Foundation, LibreOffice and OOXML - The Document Foundation Wiki - 1 views

  • Why does LibreOffice offer to read, edit and save documents in OOXML? Just like OpenOffice.org, LibreOffice lets its users handle documents in the format used by Microsoft Office 2007 and 2010. It is important to understand that these formats, also called OOXML are in fact somewhat different from the ISO standard bearing the same name; in fact it is unclear whether anyone is able to implement the ISO standard. To avoid confusion, we will refer to the Microsoft formats produced by Microsoft Office as Microsoft Open XML (MOX) hereafter. To enable data interchange, LibreOffice and OpenOffice.org before it, has traditionally engaged with the reality of a world filled with data in many, less than ideal formats. Our users are used to exchanging data bi-directionally between many proprietary formats, and their Free Software equivalents. Indeed there are few choices for a non-dominant player to deliberately shun inter-operating, and remain relevant.
  • Don't you feel as if you are betraying Free and Open Source Software, as well as Open Standards such as ODF? No. And if we felt that way, we would take immediate action to remove the full stack. What we are offering our users is convenience; if we didn't offer these features we would not be serving users and we would get daily messages requesting the support of the new Microsoft Office formats. Besides, the same reasoning applies to the old Microsoft Office formats we support; and while it was thought for a while it was possible to prevent people from using these formats or even buying Microsoft Office, it turned out that it was not possible. We do believe, however, that by offering a full-featured and innovative office suite that exists among a rich and diverse ODF ecosystem, ODF shall prevail in the end.
Gary Edwards

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

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

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

  • 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
       
      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
  • Microsoft seeks to create sales pull along the vertical stack between the desktop and server.
    • Gary Edwards
       
      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
  • Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats.
    • Gary Edwards
       
      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
  • ...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
       
      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.


  • Microsoft got there first to protect Office.
    • Gary Edwards
       
      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
  • 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
       
      Okay, now Joe has the Micrsoft SOA bull by the horns.  Why doesn't he wrestle the monster down?
  • By adapting XML
    • Gary Edwards
       
      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
  • 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
       
      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!
  • 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
       
      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.

Gary Edwards

Compound Document Format and OpenDocument Foundation (Updated 20071109) « Cyb... - 0 views

  • The first time I heard about OpenDocument Foundation people not happy with ODF is from Stephen McGibbon post about Gary Edwards disagreement with Sun. Then comes Rob Weir’s that OpenDocument Foundation had moved away from OpenDocumentFormat. With Rob Weir post I sense some crack in OpenDocument Foundation over ODF. While Weir’s post continues its tradition of building up evidence to support his argument, he is known to be a very passionate guy about ODF and is not shy about attacking opposition, any opposition to ODF. Hence, in this respect, I believe I have to exercise a certain amount of caution when Weir start attacking someone new. Today, I came across Jason Matusow’s happy rambling about how OpenDocument Foundation is unhappy about ODF and appears to be supporting a single document format. Matusow view it as an argument that the “one document format” theory does not work. More on this later. Hmmm… Did OpenDocument Foundation change direction away from ODF? and what is this Compound Document Format (CDF) thing that seems to be the new love of OpenDocument Foundation.
Gary Edwards

IBM Wins Pyrrhic Format Battle Over Microsoft | Michael Hickins - 0 views

  •  
    Michael Hickins has an interesting angle on the document wars: ...... "By releasing a new service pack for Office that includes support for the open document format (ODF), Microsoft appears to be complying with European demands that it play well with others, while putting to rest accusations by IBM that it is still trying to maintain a monopoly over document formats. But forgive IBM for failing to cheer an apparent victory in its long-running document format war with Microsoft; IBM is busy attempting to snatch defeat from the jaws of victory, probably because it's now run out of excuses for failing to capture significant market share against Word and Excel....." I've got two comment below the article: "Hoist on our own petard"
Gary Edwards

Can Microsoft Count on Inertia to Spur Office 2010 Upgrades? | Eric Lai - CIO Article C... - 0 views

  •  
    This article left me a bit confused. The author poses an important question about the next release of MSOffice; MSOffice 2010. Or what others have called MSOffice 11. The question is whether or not end users will buy into the new features, and continue on the upgrade treadmill as they have for the past 15 years or so. Strangely though, there is no discussion of the traditional factors binding end users to the upgrade treadmill. Things like ever changing formats, protocols and interfaces. Nor is there discussion as to the impact of marketplace demands that Microsoft comply with open standards; including open document exchange formats like ODF, OOXML and HTML+ (the advanced WebKit-Ajax document model).

    The thing is, it's more than simple "inertia" that compels people to jump on the upgrade treadmill. The ODF pilot studies conducted in Massachusetts, California, Denmark and Belgium brought into sharp focus the difficulties workgroups have in replacing MSOffice. Years of client/server systems designed to run within the MSOffice productivity environment has left many a business process bound to the MSOffice suite of editors and the compound documents they produce.

    I left my response in the reader feedback section of this CIO article.

    ".....In the past, the MSOffice upgrade treadmill was unavoidable due to the file format compatibility problem. As workgroups and business divisions purchased new computers with newer versions of MSOffice, resulting file format incompatibilities made workflow exchange of documents impossibly frustrating. Eventually, entire workgroups were forced into upgrading just to keep day to day business processes working....."
Gary Edwards

Odf - Converters & the ODF Zero Interop problem - 0 views

  • The ODF-Converter translates OpenXML documents (.DOCX) to Open Document Format (.Open Document Format) (and conversely) for Open XML processing applications. You will find below the list of unsupported features which may be due to standard compatibility issues, or to the translator itself (see rendering issues as discussed in the blog)...
  •  
    Explosive compatibility - interoperability study concerning ODF and MOOXL!  This has Florian's signature written all over it, and it goes right to the heart of the matter.

    David A. Wheeler submitted a comment to the OASIS ODF TC outlining his concerns with this publication.  He suggests that a few minor changes to ODF could greatly improve compatibility - interop issues.  He also figures out that OpenOffice - ODF has more features than MSOffice - MOOXML.  Wha the doesn't ge is that it is these new and innovative features that continue to increase the difficulties of implementing ODF in real world business process workgroups!

    David also ignores the fact that the TC jus tvoted down the Novell "LIt Enhancement Proposal" which was specifically designed to address the compatibility - interop issues outlined in this odf-converter blog!  Given a choice, the ODF TC members chose the new and innovative features of the interop breaking Sun-KOffice "List Enhancement Proposal".   

    The List Enhancement Proposal discussion was so contentious and focused on personal destruction as to represent a total break down of the ODF concensus process.  There is no way that either the Foundation or Novell will ever contribute another compatibility - interop enhancement proposal given the personal assault and determined oppostion of Sun to compatibility - interoperability initiatives.

    The hard lesson the Foundation learned is that if you oppose Sun, you'll get booted out of OASIS!

    The lesson Novell learned is that they are better off working through Ecma 376 to resolve these issues that the public demands be addressed.

    Notice the last line in David's comment, "In any case, the MUCH, MUCH longer list of problems with Microsoft XML format isn't our problem." 

    During the contentious List Enhancement Proposal and the compatibility - interop related Metadata RDF/XML discussions, ODF members freque
  •  
    These are the same guys who just voted against the Novell List Enhancement Proposal that did exactly what the odf-converter blog claims needs to be done if the compatibility-interop problems are to be resolved!
Gary Edwards

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

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

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

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

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

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

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

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

Novell adds fuel to the fire in OOXML feud - News - Builder AU - 0 views

  • Microsoft has created its own proprietary document format, Office Open XML (OOXML), as a rival to the community-developed OpenDocument Format (ODF). OOXML is used in Microsoft's latest applications suite, Office 2007. Despite some efforts by the two camps, ODF and OOXML are, for the most part, not interoperable, meaning documents that are created in one format cannot be successfully read by applications based on the other format. According to Novell's vice president of developer platforms, Miguel de Icaza, the situation won't change in the foreseeable future. Want to know more? For all the latest news, analysis and opinion on open source, click here "There's no end in sight to the ongoing disputes between the two camps," said de Icaza, speaking at XML 2007, a Microsoft-sponsored event, on Tuesday. "In 2006, there was lots of FUD [fear, uncertainty and doubt] about the problems behind OOXML and it went downhill from there," Icaza said. "Neither group is willing to make the big changes required for real compatibility," de Icaza added.
    • Gary Edwards
       
      What efforts are you talking about? The last time any effort was made to accomodate interoperability was in 2003 with the establishment of the ODF "Compatibilty clause" (Section 1.5). "Despite some efforts by the two camps, ODF and OOXML are, for the most part, not interoperable, meaning documents that are created in one format cannot be successfully read by applications based on the other format......" Section 1.5 authorizes the use of "foreign elements" and "alien attributes". These techniques were specifically written into ODF for handling unknown characteristics of existing MSOffice documents (binary and/or xml) on conversion to ODF. Since the Section 1.5 addition in 2003, every other suggestion to improve interop between ODF and MSOffice documents has been rejected by the OASIS ODF TC and Sub Committees. There are three problems with Section 1.5. The first is that there is only so much that can be done with foreign elements and alien attributes. There are still remaining compatibility issues relating to the basic structures of lists, tables, fields, sections and page dymnamics. The OpenDocument Foundaiton spent over a year trying to get approval for five generic elements relating to these structures, without success. As i said, there has not been a single successful comatibility - interoperability effort since 2003, although many have been proposed. The second reason for the failure of Section 1.5 is that OpenOffice only partially implements the "Compatibility Clause". OOo only recognizes "foreign elements and alien attributes" with text spans and paragraphs. The third reason is that "compatibility" is optional in ODF. The clause does not have any teeth. Applications can implement only those aspects of the spec they feel like implementing, and still be in total "compliance". This creates serious interop problem not only for MSOffice plug-in comverted documents, but also renders as
Gary Edwards

Greg McNevin : Open Document Foundation Abandons Namesake, Closes up Shop - 0 views

  • The decision to go with CDF has left some industry commentators scratching their heads, with arstechnica.com’s Ryan Paul noting that the decision is curious as CDF doesn't support “the full range of functionality required for office compatibility”. Paul does add, however, that the formats broad use of formats such as XHTML and SVG does give it a compelling edge.
  •  
    The W3C's Chris Lilley, IBM and the lawyer for OASIS have been making quite a bit of noise claiming that CDF doesn't support "the full range of functionality required for office compatibility". 

    This a strange claim, especially when considering IBM as the primary source.  CDF WiCD Full 1.0 is a desktop profile for CDF.  Other profiles include WICD Mobile and WICD Core.  The call for implementations for WICD core, mobile and full went out on Monday, November 12, 2007. 

    To understand cdf, one must first get a handle on the terms used to describe cdf technologies.
    ..... CDF= compound document formats
    ..... CDRF= compound document by reference framework
    ..... WICD = Web Integration Compound Document
    ..... CDR using WICD = Compound Document by Reference using a WICD profile, (Core, Full or Mobile)
    ..... Compound Document by Reference Framework 1.0
    ..... WICD Core 1.0
    ..... WICD Mobile 1.0 Profile
    ..... WICD Full 1.0 Profile

    The WICD Full 1.0 Profile is the "DESKTOP" profile for CDF.
    Some interesting Quotes:

    "WICD Full 1.0 is targeted at desktop agents".

    "The WICD Full 1.0 profile is designed to enable rich multimedia content on desktop and high capability handheld agents."

    From the Compound Document by Reference Use Cases and Requirements Version 1.0 :

    "The capability to view documents with preserved formatting, layout, images and graphics and interactive features such as zooming in and out and multi-page handling."

    "
    <
Gary Edwards

Independent study advises IT planners to go OOXML | All about Microsoft | ZDNet.com - 0 views

  • “ODF represents laudable design and standards work. It’s a clean and useful design, but it’s appropriate mostly for relatively unusual scenarios in which full Microsoft Office file format fidelity isn’t a requirement. Overall, ODF addresses only a subset of what most organizations do with productivity applications today.” The report continues: “ODF is insufficient for complex real-world enterprise requirements, and it is indirectly controlled by Sun Microsystems, despite also being an ISO standard. It’s possible that IBM, Novell, and other vendors may be able to put ODF on a more customer-oriented trajectory in the future and more completely integrate it with the W3C content model, but for now ODF should be seen as more of an anti-Microsoft political statement than an objective technology selection.”
    • Gary Edwards
       
      Mary Jo takes on the recently released Burton Group Report comparing OOXML and ODF. Peter O'Kelly, one of the Burton Group authors, once famously said, "ODF is a great format if you live in an alternative universe where MSOffice doesn't exist!" This observation speaks to the core problem facing ODF and those who seek to implement the ODF standard: ODF was not designed for the conversion of MSOffice documents. Nor was ODF designed to work with MSOffice applications. Another way of saying this is to state that ODF was not designed to be interoperable with MSOffice documents, applications and bound processes. The truth is that ODF was designed for OpenOffice/StarOffice. It is an application specific format. Both OOXML and ODF do a good job of separating content from presentation (style). The problem is that the presentation - layout layers of both ODF and OOXML remains bound to specific applications producing it. While the content layers are entirely portable and can be exchanged without information loss, the presentation layers can not. Microsoft makes no bones about the application specific design and purpose of OOXML. It's stated right in the Ecma 376 charter that OOXML was designed to be compatible with MSOffice and the billions of binary documents in MSOffice specific binary formats. The situation however is much more confusing with ODF. ODF is often promoted as being application, platform and vendor independent. After five years of development though, the OASIS ODF TC has been unable to strip ODF of it's OpenOffice/StarOffice specific aspects. ODF 1.0 - ISO 26300 had three areas that were under specified; meaning these areas were described in syntax only, and lacked the full semantics demanded by interoperable implementations. Only OpenOffice and StarOffice code base applications are able to exchange documents with an acceptable fidelity. The three under specified areas of ODF are: Lists (numbered), F
Gary Edwards

OOXML/ODF: Just One Battlefield in a Much Bigger War | Linux Today - 2 views

  • If the OOXML format in its current form cannot get made into a true ISO standard, it could lock Microsoft out of any future plays in what could be the biggest IT revolution to date. Here are the pieces of the puzzle that fit together for me:
  • "Amazon SimpleDB is a web service for running queries on structured data in real time."
  • "Structured data." And what's a good way to contain such data? In well-built structured data file format of course. Like, for instance, the Open Document Format (ODF). And who has a vested interest in ODF? IBM certainly does. And so does Sun. And these two companies, along with Google, Microsoft, and I'm sure many others, realize that if cloud computing does indeed take off, then it will be the file format that makes the whole thing work. Which is why Microsoft feels it must get their format standardized. Even with tactics that ironically have started to attract the attention of the EU again. How else can they get a piece of the cloud pie?
    • Gary Edwards
       
      Partly right. The MS plan is actually much bigger than Brian Profitt suggests. The MSOffice 2007 SDK is fille dwith new API's, the most interesting of which are the ones connecting MSOffice to XAML and the Windows Presentation Foundation layer. The killer component though is the OOXML <> fixed/flow translator component with related API's. fixed/flow is a new web format that is 100% proprietary. It's at the heart of the Microsoft cloud, enabling developers to easily transition between OOXML and IE browsers able to serve fixed/flow pages to devices, desktops and just about any kind re purposing publication - content management system imaginable. If ISO approves OOXML, then they've standardized MSOffice as a legitamate Web editor - enterprise publication, content management, archive management front end. Instead of producing W3C compliant (X)HTML - CSS web pages though, the MSOffice Web editor will produce the proprietary fixed/flow format via the OOXML translation component we can now see in the SDK. What we don't see in the MSOffice SDK is the use of W3C technologies such as (X)HTML, CSS, SVG, XForms, SMiL, XSL, XSL-FO. Instead of Mozilla XUL or Adobe Flex, we find XAML and Silverlight. IMHO, Microsoft is making their run for the Web. Key to this run is ISO approval of OOXML. Once that happens, there will be no need for MS product compliance with W3C standards. The break will be complete. The We forever split into the Windows Web, and the Firefox - Apache Tomcat Web. And never the twain shall meet.
Gary Edwards

Microsoft Closer on &#0092;'Office Open&#0092;' Blessing - 0 views

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

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

The Joel on Software Discussion Group - Microsoft's ridiculous Office Open XML - 0 views

  •  
    A legthy discussion of the MSOffice bound MOOXML file format. that was triggered by Rob Weir's infamous blog, "How to Hire Guillame Portes".  Lots of comments, pro and con, as to whether or not the applications specific tags used so extensibvely by MOOXML are needed, or not.

    Many argue that the application bound tags should have been fully described.  That every tag in the specification should also include the informaiton needed to implement it.  Agreed!  Otherwise, the specification does not qualify as a standard.  It's simply a vendor specific, and in this case highly proprietary and encumbered file format.

    Others argue that the app bound tags are the only way for Microsoft to provide backwards compatibility with the billions of binary documents bound to MSOffice through proprieatry and secret binary file formats.  These people argue that embedding an application specific binary in the XML file format, instead of converting it to proper XML, is the only way to insure backwards compatibilty.  BS.  There is no technical reason not to convert it to proper XML.  But that would mean fully describing the binary objects, including the nature of their application dependency.  Something Microsoft is quite reluctant to do.

    The truth of the matter is that if the binary object is to be part of a specification submitted to ISO for standards consideration, then it should be fully described, including how to implement it.  Otherwise, MOOXML is just a standard for one.  A standard for Micrsoft only since they are  the only ones with the secret blueprint as to how to implement these binary objects.

  • ...1 more comment...
  •  
    A legthy discussion of the MSOffice bound MOOXML file format. that was triggered by Rob Weir's infamous blog, "How to Hire Guillame Portes". Lots of comments, pro and con
  •  
    A legthy discussion of the MSOffice bound MOOXML file format. that was triggered by Rob Weir's infamous blog, "How to Hire Guillame Portes". Lots of comments, pro and con
  •  
    A legthy discussion of the MSOffice bound MOOXML file format. that was triggered by Rob Weir's infamous blog, "How to Hire Guillame Portes". Lots of comments, pro and con
Gary Edwards

We Can No Longer Unbundle Microsoft Office - 0 views

  • In 2007, productivity reached the cloud when the EU forced Microsoft&nbsp;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&nbsp;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&nbsp;CEO Milind Gadekar&nbsp;started using OpenXML formats to bring Microsoft Office to iPad. Since then, the company opened its&nbsp;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&nbsp;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&nbsp;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&nbsp;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 - 40 of 253 Next › Last »
Showing 20 items per page