Skip to main content

Home/ OpenDocument/ Group items tagged custom XML

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Gary Edwards

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

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

iso oasis odf officeopenxml ooxml opendocument xml

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

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

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

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

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

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

odef odf officeopenxml ooxml opendocument vista-stack

shared by Gary Edwards on 13 Jul 07 - Cached
  • To be fair, Microsoft seeks to solve real world problems with respect to helping customers glean more value from their information. But the approach depends on enterprises adopting an end-to-end Microsoft stack—vertically from desktop to server and horizontally across desktop and server products. The development glue is .NET Framework, while the informational glue is OOXML.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      OOXML is the transport - a portable XML document model where the "document" is the interface into content/data/ and media streaming.

      The binding model for OOXML is "Smart Documents", and it is proprietary!

      Smart Documents is how data, streaming media, scripting-routing-workflow intelligence and metadata is added to any document object.

      Think of the ODF binding model using XForms, XML/RDF and RDFA metadata. One could even use Jabber XMP as a binding model, which is how we did the Comcast SOA based Sales and Inventory Management System prototype.

      Interestingly, Smart Documents is based on pre written widgets that can simply be dragged, dropped and bound to any document object. The Infopath applicaiton provides a highly visual means for end users to build intelligent self routing forms. But Visual Studio .NET, which was released with MSOffice 2007 in December of 2006. makes it very easy for application and line of business integration developers to implement very advanced data binding using the Smart Document widgets.

      I would also go as far to say that what separates MSOOXML from Ecma 376 is going to be primarily Smart Documents.

       Yes, there are .NET Framework Libraries and Vista Stack dependencies like XAML that will also provide a proprietary "Vista Stack" only barrier to interoperability, but Smart Documents is a killer.

      One company that will be particularly hurt by Smart Documents is Google. The reason is that the business value of Google Search is based on using advanced and closely held proprietary algorithms to provide metadata structure for unstrucutred documents.

      This was great for a world awash in unstructured documents. By moving the "XML" structuring of documents down to the author - workgroup - workflow application level though, the world will soon enough be awash in highly structured documents that have end user metadata defining document objects and
  • Microsoft seeks to create sales pull along the vertical stack between the desktop and server.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      The vertical stack is actually desktop - server - device - web based.  The idea of a portable XML document is that it must be able to transition across the converged application space of this sweeping stack model.

      Note that ODF is intentionally limited to the desktop by it's OASIS Charter statement.  One of the primary failings of ODF is that it is not able to be fully implemented in this converged space.  OOXML on the other hand was created exactly for this purpose!

      So ODF is limited to the desktop, and remains tightly bound to OpenOffice feature sets.  OOXML differs in that it is tightly bound to the Vista Stack.

      So where is an Open Stack model to turn to?

      Good question, and one that will come to haunt us for years to come.  Because ODF cannot move into the converged space of desktop to server to device to the web information systems connected through portable docuemnt/data transport, it is unfit as a candidate for Universal File Format.

      OOXML is unfi as a UFF becuase it is application - platform and vendor bound.

      For those of us who believe in an open and unencumbered universal file format, it's back to the drawing board.

      XHTML (XHTML CSS3 RDF) is looking very good.  The challenge is proving that we can build plugins for MSOffice and OpenOffice that can fully implement XHTML .  Can we conver the billions of binary legacy documents and existing MSOffice bound business processes to XHTML ?

      I think so.  But we can't be sure until the da Vinci proves this conclusively.

      One thign to keep in mind though.  The internal plugins have already shown that it is possible to do multiple file formats.  OOXML, ODF, and XML encoded RTF all have been shown to work, and do so with a level of two way conversion fidelity demanded by existing business processes.

      So why not try it with XHTML , or ODEF (the eXtended version of ODF en
  • Microsoft's major XML-based format development priority was backward compatibility with its proprietary Office binary file formats.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      This backwards compatibility with the existing binary file formats isn't the big deal Micrsoft makes it out to be.  ODF 1.0 includes a "Conformance Clause", (Section 1.5) that was designed and included in the specification exactly so that the billions of binary legacy documents could be converted into ODF XML.

      The problem with the ODF Conformance Clause is that the leading ODF application, OpenOffice,  does not fully support and implement the Conformance Clause. 

      The only foreign elements supported by OpenOffice are paragraphs and text spans.  Critically important structural document characteristics such as lists, fields, tables, sections and page breaks are not supported!

      This leads to a serious drop in conversion fidelity wherever MS binaries are converted to OpenOffice ODF.

      Note that OpenOffice ODF is very different from MSOffice ODF, as implemented by internal conversion plugins like da Vinci.  KOffice ODF and Googel Docs ODF are all different ODF implementations.  Because there are so many different ways to implement ODF, and still have "conforming" ODF documents, there is much truth to the statement that ODF has zero interoperabiltiy.

      It's also true that OOXML has optional implementation areas.  With ODF we call these "optional" implementation areas "interoperabiltiy break points" because this is exactly where the document exchange  presentation fidelity breaks down, leaving the dominant market ODF applicaiton as the only means of sustaining interoperabiltiy.

      With OOXML, the entire Vista Stack - Win32 dependency layer is "optional".  No doubt, all MSOffice - Exchange/SharePoint Hub applications will implement the full sweep of proprietary dependencies.    This includes the legacy Win32 API dependencies (like VML, EMF, EMF ), and the emerging Vista Stack dependencies that include Smart Documents, XAML, .NET 3.0 Libraries, and DrawingML.

      MSOffice 2007 i
  • ...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
      Gary Edwards on 15 Jul 07
       
      True, but a tricky statement given that the proprietary OOXML implementation is "optional".  It is theoretically possible to implement Ecma 376 without the prorpietary dependencies of MSOffice - Exchange/SharePoint Hub - Vista Stack "OOXML".

      In fact, this was first demonstrated by the legendary document processing - plugin architecture expert, Florian Reuter.

      Florian has the unique distinction of being the primary architect for two major plugins: the da Vinci ODF plugin for MSOffice, and, the Novell OOXML Translator plugin for OpenOffice!

      It is the Novell OOXML Translator Plugin for OpenOffice that first demonstrated that Ecma 376 could be cleanly implemented without the MSOffice application-platform-vendor specific dependencies we find in every MSOffice OOXML document.

      So while Joe is technically correct here, that OOXML is neither open nor XML, there is a caveat.  For 95% of all desktops and near 100% of all desktops in a workgroup, Joe's statment holds true.  For all practical concerns, that's enough.  For Microsoft's vaunted marketing spin machine though, they will make it sound as though OOXML is actually open and application-platform-vendor independent.


  • Microsoft got there first to protect Office.
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      No. I disagree. Microsoft needs to move to XML structured documents regardless of what others are doing. The binary document model is simply unable to be useful to any desktop- to server- to device- to the web- transport!

      Many wonder what Microsoft's SOA strategy is. Well, it's this: the Vista Stack based on OOXML-Smart Documents-.NET.

      The thing is, Microsoft could not afford to market a SOA solution until all the proprietary solutions of the Vista Stack were in place.

      The Vista Stack looks like this:

      ..... The core :: MSOffice <> OOXML <> IE <> The Exchange/SharePoint Hub

      ..... The services :: E/S HUb <> MS SQL Server <> MS Dynamics <> MS Live <> MS Active Directory Server <> MSOffice RC Front End

      The key to the stack is the OOXML-Smart Documents capture of EXISTING MSOffice bound business processes and documents.

      The trick for Microsoft is to migrate these existing business processes and documents to the E/S Hub where line of business developers can re engineer aging desktop LOB apps.

      The productivity gains that can be had through this migration to the E/S Hub are extraordinary.

      A little over a year ago an E/S Hub verticle market application called "Agent Achieve" came out for the real estate industry. AA competed against a legacy of twenty years of contact management based - MLS data connected desktop shrinkware applications. (MLS-Multiple Listing Service)

      These traditional desktop client/server productivity apps defined the real estate business process as far as it could be said to be "digital".  For the most part, the real estate transaction industry remains a paper driven process. The desktop stuff was only useful for managing clients and lead prospecting. No one could crack the electronic documents - electonic business transaction model.  This will no doubt change with the emer
  • By adapting XML
    • Gary Edwards
      Gary Edwards on 15 Jul 07
       
      The requirements of these E/S Hub systems are XP, XP MSOffice 2003 Professional, Exchange Server with OWL (Outlook on the Web) , SharePoint Server, Active Directory Server, and at least four MS SQL Servers!

      In Arpil of 2006, Microsoft issued a harsh and sudden End-of-Life for all Windows 2000 - MSOffice 2000 systems in the real estate industry (although many industries were similarly impacted). What happened is that on a Friday afternoon, just prior to a big open house weekend, Microsoft issued a security patch for all Exchange systems. Once the patch was installed, end users needed IE 7.0 to connect to the Exchange Server Systems.

      Since there is no IE 7.0 made for Windows 2000, those users relying on E/S Hub applications, which was the entire industry, suddenly found themselves disconnected and near out of business.

      Amazingly, not a single user complained! Rather than getting pissed at Microsoft for the sudden and very disruptive EOL, the real estate users simply ran out to buy new XP-MSOffice 2003 systems. It was all done under the rational that to be competitive, you have to keep up with technology systems.

      Amazing. But it also goes to show how powerfully productive the E/S Hub applications can be. This wouldn't have happened if the E/S Hub applications didn't have a very high productivity value.

      When we visited Massachusetts in June of 2006, to demonstrate and test the da Vinci ODF plugin for MSOffice, we found them purchasing en mass E/S Hubs! These are ODF killers! Yet Microsoft sales people had convinced Massachusetts ITD that Exchange/SahrePoint was a simple to use eMail-calendar-portal system. Not a threat to anyone!

      The truth is that in the E/S Hub ecosystem, OOXML is THE TRANSPORT. ODF is a poor, second class attachment of no use at the application - document processing chain level.

      Even if Massachusetts had mandated ODF, they were only one E/S Hub Court Doc
  • 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
      Gary Edwards on 15 Jul 07
       
      Okay, now Joe has the Micrsoft SOA bull by the horns.  Why doesn't he wrestle the monster down?
  • 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
      Gary Edwards on 15 Jul 07
       
      Finally, someone who understands the grand strategy of levergaing the desktop monopoly into the converged space of server, device and web information systems.

      What Joe isn't watching is the way the Exchange/SharePoint Server connects to MS SQL Server, Active Directory Server, MS LIve and MS Dynamics.

      Also, Joe does not see the connection between OOXML as the portable XML document/data transport, and the insidiously proprietary Smart Documents metadata - data binding system that totally separates MSOOXML from Ecma 376 OOXML!
  • 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
      Gary Edwards on 15 Jul 07
       
      Yes, but the new platform for busines process development is that of MSOffice <> Exchange/SharePoint Hub.

      The OOXML-Smart Docs transport replaces the old binary document with OLE and VBA Scripts and Macros functionality.  Which, for the sake of brevity we can call the lead Win32 API dependencies.

      One substantial difference is that OOXML-Smart Docs is Vista Stack ready, while the Win32 API dependencies were desktop bound.

      Another way of looking at this is to see that the old MSOffice platform was great for desktop application integration.  As long as the complete Win32 API was available (Windows MSOffice VBA run times), this platform was great for workgroups.  The Line of Business integrated apps were among the most brittle of all client/server efforts, bu they were the best for that generation.

      The Internet offers everyone a new way of integrating data, content and streaming media.  Web applications are capable of loosly coupled serving and consuming of other application services.  Back end systems can serve up data in a number of ways: web services as SOAP, web services as AJAX/REST, or XML data streams as in HTTPXMLRequest or Jabber P2P model.

      On the web services consumption side, it looks like AJAX/REST will be the block buster choice, if the governance and security issues can be managed.

      Into this SOA mash Microsoft will push with a sweeping integrated stack model.  Since the Smart Docs part of the OOXML-Samrt Docs transport equation is totally proprietary, but used throughout the Vista Stack, it will provide Microsoft with an effective customer lockin - OSS lockout point.

  • Gary Edwards on 15 Jul 07
     
    Great article series from eWeek.  A must read.  But it all comes down to interoperability across two stack models:  The Microsoft Vista Stack, and an alternative Open Stack model that does not yet exist!

    Incompatible formats become a nightmare for the kind of integration any kind of SOA implementation depends on, let alone the Web 2.0 AJAX MashUps this article focuses on.

    I wonder why eWEEK didn't include the Joe Wilcox Micrsoft Watch Article, "Obla De OBA Da".  Joe hit hard on the connection between OOXML and the Vista Stack.  He missed the implications this will have on MS SOA solutions.  Open Source SOA solutions will be locked out of the Vista Stack.  And with 98% or more of existing desktop business processes bound to MSOffice, the transition of these business processes to the Vista Stack will no doubt have a dramatic impact on the marketplace.  Before the year is out, we'll see Redmond let loose with a torrent of MS SOA solutions.  The only reason they've held back is that they need to first have all the Vista Stack pieces in place.

    I don't think Microsoft is being held back by OOXML approval at ISO either.  ISO approval might have made a difference in Europe in 2006, but even there, the EU IDABC has dropped the ISO requirement.  For sure ISO approval means nothing in the US, as California and Massachusetts have demonstrated. 

    All that matters to State CIO's is that they can migrate exisiting docuemnts and business processes to XML.  The only question is, "Which XML?  OOXML, ODF or XHTML+".

    The high fidelity conversion ratio and non disruptive OOXML plugin for MSOffice has certainly provided OOXML with the edge in this process. <br
Gary Edwards

Tim Anderson's ITWriting - Tech writing blog » Microsoft's Jean Paoli on the ... - 0 views

www.itwriting.com/blog

microsoft mooxml odf paoli

shared by Gary Edwards on 24 Apr 07 - Cached
  • What’s distinctive about the goals of OOXML? Primarily, to have full fidelity with pre-existing binary documents created in Microsoft Office. “What people want is to make sure that their billions of important documents can be saved in a format where they don’t lose any information. As a design goal, we said that those formats have to represent all the information that enables high-fidelity migration from the binary formats”, says Paoli. He mentions work with institutions including the British Library and the US Library of Congress, concerned to preserve the information in their electronic archive. I asked Paoli if such users could get equally good fidelity by converting their documents to ODF. “Absolutely not,” he says. “I am very clear on that. Those two formats are done for different reasons.” What can go wrong? Paoli gives as an example the myriad ways borders can be drawn round tables in Microsoft Office and all its legacy versions. “There are 100 ways to draw the lines around a table,” he says. “The Open XML format has them all, but ODF which has not been designed for backward compatibility, does not have them. It’s really the tip of the iceberg. So if someone translates a binary document with a table to ODF, you will lose the framing details. That is just a very small example.”
  • “Open Document Format and Office Open XML have very different goals”, says Paoli, responding to the claim that the world needs only one standard XML format for office documents. “Both of them are formats for documents … both are good.”
    • Gary Edwards
      Gary Edwards on 19 Aug 07
       
      The door should have been slammed shut on OOXML near five years ago when, on December 14th, 2006, at the very first OASIS ODF TC meeting, Stellent's Phil Boutros proposed that the charter include, "compatibility with existing file formats and interoperability with existing applications" as a priority objective.
  • Another benefit Paoli claims for OOXML is performance. “A lot of things are designed differently because we believe it will work faster. The spreadsheet format has been designed for very big spreadsheets because we know our users, especially in the finance industry, use very large spreadsheets.
    • Gary Edwards
      Gary Edwards on 19 Aug 07
       
      Wrong. The da Vinci plug-in prototype we demonstrated to Massachusetts on June 19th, 2006 proved that there is little or no difference in spreadsheet performance between a OOXML file, and an ODF file.

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

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

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

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

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

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

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

      Point taken.

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

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

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

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

      Watch out Google!

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

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

      ~ge~
  • I put it to Paoli that OOXML is hard to implement because of all its legacy support, some of which is currently not well documented. “I don’t believe that at all. It’s actually the opposite,” he says. He make the point that third parties like Corel, which have previously implemented support for binary formats like .doc and .xls, should find it easy to transition to OOXML. “We believe Open XML adoption by vendors like Corel will be very easy because they have already been doing 90% of the work, doing the binary formats. The features are already there.”
    • Gary Edwards
      Gary Edwards on 20 Aug 07
       
      WordPerfect does an excellent import of MSWord .doc documents. But there is no conversion! It's a read only rendering. Once you start editing the document in WP, all kinds of funny things happen, and the perfect fidelity melts away like the wicked witch of west in a bucket full of water.
  • Gary Edwards on 24 Apr 07
     
    Tim Anderson interviews Microsoft's Jean Paoli about MOOXML and ODF.    Jean Paoli of course has the predictable set of answers.  But Tim anderson provides us with some interesting insights and comments of his own.  There is also a gem of a comment from Stephane Rodriquez, the reknown spreadsheet expert.

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

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

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

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

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

    Now i will admit that this is one very difficult issue to understand.  If not f
  • Gary Edwards on 20 Aug 07
     
    Great interview. Tim can obviously run circles around poor Jean Paoli.
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

XML.com: Standard Data Vocabularies Unquestionably Harmful - 0 views

www.xml.com/...perry.html

odf ooxml presentation semantics xml

shared by Gary Edwards on 21 Jan 08 - Cached
  • At the onset of XML four long years ago, I commenced a jeremiad against Standard Data Vocabularies (SDVs), to little effect. Almost immediately after the light bulb moment -- you mean, I can get all the cool benefits of web in HTML and create my own tags? I can call the price of my crullers &lt;PricePerCruller&gt;, right beside beside &lt;PricePerDonutHole&gt; in my menu? -- new users realized the problem: a browser knows how to display a heading marked as &lt;h1&gt; bigger and more prominently than a lowlier &lt;h3&gt;. Yet there are no standard display expectations or semantics for the XML tags which users themselves create. That there is no specific display for &lt;Cruller&gt; and, especially, not as distinct from &lt;DonutHole&gt; has been readily understood to demonstrate the separation of data structure expressed in XML from its display, which requires the application of styling to accomodate the fixed expectations of the browser. What has not been so readily accepted is that there should not be a standard expectation for how a data element, as identified by its markup, should be processed by programs doing something other than simple display.
    • Gary Edwards
      Gary Edwards on 21 Jan 08
       
      ODF and OOXML are contending to become the Standard Data Vocabulary for desktop office suite XML markup. Sun and Microsoft are proposing the standardization of OpenOffice and MSOffice custom defined XML tags for which there are no standard display expectations. The display expectations must therefore be very carefully described: i.e. the semantics of display fully provided.
      In this article Walter Perry is pointing out the dangers of SDV's being standardized for specific purposes without also having well thought out and fully specified display semantics. In ODF - OOXML speak, we would call display presentation, or layout, or "styles".
      The separation of content and presentation layer of each is woefully underspecified!
      Given that the presnetation layers of both ODF and OOXML is directly related to how OpenOffice and MSOffice layout engines work, the semantics of display become even more important. For MSOffice to implement an "interoperable" version of OpenOffice ODF, MSOffice must be able to mimic the OpenOffice layout engine methods. Methods which are of course quite differeent from the internal layout model of MSOffice. This differential results in a break down of conversion fidelity, And therein lies the core of the ODF interoeprability dilemma!
  • There have also emerged a few "horizontal" data vocabularies, intended for expressing business communication in more general terms. One of these is the eXtensible Business Reporting Language (XBRL), about which more below. Most recently, governments and governmental organizations have begun to suggest and eventually mandate particular SDVs for required filings, a development which expands what troubles me about these vocabularies by an order of magnitude.
  • ...5 more annotations...
    • Gary Edwards
      Gary Edwards on 21 Jan 08
       
      Exactly! When governments mandate a specific SDV, they also are mandating inherent concepts and methods unique to the provider of the SDV. In the case of ODF and OOXML, where the presentation layers are application specific and woefully underspecified, interoperability becomes an insurmountable challenge. Interop remains stubbornly application bound.
      Furthermore, there is no way to "harmonize" or "map" from one format to another without somehow resolving the application specific presentation differences.
    • Gary Edwards
      Gary Edwards on 21 Jan 08
       
      "in the nature of the SDV's themselves is the problem of misstatement, of misdirection of naive interpretation, and potential for fraud.
      Semantics matter! The presentation apsects of a document are just as important as the content.
    • Gary Edwards
      Gary Edwards on 21 Jan 08
       
      Walter: "I have argued for years that, on the basis of their mechanism for elaborating semantics, SDVs are inherently unreliable for the transmission or repository of information. They become geometrically less reliable when the types or roles of either the sources or consumers of that information increase, ending at a nightmarish worst case of a third-order diminution of the reliability of information. And what is the means by which SDVs convey meaning? By simple assertion against the expected semantic interpretations hard-coded into a process consuming the data in question.
      At this point in the article i'm hopign Walter has a solution. How do we demand, insist and then verify that SDV's have fully specifed the semantics, and not jus tpassed along the syntax?
      With ODF and OOXML, this is the core of the interoperability problem. Yet, there really is no way to separate the presentation layers from the uniquely different OpenOffice and MSOffice layout engine models.
    • Gary Edwards
      Gary Edwards on 21 Jan 08
       
      Interesting concept here: "the bulk of expertise is in understanding the detail of connections between data and the processes which produced it or must consume it ........ it is these expert connections which SDV's are intended to sever.
      Not quite sure what to make of that statement? When an SDV is standardized by ISO, the expectation is that the connections between data and processes would be fully understood, and implementations consistent across the board.
      Sadly, ODF is ISO approved, but doesn't come close to meeting these expectations. ODF interop might as well be ZERO. And the only way to fix it is to go into the presentation layer of ODF, strip out all the application specific bindings, and fully specifiy the ssemantics of layout.
  • In short, the bulk of expertise is in understanding the detail of connections between data and the processes which produced it or must consume it. It is precisely these expert connections which standard data vocabularies are intended to sever.
Gary Edwards

Xandros, Inc. - Xandros to Provide Enhanced Interoperability Between Standardized XML D... - 0 views

www.marketwire.com/...release.do

quickd

shared by Gary Edwards on 21 Jun 07 - Cached
  • Xandros, the leading provider of intuitive Linux solutions and cross platform interoperability tools, today announced it will join Microsoft and other companies to build and ship open source translators between documents stored in Ecma Office Open XML and Open Document Formats. The translators, being developed through the Open XML/ODF Translator project, will be made available to Xandros users via the Xandros Networks update facility. Every Xandros product that includes OpenOffice.org will be equipped with the translators. This announcement underscores the shared view of Xandros and Microsoft that competing office productivity applications should make it easy for customers to exchange files with one another and allow them to use their operating system and office productivity applications of choice. "This is good news for customers. Xandros and Microsoft share the view that competing office productivity applications should make it easy for customers to exchange files with one another," said Tom Robertson, general manager for Interoperability and Standards at Microsoft. "Mixed system environments are becoming more common, and we believe in delivering interoperability by design for the benefit of our customers. Our ongoing collaborative relationships with commercial open source companies like Xandros help us achieve that goal." "We are delighted to join forces with Microsoft and others to provide interoperability between standardized XML document formats," said Andreas Typaldos, Xandros CEO. "The work of the world is done using various document formats as well as operating systems, so it is vital to provide our customers with the means interoperate with ease in this diverse environment."
  • Gary Edwards on 21 Jun 07
     
    You have to read this!  Xandros is taking this interoperability garbage seriously!
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
Jesper Lund Stocholm

Microsoft Expands List of Formats Supported in Microsoft Office: Move enhances customer... - 0 views

www.microsoft.com/...05-21ExpandedFormatsPR.mspx

microsoft msoffice 14 msoffice 2007 odf pdf xps

shared by Jesper Lund Stocholm on 22 May 08 - Cached
  • REDMOND, Wash. — May 21, 2008 — Microsoft Corp. is offering customers greater choice and more flexibility among document formats, as well as creating additional opportunities for developer and competitors, by expanding the range of document formats supported in its flagship Office productivity suite.
  • With the release of Microsoft Office 2007 Service Pack 2 (SP2) scheduled for the first half of 2009, the list will grow to include support for XML Paper Specification (XPS), Portable Document Format (PDF) 1.5, PDF/A and Open Document Format (ODF) v1.1.
  • It will also allow customers to set ODF as the default file format for Office 2007. To also provide ODF support for users of earlier versions of Microsoft Office (Office XP and Office 2003), Microsoft will continue to collaborate with the open source community in the ongoing development of the Open XML-ODF translator project on SourceForge.net.
    • Paul Merrell
      Paul Merrell on 22 May 08
       
      The wookie here is the lack of native ODF support in older versions of MS Office, together with the earlier-announced intent to develop a new special API for other vendors to add native file suport via MS Office plug-ins. As part of its previous effort to backport OOXML support to earlier versions of Office and to port it to Office for the Mac, Microsoft engineers internally added OOXML support using the Office 2003 native file support to the Office 2003 native file support plug-in APIs, ripped it out of Office 2003 for Office 2007, wrapped it as a module with the same interface as the older APIs, then back and cross ported the module to the earlier versions and Office for the Mac. The new APIs for use by competitors must of necessity be integrated with the existing module. Anytime Microsoft needs to issue a bug fix for OOXML in the earlier versions, it would seem that the most efficient manner for Micriosoft to do so would be a patch for all versions that support OOXML. A patch that adds ODF support for the other Office versions would seem to be a fairly trivial task that could be rolled out with the patches that bring the older versions up to date with the final version of ISO/IEC OOXML In my view, the only conceivable reason for the new APIs is to limit the Office functionality available to competitors who write plug-ins for Office.
    • Jesper Lund Stocholm
      Jesper Lund Stocholm on 02 Jun 08
       
      Another key point in the silver lining here is that Microsoft will add native support for ODF to Microsoft Office 2007 SP2 "and beyond". However support for ODF in previous versions of Microsoft Office will not be native but through the CleverAge Converter on SourceForge. It will in other words be XSLT-based translation of ODF to/from OOXML with the known issues with translation such as bad quality and performance. http://idippedut.dk/post/2008/05/Document-translation-sucks-(When-Rob-is-right2c-hes-right).aspx
  • ...1 more annotation...
  • “Microsoft’s support for ODF in Office is a great step that enables customers to work with the document format that best meets their needs, and it enables&nbsp;interoperability in the marketplace,” said Roger Levy, senior vice president and general manager of Open Platform Solutions for Novell Inc. “Novell is proud to be an industry leader in cross-platform document interoperability through our work in the Document Interoperability Initiative, the Interop Vendor Alliance and with our direct collaboration with Microsoft in our Interoperability Lab. We look forward to continuing this work for the benefit of customers across the IT spectrum.”
  • Paul Merrell on 22 May 08
     
    Microsoft press announcement: REDMOND, Wash. - May 21, 2008 - Microsoft Corp. is offering customers greater choice and more flexibility among document formats, as well as creating additional opportunities for developer and competitors, by expanding the range of document formats supported in its flagship Office productivity suite.
  • Jesper Lund Stocholm on 02 Jun 08
     
    Microsoft press announcement: REDMOND, Wash. - May 21, 2008 - Microsoft Corp. is offering customers greater choice and more flexibility among document formats, as well as creating additional opportunities for developer and competitors, by expanding the range of document formats supported in its flagship Office productivity suite.
Gary Edwards

ODF 1.2? You're dreaming! Microsoft starts rolling out more OOXML translators | Mary... - 0 views

blogs.zdnet.com/microsoft

cdf mary-jo metadata odf ooxml opendocument zdnet

shared by Gary Edwards on 11 Dec 07 - Cached
  • Over the next three months, Microsoft will be releasing new and updated translators designed to aid&nbsp; customers who want interoperability between Microsoft’s Office Open XML (OOXML) and other document formats, including Open Document Format (ODF). On December 4, Microsoft began rolling out three new translators that it plans to make available this month: A 1.1 update of its translator for Word; an Open XML spreadsheet translator and a presentation translator. Additionally, in February 2008, Microsoft will deliver the final version of its translator designed to provide interoperability between the Chinese-government backed Uniform Office Format (UOF) file format and OOXML. Microsoft announced the creation of the SourceForge-hosted Open Translation Project in July 2006. At that time, the Softies said the translator-focused initiatve was started “in response to government requests for interoperability with ODF because they work with constituent groups that use that format.” Vijay Rajagopalan, a Microsoft Principal Architect, provided the update on the OOXML-ODF translation work during the XML 2007 conference on Decmeber 4. During the XML 2007 interoperability panel — sponsored by Microsoft and of which Rajagopalan was a part — the ongoing battles that have raged for the past couple of years between Microsoft and the backers of ODF were a mere sidenote.
Paul Merrell

GullFOSS - 0 views

blogs.sun.com/...office_open_xml_ooxml_filters

interop myth sources michael brauer odf ooxml sun

shared by Paul Merrell on 29 May 08 - Cached
  • ODF is the only file format that provides the level of interoperability and choice of products that our customers want.
    • Paul Merrell
      Paul Merrell on 29 May 08
       
      Brauer well knows that he speaks of "the level of interoperability and choice of products" that Sun wants, not what Sun customers want. See e.g., the IDABC ODEF Conference proceedings. ODF is not designed for interoperability and interoperability may only be achieved by all persons involved in the interchange of ODF documents standardizing on a particular editing implementation and version. In practical terms, that means everyone uses a particular version of OpenOffice.org or a clone of that version's code base.
  • OOXML? Isn't that Office Open XML? That file format, that Microsoft Office 2007 is using, that has been approved by ECMA as ECMA-376, and that is currently in a fast track process to become an ISO standard like ODF? That file format, that although its name is very similar to Open Office XML, has nothing to do with OpenOffice.org or ODF? And you may have wondered: What are Sun's OpenOffice.org developers doing with OOXML, and why? And when will we have an OOXML filter in OpenOffice.org?
Gary Edwards

Microsoft Watch - Business Applications - Convergence=Integration - 0 views

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

chains exchange hubs microsoft odf office ooxml opendocument openxml sharepoint xml

shared by Gary Edwards on 13 Mar 07 - Cached
  • Microsoft significantly increases cross-integration of features with the company's other software. Microsoft acquired most of the products making up its Dynamics product line, and what a motley crew. New products and versions bring the Dynamics line more into the Microsoft family, in part by convergence—or increased integration with the company's other software.
  • Gary Edwards on 13 Mar 07
     
    Thanks for the insightful commentary Joe. I see things a bit differently. Maybe my tin foil hat is wearing a bit tight these days, but i see MSOffice XML (MOOXML and the MOOXML binary InfoSet) as a very important aspect of how Microsoft integrates and leverages their desktop office monopoly power into server side and device systems. It is the combination of MOOXML and .NET that creates the integration mesh between desktop, server systems, and devices. Imagine every application or service participating in either a loosely coupled or carefully crafted information processing chain, being fluent in MOOXML, and able to process internal data structures and processing instructions unique to .NET. Enterprise systems and services from ORACLE, IBM and SAP will not have this same integration fluency. The design of ISO MOOXML is such that it would be impossible for <b>non Microsoft server and device systems</b> to match the quality and depth of integration with the 500 million desktops running MSOffice bound business processes. Given that MOOXML will probably succeed at getting ISO/IEC approval, removing the last "legal" barrier for this MOOXML Stack, were looking at a massive migration of MSOffice bound workgroup - workflow business processes to a new lockin point; The Exchange/SharePoint Hub. With the real estate industry, this migration to to E/S hosted applications only took six months to completely replace years of desktop productivity shrinkware dominance. The leap in productivity was spectacular. The downside of this migration is that the real estate industry is now tied into Microsoft at the critically important business process level. A binding that will perhaps last through the next fifteen years.
Gary Edwards

Document Interoperability Initiative Demonstrates Momentum and Results: Industry collab... - 0 views

www.microsoft.com/...12-03DIIBrusselsPR.mspx

ooxml odf openoffice msoffice iso microsoft brussels

shared by Gary Edwards on 03 Dec 08 - Cached
  • Gary Edwards on 03 Dec 08
     
    Through the Document Interoperability Initiative (DII) global forums, technology leaders have been working together to promote interoperability between different document format implementations to provide greater value and choice to customers, and the events - including one held in Belgium this week - are yielding practical results. Interoperability solutions announced today translate Open XML documents to a Web page (HTML) allowing readability on Web-friendly browsers such as Firefox, improve translations between different formats through optimized templates, and enable features that provide greater choice for customers and opportunities for independent software developers as they create and use business applications built on Java that manipulate business documents. At the DII events, discussions were also held about developing document test libraries and schema validators, and vendors had the opportunity to test their implementations of document formats in a lab environment to identify potential issues to be addressed.
Gary Edwards

The future of XML - 0 views

www.ibm.com/...x-xml2008prevw.html

odf ooxml xhtml xml

shared by Gary Edwards on 07 Mar 08 - Cached
  • Of course, the most important conversion isn't from OpenDoc to OOXML or vice versa: it's a down conversion from either OpenDoc or OOXML to XHTML. The HTML exporters in OpenOffice and Microsoft Office are uniformly atrocious. Look for third-party developers to pick up the slack. Most important, look for individual corporate developers and webmasters to begin publishing custom templates for their sites. This will enable regular folks to write in Microsoft Word as they're accustomed to doing and then upload their musings straight into the local content-management system. Editing and reviewing tools can be built right in. Because machines generate all the markup (the humans see the GUI interface they're used to), well-formedness will be a freebie. The majority of the Web won't be well-formed by the end of 2008, but a larger percentage will be than today.
