Skip to main content

Home/ OpenDocument/ Group items tagged saas

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Gary Edwards

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

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

cdf html odf officeopenxml ooxml opendocument

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

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

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

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

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

CIO Wakeup Call: Burton Group ODF/OOXML report | The CIO Weblog - 0 views

www.cio-weblog.com/...rton_group_odfooxml_report.php

burtongorup cdf cio css ny odf okelly ooxml w3c xhtml

shared by Gary Edwards on 20 Jan 08 - Cached
  • Although most of the ruckus over the paper has focused on the prediction that OOXML will beat out ODF, the more intriguing and meaningful conclusion is in fact that the World Wide Web Consortium (W3C) model, built on open and broadly accepted web standards already in broad use, will in fact "...be more influential and pervasive than ODF and OOXML." This implicit acknowledgment that the SaaS delivery model will dominate productivity and document storage applications is less supportive of Microsoft's approaches than many of the documents detractors care to acknowledge and suggests the entire debate is essentially a sideshow.
  • CIOs who are truly concerned with data preservation and open standards need to take a hard look at Microsoft's historical business practices and the remaining questions hanging over OOXML and ask themselves if it's worth making such a major transition to a format that is fraught with the same potential for vendor (rather than consumer) control in the future. SaaS options, it's worth noting, hardly escape this issue, so regardless of the very real potential that SaaS will eclipse any of the stand-alone office applications that are currently involved in this debate, it's still going to be necessary to pick a format for long-term, corporate control of vital data and documents.
Gary Edwards

Has Microsoft lost its way on desktop computing? | The Apple Core | ZDNet.com - 0 views

blogs.zdnet.com/Apple

msoffice ooxml saas soa xaml

shared by Gary Edwards on 07 Apr 08 - Cached
  • OM MALIK: You outlined Microsoft’s software-plus-services strategy, but what I want to know about is the changing role of the desktop in this service’s future. RAY OZZIE: I think the real question is (that) if you were going to design an OS today, what would it look like? The OS that we’re using today is kind of in the model of a ’70s or ’80s vintage workstation. It was designed for a LAN, it’s got this great display, and a mouse, and all this stuff, but it’s not inherently designed for the Internet. The Internet is this resource in the back end that you can design things to take advantage of. You can use it to synchronize stuff, and communicate stuff amongst these devices at the edge. A student today or a web startup, they don’t actually start at the desktop. They start at the web, they start building web solutions, and immediately deploy that to a browser. So from that perspective, what programming models can I give these folks that they can extend that functionality out to the edge? In the cases where they want mobility, where they want a rich dynamic experience as a piece of their solution, how can I make it incremental for them to extend those things, as opposed to learning the desktop world from scratch?
  • Gary Edwards on 07 Apr 08
     
    ZDNet's David Morgenstern must have missed ISO approval of OOXML! MS has a desktop strategy, but involves proprietary protocols, formats and API's as the protective barrier for transitioning desktop bound client/server business processes to MS Web Stack bound SaaS-SOA business processes. Welcome to the Microsoft Cloud!
Gary Edwards

Slamming the door shut on MS OOXML - 0 views

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

cdf interoperability iso odf odf-tc officeopenxml ooxml opendocument xml

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

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

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

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

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

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

    It's a devastating argument.

Gary Edwards

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

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

cloud-computing collaborative-computing paas saas soa woa

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

okay ... seriously now ... what is this supposed to be? - 229 views

Gary Thank you for the insightful (and exhaustive) overview. Question. Would you allow me to publish all or part of your response on my practice management blog at http://dcbalpm.wordpress.com? Or...

OpenDocument

started by mazyar hedayat on 01 Sep 07 3 follow-ups, last by Gary Edwards on 16 Apr 08
Gary Edwards

Bringing Open Source to SOAs - 0 views

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

apache eclipse opensource oss soa

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

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

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

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

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

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

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

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

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

ODF Civil War: Bulll Run - Suggested Changes on the Metadata proposal - OASIS ODF - 0 views

www.oasis-open.org/...msg00072.html

metadata odf odf-civil-war ooxml

