Thomas Cameron

Total Rating:
0 / 0

2 Comments

    • Tue Mar 18th 00:23 AM | Rating: 0 0
      Commented on:
      Is Red Hat Opposing Document Standard to Prepare Ban on Windows?
      Should have mentioned that I did clear it with Bryan before I used his text.

      Also - obviously I am not representing this as Red Hat's position, just mentioned I work there for disclosure purposes.
      View article »
    • Tue Mar 18th 00:17 AM | Rating: 0 0
      Commented on:
      Is Red Hat Opposing Document Standard to Prepare Ban on Windows?
      A colleague of mine named Bryan Smith here at Red Hat posted this, I thought it was a really great argument about the OOXML "standard:"

      "Top 10 Technical Reasons why [Office] OpenXML (OOXML) is NOT a Standard
      at All."

      10. Marketing: XML is not an application standard

      Uses XML in name [Office] OpenXML (OOXML) to prey upon ignorance of what
      XML is. XML is a template standards for writing vendor standards, not
      an end-application usable standard. It still requires a full set of
      support specifications, and even, that does not guarantee
      interoperability at all. OOXML not only does not have a full set of
      support specifications, but purposely avoids them (see #5-7 below).

      9. Poor History: Lack of standards in even RTF

      Microsoft has a horrendous history on any alleged standard. Most of its
      products do not even qualify as "proprietary"... standards, because that
      would require it to assign value and maintain compatibility for many
      versions. It, instead, chooses an approach of purposeful
      "hostageware"... (data is hostage after a few versions) aka "abandonware.&quo...

      A great example of this is Rich Text Format (RTF). Not only does RTF
      undergo revisions with every MS Office (specifically Word) release, but
      Microsoft exports RTF from MS Office with embedded DOC (Word) attributes
      that are not even in the RTF version standard. I.e., all office suites
      (even Microsoft Office itself) use the Microsoft DOC (Word) import
      filter to read RTF, because even a latest RTF filter does not work at
      all.

      8. Poor History: The abandoned XML "standard" of Office 11 (2003)

      This is not Microsoft's first attempt to use XML. Microsoft Office 11
      (2003, 2004 on Mac) offered allegedly XML support. The XML support was
      limited to two things: 1) third party content import (so third party
      applications could use MS Office as a "fat" content system/service) and
      2) a "dumb content" XML export (no style, no support specifications at
      all). This "standard" has been utterly abandoned. Will Office 12
      (2007, 2008 for Mac) be yet another repeat once Office 13 arrives?

      7. Core Issue: Designed to encapsulate binary data formats

      OOXML as implemented in Office 12 (2007, 2008 for Mac) is designed to
      largely address document compatibility by encapsulating older,
      "abandonware"... (not even "proprietary"... standard, but time-limited formats
      that should be considered "abandonware"... binary data formats in between
      XML tags. These include the regularly conflicting attributes in Office
      8 (97), 9 (2000), 10 (XP) and 11 (2003) for Windows formats, and let let
      alone made worst in their Mac equivalents (98, 2001, X and 2004,
      respectively).

      6. Core Issue: Designed for undocumented, binary data formats

      The regularly conflicting attributes for style (and even content) in
      Microsoft Office 8, 9, 10 and 11 binary data standards are poorly
      documented (if at all) in the OOXML specification. In fact, in several
      areas (especially in areas of locale, date/time, etc...), the Open
      Document Format (ODF) specification does a far better job. And even
      worse is the fact that Office 12 (2007) for Windows implementation seems
      to introduce some new undocumented, but encapsulated binary data
      formats. I.e., this trend of using undocumented, binary data formats --
      only now encapsulated between XML tags -- will yet still continue going
      forward in Microsoft Office implementations.

      5. Core Issue: Differing interpretations of binary data formats

      The Office 12 (2007, 2008 on Mac) implementation can only run into a
      "compatibility mode" to get the same interpretation of Office 11 (2003,
      2004 on Mac). Office 8, 9 and 10 still differ from that, especially
      when more revision apart. It is purposeful hostageware (your data
      becomes unable), commonly known as abandonware. Furthermore, Office
      12's native mode implementation still cannot read some of these binary
      formats, while having no equivalent or import. The hope is that by
      encapsulating some of these formats, Microsoft itself hopes (again,
      hopes) to be able to read them at some point (with added patches).
      Again, none of these are documented in the OOXML specification to a
      point of reproducible context+style (if at all).

      4. Core Purpose: Designed to solve data alignment issues (portability)

      The primary purpose of [Office] OpenXML (OOXML), as technically detailed
      in #5-7 above, is to solve an engineering nightmare in the Office
      division -- namely and currently, the Mac and Win64 ports -- by and for
      Microsoft itself. Win32 and the entire legacy of Office 8-11 for
      Windows, as well as the Office 11 (2003) compatibility mode of Office 12
      (2007) for Windows, is not portable to either Mac or Win64. Mac ports
      are done by another division, and binary write compatibility is limited
      -- e.g., Mac can "read" Windows files (with an intelligent, byte-by-byte
      import), but cannot "send them back" to Windows (which has exacting data
      alignment assumptions, which also causes compatibility issues between
      even Office for Windows versions itself).

      I.e., there are data alignment assumptions in Office for Windows (Win32)
      that break in Office for Mac, and any planned, native Win64 port. By
      breaking down binary formats into bytes, encoding and encapsulating them
      in between XML tags, non-Win32 implementations of Office 12 (2007) --
      e.g., Office 2008 on Mac and future, planned, native Win64 relesaes --
      can maintain better 2-way data exchange of binary formats, as they are
      encapsulated/encoded at the byte level (eliminates alignment issues)
      between XML tags.

      Again, these encapsulated binary formats are poorly documented (if at
      all) in most cases in the OOXML specification.

      3. Avoids standardization: Does not implement support standards

      Office 12 (2007) makes no effort to incorporate other, standardized
      (e.g., ISO, OASIS, W3C) support formats -- e.g., MathML. This is unlike
      virtually every standard documentation and publication language, even
      pre-Web. It continues to rely on legacy, regularly conflicting, Office
      8/9/10/11-based attributes, some not available as full context+style in
      the OOXML document. This contributes heavily to the bloat of the OOXML
      specification, while not being remotely as reproducible as ODF.

      Further Comparison/Perspective...

      ODF is based on the legacy of StarOffice, which actually pre-dates
      Microsoft Office (and has always had better integration and feature
      support, especially for the Internet). Given that StarOffice "made the
      switch," Microsoft's decision not to switch to supporting other,
      existing standards is purposeful in comparison. MathML is probably the
      biggest example, which leverages broad compatibility (e.g., even TeX
      interchange) and should have been a mandatory move from an engineering
      perspective.

      2. Avoids standardization: Lack of scrutiny in process

      Per page, specification has been scrutinized 1/100th less than Open
      Document Format (ODF). It is 10 larger and has undergone 1/10th the
      time period for review by ISO. Ironic that a large organization can
      spend less and prove far less than a coalition of not just open source
      developers, but sister standardization organizations to the ISO (e.g.,
      OASIS, W3C) and industry leaders in large, major documentation.

      1. Biggest Issue: Implementation does not match specification

      Office 12 (2007) implementation does _not_ match Office OpenXML
      specification. A standard that presented, but not implemented, let
      alone not even intended and never will be implemented, is not a
      standard. It is XML, which is standard for creating standards, not any
      indicator of an actual, open standard. As an additional note, even
      Microsoft Office 12 (2008) for Mac lacks the VBScript, so its
      compatibility, "as implemented," is even worsened.

      As I always say, "Microsoft Office for Linux would be as incompatible as
      Microsoft Office for Mac, especially when sending documents back to
      Microsoft Office for Windows users." Microsoft itself has proven it
      cannot even offer a compatible implementation between several versions
      on Windows (Win32), let alone to other platforms such as Mac and its
      own, inevitable Win64 API.
      View article »
Loading...
Symbols:
Authors:
Quick Links:
Contribute an Article Become a Seeking Alpha Contributor

Transcripts

More Transcripts»