Gary Edwards

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

blogs.zdnet.com/microsoft

burtongorup cdf css garyedwards maryjo odf okelly ooxml w3c xhtml

shared by Gary Edwards on 20 Jan 08 - Cached
  • “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
      Gary Edwards on 20 Jan 08
       
      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

Keeping both sides honest - O&#0092;'Reilly XML Blog - 0 views

www.oreillynet.com/...keeping_both_sides_honest.html

massachusetts microsoft odf ooxml opendocument openxml

shared by Gary Edwards on 12 Mar 07 - Cached
  • The former State Government CIO of Massachusetts (a state in USA) Louis Gutierrez has a worthwhile interview in Computerworld this week. What I like about the article in particular is that he seems clear that the role of govenment is not just to passively accept standards, but to pragmatically assess the suitability and impact and processes of each one. ISO makes “voluntary standards” not laws. Gutierrez says the obvious: that there is a marked difference in the feature set between ODF and OpenXML (”straightforward simplicity” versus “feature-rich but very idiosyncratic diversty”): he does not trivialize the difference in coverage or scope between the two.
  • Gary Edwards on 12 Mar 07
     
    Finally, someone in Massachusetts is talking and it's the master, Louis Gutierrez.  Wiki Ricki has some nice comments about the ComputerWorld interview with Louis.  As have become his custom though, Rick once again carries the flag (or should i say water) for Microsoft.  Rick's expertise in XML used to be the draw for his column.  Now you have to parse through his comments, separating the nuggets of truth from the torren of bias.  Paid bias.  It's too bad.  Rick was one of the best. 