shared by Gary Edwards on 11 Oct 07 - Cached
  • From our perspective it would be better to aim for doing the job in ODF 1.2, even if that requires delay. We will oppose ODF 1.2 at ISO unless the interoperability warts are cleaned up. What the market requires is no longer in doubt. See the slides linked above and further presentations linked from this page, &lt; http://ec.europa.eu/idabc/en/document/6474/5935&gt;. Substantial progress toward those goals would seem to be mandatory to maintain Europe's preference for a harmonized set of file formats that uses ODF to provide the common functionality. Delaying commencement of such work enhances the likelihood that governments will tire of waiting for ODF to become interoperable with MS Office and simply go with MOOXML. We may not be able to force Microsoft to participate in the harmonization work, but we will be in a far better position if we have done everything we can in aid of that interoperability without Microsoft's assistance. As the situation stands, we have what is known in the U.S. as a "Mexican stand-off," where neither side has taken a solitary step toward what Europe has requested. We have decided to do that work via a fork of ODF; it is up to this TC whether it wishes to cooperate in that effort.
  • Gary Edwards on 11 Oct 07
     
    This is the famous marbux response to Sun regarding Sun's attempt to partially implement ODF 1.2 XML-RDF metadata.  It's a treasure.

    There is one problem with marbux's statement though.  We had decided long ago not to fork ODF even if the five iX "interoperability enhancement" proposals were refused by the OASIS ODF TC.   This assurance was provided to Massachusetts CIO Louis Gutierrez witht he the first ODF iX proposal submitted on July 12th, 2006.  Louis ended up signing off on three iX proposals before his resignation October 4th, 2006.

    The ODF iX enhancements were essential to saving ODF in Massachusetts.  Without them, there was no way our da Vinci plug-in could convert existing MSOffice documents and processes to ODF with the needed round trip fidelity.

    For nearly a year we tried to push through some semblance of the needed iX enhancements.  We also tried to push through a much needed Interoperability Framework, which will be critical to any ISO approval of ODF 1.2.

    Our critics are correct in that every iX effort was defeated, with Sun providing the primary opposition. 

    Still rather than fork ODF, we are simply going to move on. 

    On October 4th, 2006, all work on ODF da Vinci ended - not to be resumed unless and until we had the ODF iX enhancements we needed to crack the MSOffice bound workgroup-workflow business process barrier.

    In April of 2007, with our OASIS membership officially shredded by OASIS management, bleeding from the List Enhancement Proposal doonybrook, and totally defeated with our hope - the metadata XML-RDF work, we threw in the towel.

    Since then we've moved on to CDF, the W3C Compound Document format.  Incredibly, CDF is able to do what ODF can not.  With CDF we can solve the three primary problems confronting governments and MSOffice bound workgroups everywhere. 

    The challenge for these g
Gary Edwards

ODF and OOXML - The Final Act - 0 views

www.idm.net.au/story.asp

din fraunhofer harmonization iso odf ooxml opendocument openxml

shared by Gary Edwards on 04 Feb 08 - Cached
  • 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
      Gary Edwards on 04 Feb 08
       
      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
      Gary Edwards on 04 Feb 08
       
      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
      Gary Edwards on 04 Feb 08
       
      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.
  • Gary Edwards on 04 Feb 08
     
    Correcto mundo! There should be only one standard to maximise interoeprability and functionality. But ODF is application specific to the way OpenOffice works. It was not designed from a clean slate. Nor was the original 2002 OpenOffice XML spec designed as an open source effort! Check the OOo source code if you doubt this claim. The ONLY contributors to Open Office XML were Sun employees! What the world needs is in fact a format standard designed to maximise interoperability and functionality. This requires a total application-platofrm-vendor independence that neither ODF or OOXML can claim. The only format that meets these requirements is the W3C's family of HTML-XML formats. These include advancing Compound Docuemnt Framework format components such as (X)HTML-5, CSS-3, XForms, SVG and SMiL.. The W3C's CDF does in fact meet the markeplace needs of a universal format that is open, unencumbered and totally application, platform and vendor independent. The only trick left for CDF is proving that legacy desktop applications can actually implement conversions from existing in-memory-binary-representations to CDF without loss of information.
Gary Edwards

» Government turns to SaaS to salvage IT failures | IT Project Failures | ZDN... - 0 views

blogs.zdnet.com/projectfailures

shared by Gary Edwards on 25 Jan 08 - Cached
  • As Administrator of E-Government and Information Technology, for the Office of Management and Budget, Evans oversees the government’s CIO Council, comprised of Chief Information Officers from various agencies. In September, 2007, she testified before the Senate, about high-risk IT projects:
Gary Edwards

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

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

carr office office20 web

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

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

www.internetnews.com/...3662681

ecma exchange iso microsoft msoffice oasis odf ooxml opendocument openxml sharepoint vista xml

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

ODF versus OOXML: Don't forget about HTML! - O'Reilly XML Blog - 1 views

www.oreillynet.com/...ersus_ooxml_dont_forget_a.html

iso microsoft msoffice oasis odf ooxml opendocument openxml xml

