Skip to main content

Home/ Document Wars/ Group items tagged reuter

Rss Feed Group items tagged

Gary Edwards

Free-Office - 0 views

  •  
    Wow, what an interesting collection of blogs.  Everything ODF, including blogs from florian Reuter, Rob Weir, and Bob Sutor.
  • ...2 more comments...
  •  
    Wow, what an interesting collection of blogs.  Everything ODF, including blogs from florian Reuter, Rob Weir, and Bob Sutor.
  •  
    Wow, what an interesting collection of blogs. Everything ODF, including blogs from florian Reuter, Rob Weir, and Bob Sutor.
  •  
    Wow, what an interesting collection of blogs. Everything ODF, including blogs from florian Reuter, Rob Weir, and Bob Sutor.
  •  
    Wow, what an interesting collection of blogs. Everything ODF, including blogs from florian Reuter, Rob Weir, and Bob Sutor.
Paul Merrell

U.S. top court declines to hear Microsoft antitrust case | Reuters - 0 views

  • (Reuters) - The U.S. Supreme Court on Monday brought an end to Novell Inc's antitrust claims against Microsoft Corp that date back 20 years to the development of Windows 95 software. By declining to hear Novell's appeal, the court left intact a 10th U.S. Circuit Court of Appeals ruling from September 2013 in favor of Microsoft.The court of appeals unanimously affirmed the dismissal of Novell Inc's claims that Microsoft violated the Sherman Antitrust Act when it decided not to share its intellectual property while developing its Windows 95 operating system.
  • The Novell case, which was first filed in 2004, was over Microsoft's decision not to share with Novell details about its Windows operating system. Novell claimed that its suite of applications, including WordPerfect, suffered as a result of Microsoft withholding the information.Novell alleged that Microsoft used its market power in operating systems to promote its own applications.
Gary Edwards

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

  • In a highly informative post to his Open Stack blog Wednesday, Edwards explains how three key features are necessary for organizations to convert to open formats. These are: Conversion Fidelity - the billions of binaries problem Round Trip Fidelity - the MSOffice bound business processes, line of business integrated apps, and assistive technology type add-ons Application Interop - the cross platform, inter application, cross information domain problem
  •  
    Dana Blankenhorn posted this article back in March of 2007.  It was right at the time when the OASIS ODF TC and Metadata XML/RDF SC (Sub Committee) were going at it hammer and tong concerning three very important file format characteristics needed to fulfill a real world interoperability expectation:

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

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

Gary Edwards