Gary Edwards

The Merging of SOA and Web 2.0: 2 - 0 views

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

2.0 ajax mashup odf ooxml soa web

shared by Gary Edwards on 15 Jul 07 - Cached
  • In many cases, the mashups' data or information sources have incompatible formats so integration becomes a problem.
  • Gary Edwards on 15 Jul 07
     
    Great article series from eWeek.  A must read.  But it all comes down to interoperability across two stack models:  The Microsoft Vista Stack, and an alternative Open Stack model that does not yet exist!

    Incompatible formats become a nightmare for the kind of integration any kind of SOA implementation depends on, let alone the Web 2.0 AJAX MashUps this article focuses on.

    I wonder why eWEEK didn't include the Joe Wilcox Micrsoft Watch Article, "Obla De OBA Da".  Joe hit hard on the connection between OOXML and the Vista Stack.  He missed the implications this will have on MS SOA solutions.  Open Source SOA solutions will be locked out of the Vista Stack.  And with 98% or more of existing desktop business processes bound to MSOffice, the transition of these business processes to the Vista Stack will no doubt have a dramatic impact on the marketplace.  Before the year is out, we'll see Redmond let loose with a torrent of MS SOA solutions.  The only reason they've held back is that they need to first have all the Vista Stack pieces in place.

    I don't think Microsoft is being held back by OOXML approval at ISO either.  ISO approval might have made a difference in Europe in 2006, but even there, the EU IDABC has dropped the ISO requirement.  For sure ISO approval means nothing in the US, as California and Massachusetts have demonstrated. 

    All that matters to State CIO's is that they can migrate exisiting docuemnts and business processes to XML.  The only question is, "Which XML?  OOXML, ODF or XHTML+".

    The high fidelity conversion ratio and non disruptive OOXML plugin for MSOffice has certainly provided OOXML with the edge in this process. <br