shared by Gary Edwards on 06 Mar 07 - Cached
  • But Lie is right, I think, to be alarmed by the prospect that if OOXMLfails MS will revert away from open formats. I don’t see them adopting ODF as the default format for general sale. for a start, current ODF simply does not have matching capabilities. This issue of fit is strong enough that we don’t even need to get to the issue of control. We have this nice little window now where MS is inclined to open up its formats, something that the document processing community has been pleading for for years. The ODF sideshow runs the risk of screwing this up; I’ve said it before, but I say it again: being pro-ODF does not mean you have have to be anti-OOXML. ODF has not been designed to be a satisfactory dump format for MS Office; OOXMLhas not been designed to be a suitable format for Sun’s Star Office or Open Office or IBM’s products. HTML is the format ｏｆ choice for interchange of simple documents; ODF will evolve to be the format of choice for more complicated documents; OOXML is the format of choice for full-fidelity dumps from MS Office; PDF is the format of choice for non-editable page-faithful documents; all of them are good candidates for standardization, all have overlap but are worthwhile to have as cards in the deck of standards. But systems for custom markup trumps all.
  • Gary Edwards on 06 Mar 07
     
    Famed Microsoft WikiPedia editor Rick Jellife takes on the HTML-CSS proposal put forth by Opera Browser CTO Håkon Wium Lie's in his recent CNET column.

    Rick claims that the Opera proposal is "solid in its ultimate premise .... that inspite of .. all the talk about ODF and OOXML, it is important not to lose track of HTML's potential and actual suitability for much document interchange.

    Good discussion except that MS Rick can't help himself when it comes to the tired moral equivocation argument that the world can and should accept and use two ISO/IEC desktop productivity environment file format standards, ODF and OOXML.  Once again he puts forward the claim that ODF is OPenOffice specific and OOXML is MSOffice specific - each having it's place and value as an international standard.

    Are we standardizing applications here?  I thought it was about creating a universal XML file format that all application can use::  One file format  for OpenOffice, MSOffice, KOffice, Writer, WordPerfect Office, Novell Office, GNOME Office, and even the Flash-Apollo based " Virtual Ubiquity " from Rick Treitman.

    ODF does need to provide the marketplace with at least three profiles; desktop productivity environments, server side portal publication-content-archive management systems, and devices.  This would greatly improve interoperability as ODF documents transition across desktops, servers, devices and Internet information domains.  It would also help the implementation of ODF by SOA, SaaS and Web 2.0 systems.

    But having two file formats that irreconcilably incompatible servicing the exact same market categories?  Doesn't make sense.  And can only end in massive end user confusion where the application with dominant marketshare end up crushing any and all competitive alternative
Gary Edwards

The better Office alternative: SoftMaker Office bests OpenOffice.org ( - Soft... - 1 views

news.idg.no/...art.cfm

shared by Gary Edwards on 30 Jun 09 - Cached
  • Frankly, from Microsoft's perspective, the danger may have been overstated. Though the free open source crowd talks a good fight, the truth is that they keep missing the real target. Instead of investing in new features that nobody will use, the team behind OpenOffice should take a page from the SoftMaker playbook and focus on interoperability first. Until OpenOffice works out its import/export filter issues, it'll never be taken seriously as a Microsoft alternative. More troubling (for Microsoft) is the challenge from the SoftMaker camp. These folks have gotten the file-format compatibility issue licked, and this gives them the freedom to focus on building out their product's already respectable feature set. I wouldn't be surprised if SoftMaker got gobbled up by a major enterprise player in the near, thus creating a viable third&nbsp;way for IT shops seeking to kick the Redmond habit.
    • Gary Edwards
      Gary Edwards on 30 Jun 09
       
      This quote is an excerpt from the article :)
  • Gary Edwards on 30 Jun 09
     
    Finally! Someone who gets it. For an office suite to be considered as an alternative to MSOffice, it must be designed with multiple levels of compatibility. It's not just that the "feature sets" that must be comparable. The guts of the suite must be compatible at both the file format level, and the environment level. Randall put's it this way; "It's the ecosystem stupid". The reason ODF failed in Massachusetts is that neither OpenOffice nor OpenOffice ODF are designed to be compatible with legacy and existing MSOffice applications, binary formats, and, the MSOffice productivity environment. Instead, OOo and OOo-ODF are designed to be competitively comparable. As an alternative to MSOffice, OpenOffice and OpenOffice ODF cannot fit into existing MSOffice workgroups and producitivity environments. Because it s was not designed to be compatible, OOo demands that the environment be replaced, rebuilt and re-engineered. Making OOo and OOo-ODF costly and disruptive to critical day-to-day business processes. The lesson of Massachusetts is simple; compatibility matters. Conversion of workgroup/workflow documents from the MSOffice productivity environment to OpenOffice ODF will break those documents at two levels: fidelity and embedded "ecosystem" logic. Fidelity is what most end-users point to since that's the aspect of the document conversion they can see. However, it's what they can't see that is the show stopper. The hidden side of workgroup/workflow documents is embedded logic that includes scripts, macros, formulas, OLE, data bindings, security settings, application specific settings, and productivity environment settings. Breaks these aspects of the document, and you stop important business processes bound to the MSOffice productivity environment. There is no such thing as an OpenOffice productivity environment designed to be a compatible alternative to the MSOffice productivity environment. Another lesson from Massach
1 - 14 of 14
Showing 20▼ items per page