IBM's Potempkin Village | Florian Reuter's Weblog - Flock - 0 views

  • I think that contradicts the SISSL :-)
  •  
    Recently IBM held a ODF Interoperability Workshop at the OpenOffice annual conference in Barcelona, Spain. The Workshop was organized by IBM's Rob Weir. In this blog, uber document processing expert Florian Reuter opens the lid for a peek at what really happened at the Workshop. And it wasn't "interoperability". As a Novell employee, Florian is unable to comment publicly as to what really happened in Barcelona. But to those who are not under IBM's oppressive thumb, the results of this fiasco are laughable. Sure IBM and Rob Weir are busy threatening individuals, and bribing the press to suppress the reality of this horrific ODF ZERO Interop demonstration. But that doesn't mean those who really care can't talk about it. The OpenDocument Foundation has of course been screaming about the ODF interop problems. But we've been focused on the big picture of world wide market requirements; the need for ODF to be compatible with existing file formats and interoperable with existing applications - including Microsoft documents and applications. Of course, this level of interoperability was outside the scope of ODF purpose and work. We apologize for daring to suggest that real world implementation issues are important and ought to be considered. but there remains the issue of ODF interoperability which also sucks beyond belief. The exact same principles apply. ODF interop depends on complete application independence, and ODF remains bound to OpenOffice. Now i'm someone who has publicly championed ODF interoperability. I've spent years championing the fact that ODF can meet all market requirements for interoperability. And whatever credibility i thought i might have is now destroyed by that very public and very in your face lack of interoperability.

    So here i am, with any credibility i might have ever had resting on the pretensions of a self proclaimed clown (a hef="http://wordnet.princeton.edu/perl/webwn?s=antic">his description not mine). Can R
  •  
    Let's do this again:

    Recently IBM held a ODF Interoperability Workshop at the OpenOffice annual conference in Barcelona, Spain. The Workshop was organized by IBM's Rob Weir. In this blog, uber document processing expert Florian Reuter opens the lid for a peek at what really happened at the Workshop. And it wasn't "interoperability".

    As a Novell employee, Florian is unable to comment publicly as to what really happened in Barcelona. But to those who are not under IBM's oppressive thumb, the results of this fiasco are laughable. Sure IBM and Rob Weir are busy threatening individuals, and bribing the press to suppress the reality of this horrific ODF ZERO Interop demonstration. But that doesn't mean those who really care can't talk about it.

    The OpenDocument Foundation has of course been screaming about the ODF interop problems. But we've been focused on the big picture of world wide market requirements; the need for ODF to be compatible with existing file formats and interoperable with existing applications - including Microsoft documents and applications.

    Of course, this level of interoperability was way outside the scope of ODF purpose and work. We apologize for daring to suggest that real world implementation issues are important and ought to be considered. But there remains the issue of ODF interoperability which also sucks beyond belief.

    The exact same principles apply. ODF interop depends on complete application independence, and ODF remains bound to OpenOffice.

    Now i'm someone who has publicly championed ODF interoperability. I've spent years championing the fact that ODF can meet all market requirements for interoperability. And whatever credibility i thought i might have is now destroyed by that very public and very in your face lack of interoperability.

    So here i am, with any credibility i might have ever had resting on the pretensions of a self proclaimed clown (http://wordnet.princ
Gary Edwards

OASIS ODF: List Proposal Enhancement Vote Deadline on Wednesday | Gary Edwards - 0 views

  •  
    Thanks to Paul for digging this up. Who would have guessed that years later, these same issues hang like a dark shroud on the future of ODF? Note also that June 1st of 2007 was the cut off date for ODF 1.2 proposals and recommendations. The OpenFormula and Metadata SC's were rushing to make the cutoff. The List Enhancement proposal itself was just one of many enhancements submitted by Florian Reuter in November of 2006, designed to greatly improve ODF compatibility with MSOffice "ODF". By November of 2006, thanks largely to the Massachusetts Pilot Study, there were a number of ODF plug-ins for MSOffice. All were capable of producing perfectly compliant ISO 26300 ODF, but falling far short of public expectations of high fidelity interop with OpenOffice ODF. Sound familiar? Everyone knew that it was only a matter of time before Microsoft was pressed into providing MSOffice ODF support. There was no doubt that they would face the exact same interop challenges as the many independent plug-in efforts. Hence the stepped up efforts by many at the OASIS ODF to "fix" ISO 26300! At the time of the List Enhancement Proposal, we had increasing evidence from the many pilot studies that ODF was impossible to implement in business and workgroup environments where the MSOffice productivity environment was the defining platform. ODF was not designed to be compatible with MSOffice or the binary documents so critical to business processes bound to this environment. OpenXML was designed exactly to be compatible with these environments. Unless ODF fixed it's compatibility/interoperability problems there was no way for the independent plug-ins to provide a reasonable ODF implementation alternative to OpenXML. And even if Microsoft did produce an MSOffice ODF compliant with ISO 26300, these productivity environments would remain entirely locked. The world expected ODF to be compatible, interoperable, Web ready, and fully capable of cracking open the iron grip Mic
Gary Edwards

High-latency, low-bandwidth windowing in the Jupiter collaboration system - 0 views

  •  
    Operational  Transforms (OT) is used by Microsoft CustomXML and Google Wave!  The original idea was first presented by Zerox Parc researchers in 1995, prior to the i4i patent.  The Jupiter System  includes the Jupiter Window Tool Kit, wich is all about OT.  XML came much later with the i4i patent for encoding XML with OT positioning. Insert(pos, text)Delete(pos, num-of-chars) See Google Wave API: http://www.waveprotocol.org/whitepapers/operational-transform Credit Florian Reuter for this find!!!!! 
Gary Edwards

Florian's libopc webkit demo - 1 views

  •  
    Florian Reuter has published another video demonstrating his LibOPC work; this time with his LibOPC library running in WebKit.
Gary Edwards

GullFOSS: It's our way or the highway. So what if new cool features = Zero Interop? D... - 0 views

  • When such new features that enhance the interoperability require enhancements to the Open Document file format we will propose the necessary changes to the OASIS Open Document TC. This way not only OpenOffice.org but also Open Document benefits from our efforts. Florian Reuter, who now works for Novell, lists some of the changes we have in mind in his blog . So there are a lot of common ideas how we can improve the interoperability between OpenOffice.org and Microsoft Word documents and I hope we can work together with Florian here.
  •  
    The chuckleheads at Sun's StarOffice/OpenOffice Hamburg office respond to Florian's comprehensive lis tof suggestions to greatly improve ODF interoperability. 
  •  
    Make no mistake about it. Microsoft is absolutely right about three things: .... Compatibility with existing file formats is not an ODF concern. .... Sun controls the OASIS ODF TC. .... Sun makes certain that ODF is bound tightly to the OpenOffice feature set. Sun's view of interoperability is that of a one way street. Documents can be converted into ODF-OOo/SO, but they are guaranteed to break during any kind of document routing or round tripping. This is also the reason why the Sun "external" plugin for MSOffice fails. One way conversion simply isn't enough to crack the hold MSOffice has on critical day to day business processes. The only way to that is with a conversion process able to maintain high level fidelity while round tripping. As the EU IDABC has figured out, the ODF-OOo/SO specification is loaded with interoperability break points. That's why they are turning to ODEF, which can be seen as a version of ODF that is truly application independent and optimized for interoperability. ~ge~
Gary Edwards

ODF1.2 Interoperability Proposal - 0 views

  • Subject: Suggested ODF1.2 items From: "Florian Reuter" <freuter@novell.com> To: <office@lists.oasis-open.org> Date: Mon, 20 Nov 2006 17:03:24 +0100 Suggested enhancement for OpenDocument V1.2
    • Gary Edwards
       
      This message was submitted to the ODF-OOo/SO OASIS TC the day Florian joined Novell. His Novell contract allowed him to continue his work as the OpenDcoument Foundation's CTO. Take note of the response from Sun's Michael Brauer. It's a classic. The link is at the bottom of the page. ~ge~
  •  
    Part of the sad but enduring "History of Failed ODF Interoperability Attempts".  This particular message is dated November 20th, 2006. 

    The OpenDocument Foundation was notified a week earlier that the "benefactor" ODF Community group Louis Gutierrez had asked IBM and Oracle to put together in Massachusetts had failed.  This was the group Louis formed around the da Vinci plugin and our InfoSet APi. 

    Florian has been hired by Novell, and his first day on the job he finds out about the IBM - Novell deal with Microsoft.  Now he has write the MOOXML plugin for OpenOffice using the MS-CleverAge Translator Project work.  So he writes this message to the ODF TC [office] list. 

    The interoperability enhancements Florian suggests are based on the <interoperability eXtensions> submitted in August to the ODF Metadata SC for consideration.

    The first element in this list tha tFlorian chose to tackle related to "Lists".  He called it the "LIst Override Proposal".  This became the now infamous "List Enhancement Proposal War" that resulted in Sun having OASIS boot out the Foundation.

    Such is life in big vendor ODF'dom

    ~ge~

Gary Edwards

OOXML in Norway: The haywire process | Geir Isene : Straight talk on IT - 0 views

  • I had read the essay by Jon Bosak (SUN Microsystems) on why SUN voted as it did in the US. He lays out a very different strategy. His view is that the battle is lost to completely reject OOXML as an ISO standard. ISO can only reject it with comments, and that is equivalent to giving Microsoft a todo-list on how to fix the draft so as to get it approved. Microsoft has sufficient manpower to easily tackle that. Most of us had missed what Mr. Bosak saw: OOXML promises interoperability with earlier closed binary formats (the Word Doc, older Excel file formats etc.). But it doesn’t deliver. How on earth could someone be able to convert old binary files to the new format without having the specification of the old formats and a mapping to OOXML. If you are to translate some text from Chinese to English, it doesn’t much help to only know English.
    • Gary Edwards
       
      A "Yes with comments" is a yes for the ISO approval of MS-OOMXL. If ISO approves MS-OOXML, it won't matter what Bosak's "comments" strategy is. Microsoft and the Vista Stack will be off to the races. The full disclosure of the MS binary document secret blueprint won't matter much at that point.
  • “Ah c’mon Bosak, you are chickening out, we must stop this dead in the track”
    • Gary Edwards
       
      There you go Geir!

      Sun and Bosak have held the door open for MS-OOXML since 2002, when Sun blocked an effort to write the ODF Charter to include as a priority, "compatibility with existing file formats". This of course would include the billions of legacy MS binary documents.

      The thing is that those who work in the conversion-translation field will tell you that it is currently impossible to pipe converted legacy binary documents and OOXMl docs for that matter into ODF. Just as Microsoft claims, ODF in it's current state is insufficient and unable to handle the rich feature set of the MSOffice developers platform.

      The problem could of course be easily fixed by the inclusion in ODF of five structural generics. In the past year, there have been no less than five iX "interoperability enhancement" proposals submitted to the OASIS ODF TC for discussion and consideration. As uber universal interop expert Florian Reuter points out in his blog, these iX proposals did not fare so well.

      What Florian doesn't point out is that it was Sun who opposed any and all efforts to improve compatibility with existing Microsoft binary and OOXML documents. Just as they have done for nearly five years now.

      Sort of puts the Sun-Bosak support for ISO approval of MS-OOXML in a different light. ~ge~
  •  
    see the sticky notes on this one
Gary Edwards

But can money buy love? :: Another Microsoft Sponsored OOXML Study - 0 views

  •  
    Joe Wilson of Microsoft Watch knocks another one out of the park. Why is it that so few in the media get it? Or anyone else for that matter? Matt Assay gets it. But few understand the Vista Stack and the importance of OOXML in the transition of the monopoly base from MSOffice to the Vista Stack. No doubt the arrogance of those who dare challenge Microsoft is both a necessary blessing and guaranteed curse. Take for instance the widely held assumption that Microsoft invented MS-XML (OfficeOpenXML) in response to OpenDocument (ODf). This is false, misleading and will inevitably result in a FOSS death spiral in the face of a Vista Stack juggernaut. But it sure does feel good.

    Joe Wilson at Microsoft Watch points out the real reason for MS-XML, and why ISO approval of OOXML is so important. Microsoft needs OOXML approved as an international standard because OOXML is the binding model for the emerging Vista Stack of loosely coupled but information integrated applications.

    The Vista Stack model converges desktop, server, device and web information systems using OOXML-Smart Documents, .NET 3.0 and the XAML presentation layer as the binding components.

    The challenge for Microsoft is to migrate existing MSOffice bound business processes, line of business integrated apps, and advanced add-ons to the Exchange/SharePoint Hub. Once the existing documents, applications (MSOffice) and processes are migrated to the E/S Hub, they can be bound tightly to the rest of the Vista Stack.

    Others see OOXML as some sort of surrender or late recognition that the salad days of MSOffice are over. They jubilantly point to Web 2.0, Office 2.0 and rise of the LiNUX Desktop as having ushered in this end of monopoly for MSOffice. Like the ODf champions, these people are similarly sadly mistaken!

    While they celebrate, Microsoft is quie
Gary Edwards

Slamming the door shut on MS OOXML - 0 views

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

OpenForum Europe - EU Conclusions from Open Document Exchange Formats Workshop - 0 views

  • here was strong consensus among Member State administrations on the necessity to use ODEF on "openness" being the basic criteria of ODEF and resulting requirements towards industry players / consequences for public administrations There is a general dissatisfaction with the perspective of having competing standards; One format for one purpose: Administrations should be able to standardize (internally) on a minimal set of formats; No incomplete implementations, no proprietary extensions; Products should support all relevant standards and standards used should be supported by multiple products; Conformance testing and document validation possibilities are needed -&gt; in order to facilitate mapping / conversion; Handle the legacy / safeguard accessibility
  •  
    There must be something in the air.  The end user inspired idea that applications should be able to exchange documents perfectly preserving the presentation (man percieved appearance as opposed to machine interpreted layout-rendering) is gaining a rabid momentum.

    Yesterday it was the Intel ODF Test Suite results falling into the hands of Microsoft, who is now using the results to argue that OpenOffice doesn't fully support - implement ODF.  The Intel ODF Test Suite is notable in that the test is near 100% about comparative  "presentation" :: an object to object ocmparison of a KOffice document to an OpenOffice rendering of that document and vice versa.

    Today we have the EU IDABC hosting a continent wide conference discussing the same  issue :: the "exchange" of ODF documents.  They've even gone so far as to coin a new term; ODEF - OpenDocument Exchange Format!

    This morning i also recieved an invite to join a new OASIS discussion list, "The DocStandards Interoperability List".  The issue?  The converision and exchange of documents between different standards.

    And then there is the cry for help from Sophie Gautier.  This is an eMail that has worked it's way up to both the OASIS ODF Adoption TC and OASIS ODF Mainline TC discussion lists.  The problem is that Microsoft is presenting the Intel ODF Test Results to EU govenrments.  Sophie needs a response, and finds the truth hard to fathom.

    Last week the legendary document processing expert Patrick Durusau jumped into the ODF "Lists" embroglio with his concern that the public has a different idea about document exchange - interoperability than the ODF TC.  A very different idea.  The public expects a visual preservation of the documents presentation qual
Gary Edwards

The French AFNOR Proposal to Merge ODF and MS-OOXML - 0 views

  • Summary Statement:&nbsp; Hey, this is an excellent plan!&nbsp; We can fully support this effort, even though the ISO National Bodies still have to work their way through the treacherous big vendor consortia controlled channels of OASIS ODF and Ecma 376.&nbsp; Bringing the big vendor applications to heel is not going to be easy.&nbsp; Merging ODF and MS-OOXML however is a worthwhile effort - one that the conversion and translator plug-in communities have been working on for the past three years!&nbsp; It can be done!&nbsp; And all it takes is five generic elements added to the existing ODF 1.2 specification ........
Gary Edwards

ODF and OOXML must converge!! AFNOR, the French Standards Body, announces proposals for... - 0 views

  • AFNOR has recommended to ISO adopting an approach enabling it to guarantee – using ISO processes – mid-term convergence between Open Document Format (ODF) and OfficeOpen XML (OOXML), as well as the stabilisation of OOXML on a short-term basis.
  • Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions. Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality. Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years.&nbsp;&nbsp; Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players.
    • Gary Edwards
       
      Here's the meat of the French convergence proposal.
  •  
    French experts have determined that it is technically possible to converge ODF and MS-OOXML, into a single, revisable document format standard?

    The plan has four parts:

    "Firstly, to restructure the ECMA standard in two parts so as to differentiate between, on the one hand, a core of essential and simple functionalities to be implemented (OOXML-Core) and, on the other hand, all the additional functionalities required for compatibility with the stocks of existing office document files created by numerous users, which will be gathered within a package called OOXML-Extensions."

    "Secondly, AFNOR proposes to take into account a full series of technical comments submitted to the draft in order to make OOXML an ISO document of the highest possible technical and editorial quality."

    "Thirdly, it proposes to attribute to OOXML the status of ISO/TS for three years."

    Fourth, "Finally, AFNOR proposes to set up a process of convergence between ISO/IEC 26300 and the OOXML-Core. In order to achieve this, AFNOR will begin the simultaneous revision of ISO/IEC 26300 and of ISO/TS OOXML (subject to the latter being adopted after the aforementioned restructuring), so as to obtain the most universal possible single standard at the end of the convergence process. Any subsequent evolutions will be decided upon at ISO level and no longer at the level of such a group or category of players."




    So there you go.  A solution that removes ODF and OOXML from the clam
Gary Edwards

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

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

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

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

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

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

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

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

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

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

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

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

      So where is an Open Stack model to turn to?

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

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

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

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

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

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

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

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

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

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

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

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

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

      MSOffice 2007 i
  • ...6 more annotations...
  • Microsoft's backwards compatibility priority means the company made XML-based format decisions that compromise the open objectives of XML. Open Office XML is neither open nor XML.
    • Gary Edwards
       
      True, but a tricky statement given that the proprietary OOXML implementation is "optional".  It is theoretically possible to implement Ecma 376 without the prorpietary dependencies of MSOffice - Exchange/SharePoint Hub - Vista Stack "OOXML".

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

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

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

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


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

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

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

      The Vista Stack looks like this:

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

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

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

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

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

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

      These traditional desktop client/server productivity apps defined the real estate business process as far as it could be said to be "digital".  For the most part, the real estate transaction industry remains a paper driven process. The desktop stuff was only useful for managing clients and lead prospecting. No one could crack the electronic documents - electonic business transaction model.  This will no doubt change with the emer
  • Microsoft can offer businesses many of the informational sharing and mining benefits associated with the markup language while leveraging Office and supporting desktop and server products as the primary consumption conduit.
    • Gary Edwards
       
      Okay, now Joe has the Micrsoft SOA bull by the horns.  Why doesn't he wrestle the monster down?
  • By adapting XML
    • Gary Edwards
       
      The requirements of these E/S Hub systems are XP, XP MSOffice 2003 Professional, Exchange Server with OWL (Outlook on the Web) , SharePoint Server, Active Directory Server, and at least four MS SQL Servers!

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

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

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

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

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

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

      Even if Massachusetts had mandated ODF, they were only one E/S Hub Court Doc
  • Microsoft will vie for the whole business software stack, a strategy that I believe will be indisputable by early 2009 at the latest.
    • Gary Edwards
       
      Finally, someone who understands the grand strategy of levergaing the desktop monopoly into the converged space of server, device and web information systems.

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

      Also, Joe does not see the connection between OOXML as the portable XML document/data transport, and the insidiously proprietary Smart Documents metadata - data binding system that totally separates MSOOXML from Ecma 376 OOXML!
  • I'm convinced that Office as a platform is an eventual dead end. But Microsoft is going to lead lots of customers and partners down that platform path.
    • Gary Edwards
       
      Yes, but the new platform for busines process development is that of MSOffice <> Exchange/SharePoint Hub.

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

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

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

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

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

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

Gary Edwards

Office 2.0 Conference: Live Broadcast by Veodia - 0 views

  •  
    Here you go! A complete video library of all the Office 2.0 conference presentations and pane discussions. For sure check out the panel on file formats with Florian Reuter, Bill Welty, Jason Harrop, Arnaud de Hors, Tom Snyder, and moi. Excellent discussion!
    The trick to scrolling is to catch the horizontal scroll bar at the bottom of the page. Scroll to the right, and the video library vertical scroll bar will appear so you can see all the vids.
    Document Formats
Gary Edwards

Hunting down those who dare help Microsoft | Florian Reuter's Weblog - 0 views

  • New OpenOffice.org target.Many of you probaly know the “WONT FIX” target in the OpenOffice.org issue tracker.What about introducing a new target: “HELPS MICROSOFT”.But why do we need this? These days many people --- especially from the file formats camps --- are extremely sensitive of anything related to compatiblity 'cause they believe it helps Microsoft.So lets give the ODF warriors an opportinity to clearly communicate with the users. Give them the “HELPS MICROSOFT” target to publicly exposing the issuer of the bug and the people working on it.
  •  
    Another good one from that all around funny guy and document processing expert extraordinaire, Florian Reuter.  This one is way too funny.  I hope the lord of the garage gestapo doesn't take him up on this.
Gary Edwards

Does ODF 1.2 Metadata Solve the Interop Problem? - Microsoft starts rolling out more O... - 0 views

  • Sorry Shish, you're wrong about ODF 1.2 Try ODF 1.5 or ODF 2.0, maybe. The metadata requirements for ODF 1.2 actually did include two way lossless translation capability. Unfortunately these features did not survive the final cut, and were not included in the April 2007 submission. You might also want to check the February 23, 2007 metadata proposal from Florian Reuter. That also would have delivered the goods and perhaps put ODF that grand convergence category of usefulness across desktops, servers, devices and web systems currently the exclusive domains of MS-OOXML and CDF+. Florian had devised a means of using metadata to describe the presentation aspects of content and structural objects. Very revolutionary. And based on the simple notion that bold, font, margins etc. are simply metadata about content and style objects. Where the train came off the track had to do with the concept of an XML ID means of linking metadata to content. Not that there was anything wrong with this mechanism. It's actually quite clever. What went wrong was that Sun insisted that only those elements approved and supported by OpenOffice would be allowed to make use of XML ID metadata. For independent developers, this is a serious constraint. Because of this constraint, the metatdata sub committee started off with six elements supported by OOo that metadata could be appied to. IBM then came in and asked for eleven more elements having to do with charts and graphs. The OpenOffice crew decided they could support this, so in they went. Then an interesting question was posed, "How are independent developers supposed to submit elements for metadata consideration?"
  •  
    A Second response to Mary Jo's, "Microsoft starts rolling out more OOXML translators" is also posted here. The title is "Standardization by Corporation". Shish-Ka-Bob makes the assertion the ODF 1.2 metadata model will enable lossless two way conversion between MSOffice and ODF. While it's true that that intent was a key component of the original July of 2006 Metadata Requirements, the proposal was eventually stripped from the final submission made in April of 2007. I try to explain to Shish how that came about. The second post here, "Standardization by Corporation", is a follow on to statements made to Shish. The statements have to do with the events at ISO, and what i think will eventually happen. IMHO, ISO will follow either the AFNOR or Brittish proposals to merge ODF and OOXML. To do this they will remove entirely the coproarate vendor influence of Ecma and OASIS, and perfect the merger entirely at ISO. My post just happened to coincide with ISO Governor Mark Bryan's "Standardization by Corporations" letter. A derpressing but nevertheless very true concern. In fact, the OpenDocument Foundation was created specifically to address our concerns about the undue influence big application vendors were exerting on ODF following the April 30th, 2005 approval of ODF 1.0 (which went on to become ISO 26300). ~ge~
Gary Edwards

ODF 1.2 Metadata? You're Dreaming! Microsoft starts rolling out more OOXML translators... - 0 views

  • Sorry Shish, you're wrong about ODF 1.2 Try ODF 1.5 or ODF 2.0, maybe. The metadata requirements for ODF 1.2 actually did include two way lossless translation capability. Unfortunately these features did not survive the final cut, and were not included in the April 2007 submission. You might also want to check the February 23, 2007 metadata proposal from Florian Reuter. That also would have delivered the goods and perhaps put ODF that grand convergence category of usefulness across desktops, servers, devices and web systems currently the exclusive domains of MS-OOXML and CDF+. Florian had devised a means of using metadata to describe the presentation aspects of content and structural objects. Very revolutionary. And based on the simple notion that bold, font, margins etc. are simply metadata about content and style objects. Where the train came off the track had to do with the concept of an XML ID means of linking metadata to content. Not that there was anything wrong with this mechanism. It's actually quite clever. What went wrong was that Sun insisted that only those elements approved and supported by OpenOffice would be allowed to make use of XML ID metadata. For independent developers, this is a serious constraint. Because of this constraint, the metatdata sub committee started off with six elements supported by OOo that metadata could be appied to. IBM then came in and asked for eleven more elements having to do with charts and graphs. The OpenOffice crew decided they could support this, so in they went. Then an interesting question was posed, "How are independent developers supposed to submit elements for metadata consideration?"
1 - 20 of 27 Next ›
Showing 20 items per page