Gary Edwards

Microsoft Hit By U.S. DOT Ban On Windows Vista, Explorer 7, and Office 2007 - Technolog... - 0 views

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

exchange/sharepoint government msoffice odf opendocument standards vista vistachain vistastack

shared by Gary Edwards on 06 Mar 07 - Cached
  • »&nbsp; E-Mail »&nbsp; Print »&nbsp; Discuss »&nbsp; Write To Editor late last year -- can be resolved. "We have more confidence in Microsoft than we would have 10 years ago," says Schmidt. "But it always makes sense to look at the security implications, the value back to the customer, and those kind of issues." The DOT's ban on Vista, Internet Explorer 7, and Office 2007 applies to 15,000 computer users at DOT proper who are currently running the Windows XP Professional operating system. The memo indicates that a similar ban is in effect at the Federal Aviation Administration, which has 45,000 desktop users. Compatibility with existing applications appears to be the Transportation Department's major concern. According to a separate memo, a number of key software applications and utilities in use in various branches of the department aren't Vista compatible. Among them are Aspen 2.8.1, ISS 2.11, ProVu 3.1.1, and Capri 6.5, according to a memo issued by staffers at the DOT's Federal Motor Carrier Safety Administration. Any prolonged ban on new Microsoft technologies by the federal government could have a significant impact on the software maker's bottom line, as Microsoft sells millions of dollars in software to the feds annually. http://as.cmpnet.com/event.ng/Type=count&amp;ClientType=2&amp;AdID=125682&amp;FlightID=75634&amp;TargetID=2625&amp;SiteID=222&amp;AffiliateID=283&amp;EntityDefResetFlag=0&amp;Segments=1411,3108,3448,11291,12119&amp;Targets=2625,2878,7904,8579&amp;Values=34,46,51,63,77,87,91,102,140,222,227,283,442,646,656,1184,1255,1311,1405,1431,1716,1767,1785,1798,1925,1945,1970,2217,2299,2310,2326,2352,2678,2727,2767,2862,2942,3140,3347,3632,3636,3638,3890,3904,4080,448
  • Gary Edwards on 06 Mar 07
     
    Whoa, those government desktops add up quickly.  This Vista ban will immediately effect over 50,000 desktops, with tens of thousands more possibly impacted by the IE 7.0 ban.  The MS Exchange/SharePoint Hub juggernaut is based on IE 7.0, which is not available for Windows 2000 - MSOffice 2000 desktops.

    Lack of Vista Stack compatibility with non Microsoft application is given as the reason for the ban.  But notice the "alternatives" to Vista mentioned; Novel SuSE and Apple Mac.  What kind of interop - compatibility do they offer?  My guess is ZERO!

    The reality is that the DOT is trapped.  My advice would be stay exactly where they are, keeping the current MSOffice desktop installs running.  Then, install the Foundation's daVinci ODF plugin for MSOffice. 

    This will insure that Windows OS and  MSOffice bound business processes can continue to function without disruption.  Win32 APi based applications like those mentioned in the article can continue.  Critical day to day business processes, workgroup and workflow related activities can continue without disruption or costly re engineering demanded by a cross platform port.

    What daVinci doe sdo is move the iron triangle that binds Windows-MSOffice applications to business processes and documents, to an ODF footing.  Once on a ODF footing, the government can push forward with the same kind of workgroup - workflow - intelligent docuemnt - collaborative computing advnaces that the Vista Stack was designed to deliver.  Only this push will involve the highly competitive "the customer is sovereign" environment of ODF ready desktop, server, device and Web 2.0 systems.  End of Redmond lock-in.  End of the costly iron triangle and the force march upgrade treadmill that so enriches Microsoft.

    So what's not to like?  We can do this.
    ~ge~

    http://docs.google.com/View?docID=dghfk5w9_20d2x6rf&amp;revi
Gary Edwards

Office 2007 won't support ISO's OOXML - SD Times On The Web - 0 views

www.sdtimes.com/...article.aspx

iso oasis odf ooxml pdf

shared by Gary Edwards on 21 May 08 - Cached
  • In a surprise move, the company also announced that it intends to participate in the OASIS ODF working group and the corresponding ISO/IEC Joint Technical Committee 1 Subcommittee 34 working groups for ODF, as well as the ISO Technical Committee 171 working group for PDF, said Doug Mahugh, senior product manager for Microsoft Office.He added that Microsoft would also introduce an API to allow developers to plug their own converters for formats, such as ODF, into Office to make it the default conversion path. ODF 1.1 was chosen over the ISO-standard ODF 1.0 as a practical decision based upon interoperability with existing implementations, Mahugh explained.
    • Paul Merrell
      Paul Merrell on 22 May 08
       
      The announcement of the new API for others to use for plug-ins is not new news. It was originally made when Microsoft claimed to have gotten religion on interoperability a few months ago. The wookie is that the only conceivable reason for a new API for use by others is that Microsoft does not want to disclose the specs for its existing API. That in turn suggests that the API for use by others will have functionality different from the API used by Microsoft itself, almost certainly far less.
  • “Customers that are expecting true document fidelity from XML-based, ISO-standard document formats will continue to be disappointed,” said Michael Silver, a Gartner Research vice president. Silver observed that the most compatible formats to use today are Microsoft’s legacy binaries, and he believes that Microsoft will be unlikely to convince customers to move to OOXML in the foreseeable future.
  • Gary Edwards on 21 May 08
     
    Microsoft to support PDF, ODF 1.1 and ISO OOXML in MSOffice 14. The company will also join the OASIS ODF TC and working group for ISO PDF.
Gary Edwards

IBM's Stance Against OpenXML Is Increasingly Confusing : Oliver Bell's weblog - 0 views

osrin.net/...nxml-is-increasingly-confusing

cdf heintzman ibm odf ooxml opendocument openxml symphony weir

shared by Gary Edwards on 25 Jan 08 - Cached
  • Events have played out in the media and in the blogosphere over the last couple of weeks that represent a breakdown of some of those anti-OpenXML arguments that have been played back so frequently over the last year. Arguments that there is a lack of demand for Open XML, the specification is too complex to implement, the specification can’t be deployed cross platform and the long running but baseless claim that the Ecma-376 specification might be encumbered by IPR and patent threats all appear to have been cast aside as big blue steps up to meet the demands of their own customers and the market in general. Here is a blow by blow review of the relevant activity over the last two weeks…
1 - 20 of 20
Showing 20▼ items per page