decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Searching for Openness in Microsoft's OOXML and Finding Contradictions
Thursday, January 18 2007 @ 08:38 AM EST

I thought of a friend's ex-husband when I learned this week that despite Microsoft's promises of a new openness and its assertions regarding interoperability for its OOXML (formerly known as OpenXML and also known as EOOXML) and despite having offered it as a *standard*, it seems that it's another case of promises, promises. From what I've been reading, which I'll share with you, I think it's time to ask ourselves some serious questions: does OOXML really qualify as a standard? Or is it yet another monopoly-enabler in the guise of a standard?

It's a good time to ask, because it turns out that we are right now in the window of time where contradictions in the OOXML standard can be reported by member bodies of the ISO/IEC Joint Technical Committee 1. February 5 is the deadline, so now is the time to bring such to their attention. Some have already found some contradictions, and perhaps you will know of more to add to the list. If so, put them in a comment here or on either of two new page we've set up on GrokDoc, EOOXML at JTC-1 and EOOXML Objections wiki pages, each a work in progress. You'll find abundant resources there for further study and consideration. Marbux has also written up an explanation of the ISO process, which I'll put at the very end.

The bottom line: Because of the apparently unresolvable contradictions being discovered, the questions being asked are whether ISO should reject EOOXML from the fast-track process and instead use the regular process, and whether, if there can be no resolution of some of the contradictions discovered, ISO should accept the specification at all. Is the "fast track" process even appropriate when there are such questions, and more, in the air? Is the Ecma process itself flawed, in that it allows, even mandates, conformance with a single vendor's file formats? Let me explain what I mean by contradictions and I'll tell you about my friend's ex and how he fits in to all this.

The Novell-Microsoft Deal: Interoperability for Whom?

First, though, let me address the Novell-Microsoft deal, the part about interoperability. We've heard much talk about how it will lead to greater interoperability for everyone, specifically with OpenXML (or OOXML or whatever it's called this week). What's the matter with the naysayers? Don't we appreciate that Microsoft is finally opening up and embracing openness? This is good for us all in the community, I've read. I suppose they'll tell that to the EU Commission too. So that's the happy talk. But read this, Jeff Jaffe's Blog. Does it sound to you like Novell plans on sharing on an even playing field?

In my last posting, I defined Novell’s technical strategy as:

The world’s best and most interoperable Linux surrounded with management services that leverage our footprint to build a business solving customer problems in heterogeneous systems management.

If Novell is the "most interoperable" Linux, how does that work? Obviously, they don't plan to share. And in fact, Jaffe goes on to explain Novell's differentiation strategy, including this relevant slip:

And on the desktop side. XGL graphics. Wobbly windows. 3 dimensional windows. Search. Media players. Plug and play. Interoperability. Almost a never ending list.

So, they plan to be the only one in the Linux world that can actually interoperate with Microsoft. How do you think they will achieve that? By sharing? On the contrary, they already market themselves as uniquely interoperable, which means they get to interoperate and you don't, unless you are their paying customer. Competitors in the market need not apply:

Novell is the company which stands at the nexus of both of these key platforms. (In addition to bringing the NetWare base forward on SUSE Linux Enterprise Server as part of Open Enterprise Server.)

Why is that? Only Novell has Microsoft’s endorsement as its partner to drive Linux-Windows interoperability. So – of the Linux vendors - only we can speak authoritatively about Windows.

See? "Only Novell" can do this. That isn't interoperability, in the sense that you'd expect from a standard, is it? It's just another Microsoft partner, maintaining the Microsoft unwillingness to share technical information with real competitors, to my eyes. Why would you even need the interoperability work between Novell and Microsoft, if Microsoft planned to offer a standard the whole world could use equally? Isn't that what a standard is supposed to mean?

Philanderer's Promises

Now, about my friend's ex. Did you ever have a friend or relative who married a philandering ladies man? I did. My friend married one years ago, and I still remember trying to warn her. Guys like that generally leave quite a wake as they put-put through life's waters, and I had learned about his ways from someone. So I naturally told my good friend.

If you've ever had a similar experience, you know exactly what happened. She told me I was wrong, she didn't believe it, and to mind my own business. And the parts that she couldn't deny because there was incontrovertible proof? He'd changed. He'd told her that it was all in the past. Now that he'd met her, he was a changed man. So they got married, she barely spoke to me for two years, after which she told me that everything I'd told her had proven true, and they were getting a divorce.

How do guys like that do it? How do they make good-hearted women believe that they will straighten up and fly right and get them to agree to marry them? Vanity? Inexperience? The blinding power of love? I have no idea, but I observed that creative and convincing half-truths and even lies play a role. If the wife finds lipstick on his collar, he'll tell her with urgent "sincerity" -- nay, tears in his eyes and an outraged tremor in his voice, indicating his pain that she'd even think of such a thing as infidelity -- that a co-worker had an epileptic fit in the cubicle next to his and he ran in to catch her just in time to keep her head from hitting the desk as she fell. He naturally had to hold on to her really hard, because she was thrashing about so much, and the lipstick probably got on his collar then. And if she's a dope, she'll believe him.

Now, I believe in the regenerative power of love as much as the next guy, but it has always seemed to me that you can predict a guy's future conduct by prior behavior in 99% of all cases. Men like Donald Trump or Magic Johnson are more honest about it, but to me that's not such a bargain either, considering what they might be bringing home. But ethically, it's certain preferable to just tell the woman up front, that you have no intention of being faithful. That way at least you don't destroy a trusting heart.

Microsoft's Record

Now, when it comes to Microsoft, I think we can safely say that it too has left quite a wake behind it as it has conducted business. We learned yesterday that the plaintiffs in Comes v. Microsoft, the antitrust trial going on right now in Iowa, believe they have found in discovery evidence that Microsoft has failed to turn over APIs to competitors. Are you surprised? Microsoft was told to do that in 2002, in the Final Judgment. It's now 2007. Microsoft is still negotiating with the authorities overseeing compliance about when it really, really, really, no more excuses, has to come up with the documentation. If you read the incremental status reports, they are a positive hoot, particularly if you start with 2002 and read them all, one after another. Here's a fairly recent sample Status Report [PDF]:

Plaintiffs are surprised that Microsoft believes the rewrite project will take as long as envisioned.

Yes, friends. Lots of happy talk of promises, but very little on the table. Not only did Microsoft get a two-year delay to do a rewrite, now it expresses it may not be able to meet the new deadline either. It seems documentation is very, very hard for Microsoft. Here's a section from a 2003 status report [PDF]:

Plaintiffs are most concerned with Microsoft’s implementation of the requirement of Section III.E that it license certain Communications Protocols on reasonable and nondiscriminatory (“RAND”) terms. Plaintiffs note that Microsoft was required to do so in a timely manner, i.e., “[s]tarting three months after the entry of this Final Judgment . . . .” New York v. Microsoft Corp., 224 F. Supp. 2d 76, 173, 269 (D.D.C. 2002). Implementation of RAND terms is of particular concern to Plaintiffs because Section III.E was intended by the Court to be the “most forward-looking provision in the Court's remedy” and directed toward “unfettering the market and restoring competition.” Id. at 226; see also United States v. Microsoft, 231 F. Supp. 2d at 191-92 (recognizing that Section III.E is prospective and “particularly warranted in this case given the rapid pace of change in the software industry[;]” and stating that without it and other prospective provisions “it is quite possible that the core of the decree would prove prematurely obsolete”). As noted above, at Plaintiffs’ urging, Microsoft has made, and has stated that it will continue to make, changes to the MCPP terms. While Plaintiffs are continuing to work with Microsoft to improve the MCPP so that the Communications Protocols are licensed under RAND terms, Plaintiffs recognize that further steps may need to be taken, either pursuant to agreement or order of the Court, to account for Microsoft's delayed implementation.

It's now 2007. How are they doing with that delayed implementation? Read this piece of work [PDF], the "Supplemental Status Report on Microsoft’s Compliance with the Final Judgments", dated September 2006. Microsoft still is making qualified promises to deliver, all these years later:

As Microsoft has indicated to the TC, the schedule described above is aggressive and represents a commitment by Microsoft to delivering rewritten documentation of the highest quality as soon as practicable....

While Microsoft is fully committed to achieving the milestones set forth in the above schedule, it also recognizes that changes to this aggressive schedule remain possible (both over the next month as the schedule is being finalized and as the project continues) in order to incorporate additional feedback from the TC and to account for other unforeseen obstacles. Accordingly, Microsoft will stay in regular contact with the TC and the Plaintiffs regarding the need for adjustments in the schedule and will update the Court with respect to any changes.

Who are they kidding, aside from the monitoring folks, that is? Not me. To me, it's like lipstick on the collar. Again. I get the distinct impression, looking beyond what Microsoft says and concentrating on what it does, that Microsoft has no intention of sharing APIs to the extent it can help it or postpone it.

The EU Commission has been telling Microsoft to do the same thing, share APIs, even fining the company for not complying. The EU decision gave Microsoft 120 days to turn over APIs:

"Microsoft abused its market power by deliberately restricting interoperability between Windows PCs and non-Microsoft work group servers, and by tying its Windows Media Player (WMP), a product where it faced competition, with its ubiquitous Windows operating system. . . .

That was March of 2004. Do they have them? Microsoft's response at the time, from attorney Brad Smith, as reported by Reuters:

"Microsoft General Counsel Brad Smith said on Wednesday the European Commission's decision amounted to a 'compulsory licence' of the firm's intellectual property rights within Europe. 'We believe that will infringe our IP rights in Europe and it also violates the international treaty obligations pursuant to its (the EU's) membership of the WTO (World Trade Organisation),' he told a conference call."

And read Microsoft's objections to the EU Commission's complaint that documentation Microsoft turned over was useless. Microsoft is "fully committed to compliance", it wrote. But once again, it was somehow unable to turn over documentation that was useful. Here's what I wrote about the objections:

Reading the Microsoft reply to the criticisms of its documentation makes it obvious what the Trustee, Neil Barrett, was talking about. It seems that there was no way to follow the documentation without reading other books and white papers, not written by Microsoft, and looking up standards protocols elsewhere, etc. and trying to figure it out yourself. On page 2 of Annex 5, for example, you find out that the documentation refers to "existing engineering art" meaning books like "Active Directory Cookbook" and "Building LDAP-Enabled Applications". Using those books and white papers, the engineer, they say, can "scope his solution." From the "art" the engineer then makes a list of protocols his design will need to implement. Then he compares that list to the list of protocols Microsoft is offering to license, to find out if he needs documentation from Microsoft or can just implement from existing art entirely, etc. This is all perfectly normal, to hear Microsoft's apologists tell it, in documentation of this type. Honestly, it's a sketch. I'm not an expert, of course, but it left me rolling my eyes. That could just be because there's a little water under that bridge. But I came away with the distinct impression that Microsoft would prefer not to reveal anything it doesn't have to. Their view is that competent engineers are assumed to have a foundation of knowledge of Microsoft ways or the ability to bone up on the subject.

Well, that didn't fly with the EU Commission, and the dance continues. In that setting too, we've seen delay. Now, Microsoft claims it has seen the light and changed its ways. OpenXML is the way forward. Microsoft is promising that its OOXML is open, an open standard. Yes, sirree, what could be better than openness and interoperability? And you believe them? Based on what? I feel like I'm talking to my friend again, trying to talk her out of marrying a man who wasn't being truthful with her (Cf. this article on some water under the interoperability bridge).

Contradictions Found Already

You may have seen Andy Updegrove's article on contradictions in Microsoft's OOXML, which I put in News Picks. Here are some contradictions he reported:

  • OOXML does not conform to ISO 8601:2004 "Representation of Dates and Times." Instead, OOXML section 3.17.4.1, "Date Representation," on page 3305, requires that implementations replicate a Microsoft bug that dictates that 1900 is a leap year, which in fact it isn't. Similarly, in order to comply with OOXML, your product would be required to use the WEEKDAY() spreadsheet function, and therefore assign incorrect dates to some days of the week, and also miscalculate the number of days between certain dates.
  • OOXML does not follow ISO 639 "Codes for the Representation of Names and Languages."
  • Similarly, 6.2.3.17 "Embedded Object Alternate Image Requests Types (page 5679) and section 6.4.3.1 "Clipboard Format Types" (page 5738) refer back to Windows Metafiles or Enhanced Metafiles – each of which are proprietary formats that have hard-coded dependencies on the Windows operating system itself.
  • OOXML also apparently violates section 2.14 of the ISO/IEC Directives, Part 1, in that not all of what it takes to implement OOXML appears to be covered by Microsoft's patent pledge, in two respects. First, the pledge does not explicitly cover material that is referenced, but not included in the specification, and second, the Microsoft patent commitment does not cover optional features. Sections of OOXML that are not fully described include those that require compliant implementations to mimic the behavior of Microsoft products, such as those products and capabilities referred to above (OLE, etc.) Microsoft will need to clarify whether its patent commitment will in fact extend to these requirements.

If you wish to help find more, some keywords Marbux suggested to me are:

bitmask, Windows, application-defined, legacy, binary, blob, base64, signature, encrypt, MSDN, Word, Excel,PowerPoint, Internet Explorer, SQL Server, SharePoint, might, compatible, undefined, OLE, DDE, COM, ActiveX, outside the scope, internal, SDK, .NET, device

In addition, you can search for the the text of the "guidance" quoted by Ben Langhinrichs.

And here's Marbux's explanation of the ISO process, some legal issues regarding standards, why contradictions matter, the significance of the February 5th deadline, and some more examples of contradictions, all from his point of view:

**************************

Why Fast-Tracking OOXML is a Mistake
~ by Marbux

February 5, 2007 is a critical deadline for the future of office productivity software. That is the date by which national standards bodies must submit any objections to fast-track processing of the Microsoft Office Open XML specification by the ISO/IEC international standards body.

Only qualified "P" member bodies of the ISO/IEC Joint Technical Committee 1 ("JTC-1") have legal standing to submit such objections. Fast-track processing is the default JTC-1 status for the proposed Ecma-376 standard, more informally known as the Ecma Office Open XML ("EOOXML") standard. The default fast-tracking status can only be changed if a JTC-1 member national standards body submits objections, forcing a vote. Furthermore, there are far fewer opportunities for EOOXML's revision or to block its adoption by ISO/IEC unless EOOXML is successfully derailed from the JTC-1 fast-track procedures. 1

Despite the fact that no full-featured reference application is yet available for testing and review purposes and despite compelling evidence of EOOXML's unusually over-hasty preparation, the 6,039-page specification was submitted to JTC-1 for fast-track processing on January 5, 2007, providing national standards bodies a single month for detailed review and testing of the specification, and for filing of potential objections.

Can national bodies competently test and evaluate the EOOXML specification by February 5 or will one or more of them file objections to EOOXML fast-track processing? A few representative examples will provide a hint of the technical scope of the problem JTC-1 member bodies are facing.

File formats with no specification

The EOOXML specification (page 10) 2 states the ostensible goal of the proposed EOOXML ISO standard:

"The goal is to enable the implementation of the Office Open XML formats by the widest set of tools and platforms, fostering interoperability across office productivity applications and line-of-business systems, as well as to support and strengthen document archival and preservation, all in a way that is fully compatible with the large existing investments in Microsoft Office documents.

Indeed, the need for "compatibility" with legacy Microsoft Office file formats is the only justification Ecma offers for a proposed standard that duplicates and overlaps functionality with ISO/IEC 26300, the OpenDocument standard. That duplication and overlap is sufficient in and of itself to raise cognizable grounds for national bodies to object. Agreement on Technical Barriers to Trade, Annex 3 section H (members "shall make every effort to avoid duplication of, or overlap with … the work of relevant international or regional standardizing bodies"); see also ISO primary goal [PDF] of "one standard, one test, and one conformity assessment procedure accepted everywhere.”

However, the specifications for those legacy Microsoft file formats — the sole justification offered for duplicating the functionality of the OpenDocument standard — appear nowhere in the EOOXML specification and are unavailable to other developers. 3 Yet those formats' implementation is mandatory for conformance with the specification. How then, are national bodies to verify whether a duplicative standard is in fact necessary and can be implemented by all vendors? Apparently all of the claimed carefully-engineered compatibility with billions of legacy Microsoft files is reserved for the exclusive use of a single software vendor, Microsoft.

JTC-1's role includes ensuring that such vendor favoritism does not creep into the preparation of international open standards. Agreement on Technical Barriers to Trade, supra, section 2.2 ("[m]embers shall ensure that technical regulations are not prepared, adopted or applied with a view to or with the effect of creating unnecessary obstacles to international trade"); ISO/IEC JTC-1 Directives, section 11.1.2 (members may appeal JTC-1 action or inaction that is "[n]ot in the best interests of international trade and commerce"). A single vendor's development requirements do not necessarily create a market requirement for a duplicative standard, particularly when a proposed standard would have "the effect of" granting a single vendor a monopoly in the full-fidelity conversion of billions of legacy files to and from the supposedly open EOOXML.

The unavailability of the specifications for virtually all of the the legacy file formats also clashes irreconcilably with the verifiability requirements of section A.4 of Annex A to IEC Directives, Rules for the structure and drafting of International Standards, Part 2, ("[w]hatever the aims of a product standard, only such requirements shall be included as can be verified"). If compatibility with and implementations of the specifications for those legacy formats are mandatory for conformance with the proposed standard, disclosure of the specifications for the legacy file formats is necessary even to consider whether EOOXML achieves Ecma's stated goal of compatibility with those formats.

Vendor-specific application dependencies

The EOOXML specification is inappropriately replete with dependencies on a single vendor's software. As an example, "autoSpaceLikeWord95" (page 2161) merely defines semantics in reference to a legacy application whose specific behavior is nowhere specified. Instead, vendors are repeatedly urged to study the referenced applications to determine appropriate behavior. But no relevant specification is available for other developers to use and Microsoft's Open Specification Promise grants no right to decompile and reverse engineer the company's legacy applications. Such vendor-specific application dependencies create rather than remove "unnecessary obstacles to international trade" within the meaning of the Agreement on Technical Barriers to Trade, section 2.2, supra, inappropriately bestowing an enormous competitive advantage for a single vendor and rendering EOOXML ineligible for the status of an international open standard within the meaning of the relevant treaties.

Still other such application-specific tags and citations to the page numbers where they can be found were collected by Ben Langhinrichs along with the mentioned Ecma "guidance" for other developers to study the behavior of the host of legacy applications to implement the tags:

I was reading through the Office Open XML draft yesterday, and came across a whole host of scary elements. These are all from Part 4 of the draft specs, entitled Markup Language Reference, and, yes, those are the real page numbers. It is not a short documemt, and this may partly explain why. For example:
* autoSpaceLikeWord95 (Emulate Word 95 Full Width Character Spacing) - pages 1378-1379
* footnoteLayoutLikeWW8 (Emulate Word 6.x/95/97 Footnote Placement) - pages 1416-1417
* lineWrapLikeWord6 (Emulate Word 6.0 Line Wrapping for East Asian Text) - pages 1426-1427
* mwSmallCaps (Emulate Word 5.x for Macintosh Small Caps Formatting) - pages 1427-1429
* shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects) - pages 1442-1443
* suppressTopSpacingWP (Emulate WordPerfect 5.x Line Spacing) - pages 1462-1464
* truncateFontHeightsLikeWP6 (Emulate WordPerfect 6.x Font Height Calculation) - pages 1467-1468
* useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules) - pages 1481-1482
* useWord97LineBreakRules (Emulate Word 97 East Asian Line Breaking) - pages 1482-1483
* wpJustification (Emulate WordPerfect 6.x Paragraph Justification) - pages 1483-1485

There are many more which relate to various parameters which are deprecated... Now, on the one hand, Microsoft is to be praised for its careful presevation of attributes, features and behaviors which exist not only in its own earlier versions but also in those of competitive products. Good show! On the other hand, these do not belong in an open standard! This is a very clear case of vendor specific implementation leaking through into what Microsoft claims to be an open standard....

I have no objection to the goal of fully supporting legacy MS Office documents. I fully respect that as a goal for Microsoft. It just doesn't make it an open standard, it makes it a speciofication for MS Office....

To repeat, as I have said here and elsewhere, when MS introduced this as a full specification of the MS XML storage, they did a good thing. But that good thing does not then cancel out the bad idea of declaring this an "open standard". It isn't, and no matter how many times you defend their support of legacy documents, it won't change that. I also defend their support of legacy documents, and support their full specification of it, but not in a public standard.

There are many more that can be quickly identified by performing a document search of the specification for the text of the "guidance." The barriers to implementation for other developers posed by such tags have been discussed by Robert Weir in some depth:

It is quite possible to write a standard that allows only a single implementation. By focusing entirely on the capabilities of a single application and documenting it in infuriatingly useless detail, you can easily create a “Standard of One”. ...

Here are some other examples of where the OOXML “Standard” has bloated its specification with features that no one but Microsoft will be able to interpret:

2.15.3.6 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing)

This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 95) when determining the spacing between full-width East Asian characters in a document's content.

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

...What should we make of that? Not only must an interoperable OOXML application support Word 12's style of spacing, but it must also support a different way of doing it in Word 95. And by the way, Microsoft is not going to tell you how it was done in Word 95, even though they are the only ones in a position to do so.

Bob Sutor has discussed the harm to be inflicted by the cumulative mass of vendor-specific application dependencies in EOOXML:

Who will implement Open XML correctly and fully? Maybe Microsoft. Why? Since it is essentially a dump into XML of all the data needed for all the functionality of their Office products and since those products are proprietary, only they will understand any nuances that go beyond the spec....

Fully and correctly implementing Open XML will require the cloning of a large portion of Microsoft’s product. Best of luck doing that, especially since they have over a decade head start. Also, since they have avoided using industry standards like SVG and MathML, you’ll have to reimplement Microsoft’s flavor of many things. You had better start now. So therefore I conclude that while Microsoft may end up supporting most of Open XML (and we’ll have to see the final products to see how much and how correctly), other products will likely only end up supporting a subset....

This means that data in Open XML form will be largely sucked into the Microsoft ecosystem but very little will escape for full and practical use elsewhere. In my opinion, suggesting “choice” among ODF and Open XML by governments who are seeking control, true choice, and interoperability is nothing more than maintaining the status quo — a requirement for Microsoft products under the guise of supporting a “standard.” All standards are not the same and providing support for all standards is not the same.

In a later article Sutor has offered a layman-level explanation with graphical depictions of the involved market forces:

When a single vendor or software provider makes it easier to connect primarily to his or her software, this is more properly called intraoperability.

In the intraoperability situation, one product is somehow central and dominant, either by marketshare, attitude, or acquiescence. The connectivity is supported by protocols and data formats that favor the central software, and those are often prescribed by the provider. The goal is to suck all important data and processing into the central software ecosystem, and it is in this sense that we use the prefix “intra.” ...

You may need special licensing to use the protocols or formats, and the central vendor may even try to standardize the specifications with weird rules stating that you can’t break compatibility with their products. The licensing might even prevent the use of the formats, protocols, or even a user interface by competitors or creators of open source software.

Just how thoroughly the EOOXML specification is dependent on a single vendor's applications 4 is well illustrated by the spreadsheet specification's "Date and Times" requirement (pages 3305-6). That section requires that spreadsheet dates treat the year 1900 as a leap year, which contradicts the Gregorian Calendar. This raises severe interoperability issues when interfacing with the many other developers' office suites, other office software, and development libraries that do properly implement the Gregorian Calendar. The specification straightforwardly acknowledges that this behavior is required for "legacy reasons." Indeed, it is a known bug work-around in the Microsoft Excel spreadsheet program, which would be imposed on other developers and software users by the EOOXML specification's adoption as an ISO standard, a problem discussed in more depth by Rob Weir:

By mandating the perpetuation of this bug, we're asking for trouble. Date libraries in modern programming languages like C, C++, Java, Python, Ruby will all calculate dates correctly according to the Gregorian Calendar. So any interpretation of dates in OOXML files in these languages will be off by one day unless the author of the software adds their own workaround to their code to account for Excel's bug. Certainly some will make the “correction” properly, at their own expense. But many will not, perhaps because they did not see it deep within the 6,000 page specification.

The EOOXML specification also creates barriers to interoperability where such barriers seem gratuitous. For example, the "Workbook Protection" section (page 2698) defines an encryption algorithm by including several pages of C-language source code that appears to have byte-ordering dependencies that will produce different results on different machine architectures. Likewise, the "Clipboard Data" section (page 5905) defines a schema type that can encode clipboard format values for Windows and the Macintosh, but appears not to allow for use by other operating systems. Yet another is "Conditional Formatting Bitmask" (page 2478), which mandates the use of bitmasks. Some of the standard XML processing tools like XSLT lack bitwise operators, making the use of such data impossible when converting to other XML formats.

For a multitude of reasons such as those summarized above, one must question Ecma's undisclosed reasons for selectively including a mass of required behaviors of implementing applications for "legacy reasons" whilst simultaneously disclaiming any responsibility to specify critical application functionality needed by other developers to fully implement the specification (page 13):

Existing files and applications exercise a broad range of formats and functionality that, if required by the conformance definition, would add an impractical amount of bulk to This Standard and could inadvertently obligate new applications to implement a prohibitive amount of functionality. This issue is caused by the breadth of currently available functionality and is compounded by the existence of legacy formats.

That is a somewhat less-than-compelling argument for withholding specifications required to be implemented by the repeated usage of the mandatory "shall" and "shall not" that appears throughout the specification. Annex H to ISO Directives, Part 2, supra (e.g., "shall" to be used only “to indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted” ); see also extended analysis by Robert Weir ("The OOXML specification, at 6,000+ pages has now just sucked in the complexity of one or more versions of HTML, MHTML, RTF and WordProcessingML. It requires that a conformant application understand these formats, but forbids a conformant application from producing them."); Microsoft Open Specification Promise (patent rights granted extend only to "required portions of the Covered Specification that are described in detail and not merely referenced in such Specification").

4. Conclusion

EOOXML was crippled from the very beginning of the Ecma standardization process by an inappropriate charter requiring compatibility with only a single vendor's file formats:

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 [Microsoft] Office Open XML Formats.

That charter language forbade any deviation from a single vendor's specifications in development of the EOOXML "open" standard. Not surprisingly, most major software houses boycotted the pre-rigged work program and Ecma included in EOOXML no specifications for the interoperability of other vendors' applications that are based on the existing ISO OpenDocument standard. Furthermore, Microsoft's Chief Executive Officer has publicly stated that Microsoft Office — and by implication EOOXML — will only "achieve the level of interoperability [with OpenDocument] that customers can work with." That ignores, of course, the market requirement of full fidelity interoperability in automated business processes. There were no full-featured reference applications available for EOOXML testing and evaluation purposes by national bodies at the time of EOOXML's submission to JTC-1 that I am aware of.

In contrast, ISO/IEC's highly-interoperable OpenDocument standard has been widely implemented across the software industry and has been extensively put into service around the world. See e.g., this page that tracks government adoption of OpenDocument worldwide, current as of May of 2006. EOOXML has no comparable track record of support and adoption.

ISO/IEC's reputation is on the line in its processing of the EOOXML proposal. See ISO/IEC JTC-1 Directives, supra sections 11.1.2 and .3 (any JTC-1 member may appeal if a draft standard "may be detrimental to the reputation of IEC or ISO"). The 6,039-page EOOXML specification warrants close scrutiny that cannot feasibly be achieved within the time frames mandated by ISO fast-track standardization procedures.

My understanding is that governments' software procurement tenders are required to specify the existing OpenDocument standard absent exceptional circumstances, pursuant to the international Agreement on Government Procurement Article VI section 2 (technical specifications shall "be based on international standards, where such exist"). If that understanding is correct, Microsoft must support OpenDocument or give up the pretense that its "standard" is anything but its own private international standard.




5. Notes

1 There is an overview of relevant law and procedures here.

2 Because the specification is not consistently paginated throughout, all references are to the PDF file page numbers.

3 Microsoft's failure to disclose the specifications for its legacy office file formats came under antitrust investigation in Europe. The relevant specifications are not available to other software developers.

4 See also e.g., "Disable Features Not Supported by Target Browser" section (page 2120), detailing requirements designed to optimize output for various versions of Microsoft Internet Explorer and disregarding entirely MSIE's main competing product, Mozilla Firefox, as well as many other alternative browsers.


  


Searching for Openness in Microsoft's OOXML and Finding Contradictions | 221 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
A standard that "cannot be faithfully placed into narrative"!?!
Authored by: Anonymous on Thursday, January 18 2007 @ 09:03 AM EST
Huh, how can any standard require a feature "which involves many possible
behaviors and cannot be faithfully placed into narrative for this Office Open
XML Standard."

Why isn't that grounds enough to kill it - since the standard doesn't even
attempt to describe what it's standardizing?

[ Reply to This | # ]

OT Here, please
Authored by: overshoot on Thursday, January 18 2007 @ 09:03 AM EST
Instructions in red at bottom for posting clickable HTML.

[ Reply to This | # ]

Corrections here, please
Authored by: overshoot on Thursday, January 18 2007 @ 09:10 AM EST
Everyone maks a mistake from thyme to thyme.

[ Reply to This | # ]

Novell not sharing?
Authored by: Anonymous on Thursday, January 18 2007 @ 09:27 AM EST
Novell has said from day one, when they announced the interoperability agreement
with MS, that they would donate all of the Open Office plug-in code that they
plan to develop under this agreement back to OpenOffice.org.

Just because Novell now says that they plan on being the "most
interoperable" Linux, this doesn't mean that they plan to achieve that goal
by "not sharing" their interperability code.

Look at all of the varied Linux distributions available today. They all choose
to include and exclude various open source applications with their
distributions. I challenge you to find any Linux distribution that does not
claim to be the "best Linux distribution" for some reason or another.
Are any of them achieving their claims by "not sharing"? Even
non-commercial Linux distributions need community support to maintain interest
and keep contributors contributing, so they all practice "marketing
hype" whether it is a commercial or a non-commercial distribution.

Granted, if no one else chooses to use Novell's contributions in their
distributions of Linux and/or Open Office because of paranoia, then Novell will
be the "most compatible" Linux distribution, but it won't be because
Novell didn't offer to share, it will be because no one else took them up on
their offer.

[ Reply to This | # ]

Catch 22?
Authored by: Jude on Thursday, January 18 2007 @ 09:35 AM EST
ISTR that Microsoft's "patent pledge" only applies to applications
which conform to the OOXML spec. Since it appears that no application can
actually implement the full spec, does this mean the patent pledge is useless?

[ Reply to This | # ]

Reject, because it rejects MANY existing standards
Authored by: Anonymous on Thursday, January 18 2007 @ 09:49 AM EST
The Microsoft XML format (let's call it what it REALLY is) should be REJECTED because it completely ignores many current standards. Instead, it re-implements incompatible formats at nearly every turn. This creates a large and completely unnecessary barrier to trade. Indeed, that's one of the main reasons it's so long - because it willfully violates lots of other standards that are ALREADY widespread in the industry IN ADDITION to OpenDocument.

There are already standards that support functionality needed in office documents, including MathML (Mathematical equations in XML), SVG (Vector graphics in XML), XForms, XPath, and XLinks. OpenDocument reuses these. Microsoft's XML format does not.

For example, OpenDocument doesn't even spend half a page on mathematical formulas (for presentation). It just says "use MathML". Which means that instantly any OpenDocument implementation can interoperate with the many other products that work specifically with MathML. Microsoft's document takes page after page to do the same... and not as well, because they were rushed to generate a 6000-page document in less than a year, with no effective industry review. (Most of the industry boycotted the ECMA process, since it was so obviously biased for a single vendor.)

In contrast, Microsoft's XML format can work with only... Microsoft! Everyone else has to create implementations for a non-standard, that's embedded in a larger single-vendor specification, just to work with it?

Let's imagine that ISO accepts this. We now have a new precedent: There's no need to accept any ISO standards. If you want to create a proprietary format, just create a format that includes most of the capabilities of a pre-existing format, and then submit it to ISO via ECMA. With this new process, any standard can be killed in a year by a company that wants to have proprietary control over one. Imagine a world where standards are replaced every year with incompatible standards by new single-vendor specifications - is that really sensible? If the goal is to have worldwide, widely-used standards, then this needs to be rejected as a precedent-setting measure.

This non-compliance with a large number of pre-existing standards is a barrier to trade, and the Microsoft XML format should be rejected for this reason.

[ Reply to This | # ]

Are member positions known?
Authored by: Anonymous on Thursday, January 18 2007 @ 09:51 AM EST

Only qualified "P" member bodies of the ISO/IEC Joint Technical Committee 1 ("JTC-1") have legal standing to submit such objections.

This might not be good. As I understand it, the "member bodies" are mostly national standardization committees. Does anyone know the position any of these bodies are likely to take?

[ Reply to This | # ]

The battle is on...
Authored by: Anonymous on Thursday, January 18 2007 @ 09:53 AM EST
If it were the British North American Colonies during the 1700s who were being
forced to pay double taxes for tea and sugar, we would hear the cry...
The British are coming!
The British are coming!
How would we react today if we heard a certain horse and rider as they flew past
our houses warning us to act before it was too late?

Today, if we don't act we will all be forced to buy a version of MS Office 2007
(and all versions after that), just to be able to interact with others! If
that is not double taxing for no logical reason what is?

Businesses, schools, govenments, and individuals who don't act to alert folks of
MS OFFICE 2007 format monopoly move by Microsoft, will in the end, be forced to
buy such upgrades as well. Simply because Microsoft needs more money! Sadly,
this reason is NOT because we need another word processor!

At this point in time, everyone has to get on their horse and ride.

This new format battle, that is focused on what is truly an OPEN FORMAT, is the
key to winning the war... then we can return to living normal lives again
without ever having to think that we need JUST Microsoft software to exist in a
digital world.

As citizens who care, we must educate and spread the word. Someday, maybe with
our HONEST efforts folks will come to understand that a certain emperor has no
cloths on at all! And we all know who that is!

It is all about education... and relating to folks how freedom of software
equated directly to free speech.

As - If you have the right software then you can communicate in the right
digital circles with right others who also have the same right software too...!
If, there is a price to pay for the software (monetary or exclusionary), then
there is a percentage of the public who can't afford it, and who pay much more
then we understand (I know of folks who have a hard time putting food on the
table, and asking them to buy software in a certain format so that their kids
can hand in homework that is required in that format is expensive and impossible
to afford).

However...
IF, there is a standard FORMAT used where both expensive software and free (no
price) software are BOTH able to use the same file format... then, files can be
transferred between different people of different ideas who use different
computers, using different operating systems, and even using different word
processing and other applications! Children can hand in homework created on
different computers, operating systems, and applications where this homework
that can then be read then by teachers who are using even different computers,
different operating systems and different software aplications, meaning that
folks with different systems can FREELY interact. Meannig that in a digital
world where we share ideas in a digital format, that there is no social
inequality, no social injustice... and most important there is NO EXCLUSION that
happens to our children JUST because they don't have the "right
software"! In this digital world, we are all still the same as any child
who are still learning... as we all are learning still of how to best live in
this maturing digital world around us!

Freedom is... what freedom is... and the most basic freedom we have is speech.
Once speech goes digital in a proprietary format sense, then pure freedom of
speech is lost, because it is then no longer free.

Net Neutrality is next.

[ Reply to This | # ]

OpenDocument: Fully supporting legacy MS Office documents
Authored by: Anonymous on Thursday, January 18 2007 @ 10:10 AM EST
The justification for this Microsoft-sponsored format is to "fully support legacy MS Office documents." But OpenDocument can do that nicely; there's no requirement for a Microsoft-unique XML to meet that need.

Some users require that their documents be transferred without data loss to a new format. That's fine. But the new format does not need to be identical to the old one. Indeed, no matter what, the format won't be identical -- it'll be in XML instead of in a binary encoding! But also, it doesn't need to use the awkward encoding scheme applied here.

There are two ways to create a format: create a large number of weird special cases, and note each one, or create a generalized format that can handle the special cases. Where the general approach is used, there's no need for weird special cases to support the legacy format. Yet the legacy format is fully supported by the general case.

That's what OpenDocument provides - the creators have worked hard to create a general-purpose format, so that real documents can slip into it no matter how they were originally formatted. Microsoft's XML format instead creates lots of weird special cases, which only handle their format and CANNOT handle the documents of others. Because OpenDocument is more general, there's more loss going from the general-purpose OpenDocument to the special-purpose Microsoft XML. All by itself, this means that OpenDocument should continue to be the standard, and Microsoft's XML should be rejected wholeheartedly.

If there's anything that Microsoft's XML has that OpenDocument can't do, great.. then let's expand OpenDocument in that area. Starting with the general-purpose standard, and then improving it with general-purpose abilities, is far better than starting with a single-purpose single-vendor specification and trying to make it general-purpose somehow. But a standard should handle the needs of ALL its users... having a specialized standard only for legacy documents for a single vendor makes no sense.

Also, let's admit that this "full fidelity" phrase is very misleading. Microsoft Word, OpenOffice.org, Word Perfect, and most other office suites routinely reformat documents based on factors such as fonts and printers available. If you upgrade Word - or even change the default printer - you are likely to get slightly different word wraps and pagination of results. THIS IS EXPECTED BEHAVIOR. If you don't want that, use PDF.

People who use the word "fidelity" for Microsoft's XML formats are often deceived. People are often mislead into thinking that Microsoft's XML format will guarantee that the word wrap, page breaks, and so on will be identical on all Microsoft platforms. But they're being mislead. It's not true, and it's not SUPPOSED to be true. The Valoris report even specifically noted this. Microsoft's XML format provides a "reasonable" approximation, but there will be some variance in word wrap, page breaks, and that sort of thing. Which means that Microsoft's XML is of no higher fidelity than OpenDocument for legacy documents.

[ Reply to This | # ]

The ISO fast-track record
Authored by: Anonymous on Thursday, January 18 2007 @ 10:14 AM EST
The problem isn't just with ECMA, it is also with the ISO Fast Track procedure - this is designed to rubber stamp submitted standards. The recent history of the C++/CLI standard shows that even the existance of serious contradictions is probably not enough to stop a standard being approved. (See Lif e in The Fast Lane [PDF] for some background.) WRT C++/CLI it would appear that the contradictions will be dealt with at a resolution meeting in April and the standard adopted - although I am not currently aware of any changes to the submitted document. (AlanGriffiths not signed in)

[ Reply to This | # ]

Searching for Openness in Microsoft's OOXML and Finding Contradictions
Authored by: Alan(UK) on Thursday, January 18 2007 @ 11:52 AM EST
What happens if ISO changes ECMA/MS/OOXML? Microsoft will have a non-compliant
Office suite.

[ Reply to This | # ]

The purpose: No-big contracts
Authored by: Anonymous on Thursday, January 18 2007 @ 12:15 PM EST
The purpose of this standard is to make it easy for governments to have single-bid contracts. Reference this specification in your contract, and no other vendor may apply, ever, and expect to win the bid.

More information can be found Bob Sutor's OpenDocument category her e's an openstack entry.

[ Reply to This | # ]

It's a contradiction, all right!
Authored by: Anonymous on Thursday, January 18 2007 @ 12:55 PM EST
OpenDocumentFellowship has a document that defines what a standards "contradiction" is. That's important, because specifications aren't supposed to enter the fast track if there's a serious contradiction.

And this case, there are lots of massive, fatal contradictions that should immediately derail the "fast track" (and really, the whole specification). Let's look at the possible reasons for a contradiction:

  1. confusion of users: Users may be confused by the "term 'open'"; users might think it means that the specification represents some sort of industry consensus, or a specification that is widely implemented by many suppliers, or one with fully open IPR (e.g., so partial implementations and later versions are unencumbered). This is not true. For example, there doesn't seem to be a legal way for others to fully implement it (due copyright on material like graphics borders and EULAs forbidding reverse engineering for inadequately specified pieces). This specification does not meet many of the common definitions of the term "open standard". Users may also confuse the specification with OpenOffice.org, a product that implements OpenDocument instead.
  2. damage to ISO reputation: If it accepts this specification, ISO will be tarred as an organization that can be controlled by any single powerful company, instead of one that strives for broad industry consensus and protection of users' interests. Look at the precedent this sets - if ISO accepts this specification, it means that a rich company can overturn any existing standard (e.g., OpenDocument) simply by buying off a standards organization (ECMA) to accept whatever they write. ISO's key value is in its reputation for impartiality, and should not sully such a valuable reputation for such an obvious ploy.
  3. lack of consistency with existing standards: Obviously this isn't consistent with ISO/IEC 26300 (OpenDocument). Which was approved as an ISO standard in 2006, so it's clearly not obsolete. What's worse, it's completely inconsistent with other standards: MathML, SVG, XForms, and so on.
  4. duplication of existing standards: It duplicates OpenDocument. Completely. There's no "different market" for office documentation; it's all the same market. Indeed, the fact that people are working on bidirectional translators shows that they are the same thing. There's no need for yet another standard for the same thing, unless of course you're trying to ensure that a single vendor controls the format of all office documents.
  5. overlap with existing standards: I wish it were just "overlap". This is essentially a complete duplication of an existing standard, for the sole purpose of enriching a single company (at the expense of competition in the marketplace).

Another problem is that the specification, for all its pages, doesn't get to the meat of the specification. You can't really implement it without "secret sauce" information that only Microsoft has. It's a non-specification specification. It's only so long because they had to re-create incompatible specifications for functions that are open standards elsewhere (like MathML and SVG).

This specification is also grossly immature; even if were not a contradiction, it's not ready. It can't be otherwise:

  1. It was developed in a rush - 6000 pages in less than a year (!). In contrast, OpenDocument development began December 16, 2002 and was approved May 1, 2005. And OpenDocument development was much easier, because they reused standards (like SVG and MathML) wherever they could, instead of recreating things from scratch.
  2. Nearly all office application developers were not involved in the ECMA process (for development OR review), for good reasons. After all, nearly all office application suppliers had spent years working to develop a standard; there was no need to do it again (note that the ECMA process only started many months after OpenDocument had been completed). The ECMA process, by charter, was clearly unfair and tilted towards the whim of a single vendor. And technically, because the specification completely redoes from scratch many standards areas (like MathML and SVG), there are many good reasons to avoid implementing this specification.

There's no terrible harm to Microsoft if ISO rejects fast track status, or even the spec outright. Microsoft can implement the industry-developed international ISO standard (OpenDocument) any time it wants to. If there are problems with the standard, they can be addressed through normal standards processes. But allowing a single company to create its own incompatible, essentially proprietary standard will do great harm to the reputation of all standards bodies.

ISO says its goal is "one standard, one test, and one conformity assessment procedure accepted everywhere.” Do they mean it? Or is that a lie, just another empty claim that can be sold to the highest bidder? Is it possible for an industry to work together for many years to develop and implement a standard, and then as the standard begins to be adopted, for a single vendor to write its own incompatible specification and get ISO's endorsement?

We'll see if ISO can really stand for its principles. I hope, and have reason to believe, that ISO can, and reject the fast track request.

[ Reply to This | # ]

Microsoft != interoperability
Authored by: philc on Thursday, January 18 2007 @ 12:55 PM EST
Microsoft gained its monopoly with the help of extensive use of vendor lockin.
(Remember "DOS ain't done till Lotus won't run"?) Lockin means that
others explicitly can't interoperate. This is the foundation of the monopoly.

Second, Microsoft has in its position everything it needs to interoperate with
Linux. It is capable of doing the work itself. Yet is doesn't and won't. See the
first paragraph.

Their aversion to interoperability is legend. Just look at their behavior in the
EU for one example.

As for Novell, innocent the babes in the woods, they will find out. Nothing will
come of the deal. Microsoft does not benefit from improved interoperability and
they will not suffer it.

In a lot of ways their dislike of interoperability far exceeds their dislike of
the GPL. Think about it.

I don't get it. Microsoft has a long history that is very easy to follow. Anyone
that cares to do a little research can accurately predict how Microsoft will
respond to any given situation. Anyone that has been in the IT industry for a
while can't avoid knowing. They are nothing if not predictable, right down to
the lies to seduce its victims. Yet Novell doesn't see it, even a little bit.

[ Reply to This | # ]

6000 page spec for new, but can't produce spec for old?
Authored by: Anonymous on Thursday, January 18 2007 @ 01:00 PM EST
Isn't it funny that MS can produce a 6000+ specification for a new, proposed
standard, but can't produce the "required by law" specs on already
existing stuff? Maybe the EU enforcement guys need to be made aware that MS
does have the capability, it just is (apparently) focusing on something other
than the required specs...

[ Reply to This | # ]

Philandering Individuals!
Authored by: Anonymous on Thursday, January 18 2007 @ 01:05 PM EST

It's interesting to note that the Merriam-Webster on-line dictionary has the deffintion issolated to males.

As a male, I can attest to the fact that there are plenty of women that fall into the same category. Unfortunately, my very first real relationship in life was with such a woman. My bubble of belief that women were innocent was soundly popped.

As for why they do it? On a philosophical note, why do most people pretend to be someone they aren't when first dating? Recently on public transportation I overheard a conversation between a couple ladies where one pointed out her husband of 10 years recently admitted he never liked camping. Go figure.

If everyone was honest with themselves, they'd be far more likely to find someone compatible. P.J.'s friend's ex, as an example, would probably be happier admitting his chosen lifestyle and finding a woman with the same lifestyle.

I live in a city with a surrounding population of 900,000 people. You can bet there's a good smattering of all kinds of lifestyles. So why are people dis-honest with potential relationships and - more importantly - why are they so dishonest with themselves?

Not a clue! But, it would be nice if PJ had used a term that would probably identify both males and females that choose the same behavior. After all, there are those good-hearted gentlemen like myself that have run into "philandering" females.

RAS

[ Reply to This | # ]

May I just say that this Standards Process sounds like a total crock
Authored by: billyskank on Thursday, January 18 2007 @ 01:08 PM EST
in my humble opinion.

---
It's not the software that's free; it's you.

[ Reply to This | # ]

Searching for Openness in Microsoft's OOXML and Finding Contradictions
Authored by: Anonymous on Thursday, January 18 2007 @ 01:31 PM EST
has anyone been through the ODF and M$XML descriptions to count how many other
ISO (or other international, I'm not sure if there are or not) standards each
one references? And the same for how many programs each one references.

I'd of thought that instead of saying ISO26300 compliant, compared to M$XML
compliant, being able to say ISO26300, ISOxxxxx, ISOxxxxx, etc compliant,
compared with: M$XML, M$Word, M$Excel, M$PowerPoint, WordPerfect, etc compliant
might get the point across.

(move me if I'm in the wrong place)

[ Reply to This | # ]

Short development time == no review and no widespread industry buy-in
Authored by: Anonymous on Thursday, January 18 2007 @ 01:54 PM EST
Microsoft's XML format was created in a year. How'd they manage that? Well,
one way is to skip review; if whatever you say is what happens, then you can
create anything quickly. Another way is to not even TRY to work with other
organizations to create a consensus document. In this case, both occurred.

[ Reply to This | # ]

Microsoft Excel guy on Standards
Authored by: Anonymous on Thursday, January 18 2007 @ 02:30 PM EST
A doc in the Iowa Microsoft case shows what the Excel team thinks of standards.

Q "how would you like to standardize this stuff and work with these ISVs to
make [Excel features] a standard"

A "Why should I work with anyone outsid the company to make their products
better because all it's going to do is help them sell copies that could
otherwise be a Microsoft copy....My job is to make Excel basically, like, the
only application in the world."

http://www.iowaconsumercase.org/010807/PLEX_2456.pdf

[ Reply to This | # ]

required to use the WEEKDAY() spreadsheet function
Authored by: Anonymous on Thursday, January 18 2007 @ 03:19 PM EST
Is an implementation required to use a function that has the same results as
WEEKDAY(), or is it required to actually use the WEEKDAY() function in a
licencesd copy of Excel ?

It would seem to me that this may require everyone to buy Office in order to use
any other word processor that implented OfficeXML even if that other one was
free.

[ Reply to This | # ]

And Seven Layer Torts...
Authored by: tz on Thursday, January 18 2007 @ 03:56 PM EST
ISO occasionally does other complex absurdities like the 7 layer network model,
which TCP/IP doesn't follow so the internet works and interoperates.

But this will make them a laughingstock if they adopt it.

There is nothing intrinsically wrong with a single vendor carefully and fully
documenting something and submitting it for a standard.

But "get leap years wrong" and "do it like Word95 does, whatever
that is" is hardly careful or full.

Proper design (which I don't expect to come from Redmond) has someone write the
spec and find internal contradictions, ambiguities, lacunae, and anything else
BEFORE coding so that each behavior is intentional. Rarely is this fully
realized, but that is the idea.

It looks like Microsoft hacked Office2K+7 to get it out, then tried to document
it (it would be interesting to see if there are any contradictions between what
it does and what the spec says). These engineering notebook scratches were
submitted for fast track approval.

There apparently were still some pluggable holes with open office (someone
pointed out the spreadsheet formulae missed something) but it accomplishes the
same task without all the weird attachments.

Sun said "the computer is the network". It seems with MSFT, "The
application is the specification - oh, and we include legacy apps in that
too". For encryption they also have a source-code dump.

Maybe they didn't expect anyone to read it, but I'm finding it easier to
understand all the quality and security problems with all their software. They
can't even get a critical document clean enough. But they will probably use
marketing or other pressure to get it approved.

ISO and Microsoft might become like the BBB and PayPal. Paypal often locks up
customer's funds and it can be a nightmare to untangle, but they get the highest
BBB rating since they always respond (if not meaningfully) to every complaint.
After I heard that I don't care what the BBB thinks. If ISO approves of Vendor
Blobs, then ISO deserves no respect. Write an RFC.

[ Reply to This | # ]

Nice mind trick on the naming: OOXML
Authored by: Peter Baker on Thursday, January 18 2007 @ 04:00 PM EST
Andy Updegrove hadn't spotted the mind grab either when I emailed him (he found
it interesting): has any of you noticed that OOXML for most people will
translate as OO XML, i.e. OpenOffice XML? That's precisely why it's been called
Office Open XML, nice bit of substitution.

That's a sleigh of mind worth of Derren Brown (if you don't know who he is,
seach YouTube).


---
/// P ///

"I drank WHAT?" - Socrates, 399 BC

[ Reply to This | # ]

delay delay and more delay -- Searching for Openness in Microsoft's OOXML and...
Authored by: Anonymous on Thursday, January 18 2007 @ 04:58 PM EST
Why are we surprised? Where else have we seen this tactic. (Just long enough
to make sure Longhorn, er Vista gets out.) Hint, think of Utah.

[ Reply to This | # ]

Is there any hope?
Authored by: stevenj on Thursday, January 18 2007 @ 04:59 PM EST

According to the article, only "P-members" (national standards bodies like ANSI) are allowed to submit objections to the ISO, and they must do so by February 5, 2007.

Given this, it's not clear what most of us can do to object to this 6000-page "standard" (which is incomplete: it incorporates undocumented behaviors of previous Microsoft software by reference). Is there some public official we should be sending letters to? Even if we bombard the director of ANSI (for US citizens) this week, is there any chance that they will be able to submit a substantive protest by February 5?

[ Reply to This | # ]

NOT SUPPORTED !!!! Searching for Openness in Microsoft's OOXML and Finding Contradictions
Authored by: Anonymous on Thursday, January 18 2007 @ 05:09 PM EST
Auto spacing like word 95. Minor detail here. How can you make sure something
will work the same way a different application does when that particular
application is no longer supported by the vendor. Where are you going to get a
copy of supported Word 95 to verify against?

[ Reply to This | # ]

  • You can't - Authored by: Anonymous on Friday, January 19 2007 @ 10:05 AM EST
Sun should sue for change in the name OOXML
Authored by: Anonymous on Thursday, January 18 2007 @ 05:29 PM EST
I can't help but think that the name Office Open XML was chosen deliberately to
confuse the public by sounding very similar to OpenOffice. Sun should sue over
this. After all if Microsoft can sue over Lindows sounding like Windows, then
Sun can sue over Office Open sounding like OpenOffice.

[ Reply to This | # ]

Searching for Openness in Microsoft's OOXML and Finding Contradictions
Authored by: Anonymous on Friday, January 19 2007 @ 12:17 AM EST
We should influence around us to use more open formats like ODF than MS formats.
It is utterly useless to expect Microsoft will ever open up their APIs much less
their file formats. We must move on. Forget Microsoft.

I have been using OOo, AbiWord, Inkscape and Gnumeric for quite sometime. I find
them much better than that of Microsoft's products. I hope that a well-developed
CAD program will be available soon.

8-)

[ Reply to This | # ]

Searching for Openness in Microsoft's OOXML and Finding Contradictions
Authored by: Anonymous on Friday, January 19 2007 @ 12:18 AM EST
We should influence people around us to use more open formats like ODF than MS
formats. It is utterly useless to expect Microsoft will ever open up their APIs
much less their file formats. We must move on. Forget Microsoft.

I have been using OOo, AbiWord, Inkscape and Gnumeric for quite sometime. I find
them much better than that of Microsoft's products. I hope that a well-developed
CAD program will be available soon.

8-)

[ Reply to This | # ]

Your Philandering friend in-law reminds me of Plamondon's speech
Authored by: darkonc on Friday, January 19 2007 @ 12:53 AM EST
Slashdot just recently had a slashback that referred to A 1996 speech by James Plamondon where he (now, infamously) referred to ISVs as 'pawns in the struggle between platform vendors'. It also uses the metaphor of ISV's as a girl that
"... what you really want to do is have a deep, close and intimate relationship, at least for one night. And you know you just cant let her feel like that, because if you do, it ain't going to happen, right[?] so you have to talk long term and white picket fence and all these other wonderful things, or else you're never going to get what you're really looking for. So you can't let them feel like pawns, no matter how much they really are.
. . . . .

Goals. Microsoft a very goal-driven company. Every six months, hit those objectives. The goal is always the same. Your ... when you're writing your review and your goals for the next six months, your goals should always be worded almost exanctly like this: Establish (whatever it is you're working on, insert here) as the de facto standard in the industry. That's your goal. Now, that's different from an objective. I'll get to objectives
. . . . .

Generally speaking, DRG thindks about ISVs, the rest of the company doesn't, or to the extent that they do, [ISVs are] the enemy, right?`
. . . .

and his answer was very simple. He said, "Why should I work with anyone outside the company to make their products better because all it's going to do is help them sell copies that could otherwise be a Microsoft copy? Any money they're making they can sell...they can spend on improving their product and staying in existence and making it harder for us to do well. My job is to make Excel basically, like, the only application in the world. And if it doesn't add money to my bottom line, then there's no point in my spending any cycles on it."

OK: so, from what I get from reading that excerpt (the full transcript is a 66 page PDF) Microsoft seems to consider ISV's as pawns... enemies, really that will ultimately need to be squashed -- but first you may need to seduce them for your current needs ... use them as stepping stones to the ultimate goal of establishing Microsoft as the de facto standard for just about everything. ... It's only once they have exceeded their usefullness that they can be swept aside (or, even better yet, squashed so that they don't cause you problems later).

Now, of course, I'm doing a good bit of paraphrasing here, but I think it's a pretty accurate portrayal of the start of Plamondon's speech. ... and the further I get into it, the worse it looks.

---
Powerful, committed communication. Touching the jewel within each person and bringing it to life..

[ Reply to This | # ]

5 February is deadline only for contradictions?
Authored by: Anonymous on Friday, January 19 2007 @ 02:00 AM EST
I will be on holiday 5 Feb, and would dearly love to go Brussells
to see MS' representatives taken out in the snow and burnt
at the stake using the 6000pp and copies of Office 2007.

Unfortunately this nonsense is going to drag on for donkeys' years...

[ Reply to This | # ]

Searching for Openness in Microsoft's OOXML and Finding Contradictions
Authored by: Anonymous on Friday, January 19 2007 @ 03:22 AM EST
It's simply because the current accepted view of things is that men are
opportunists whereas women aren't.

Don't know where that came from, but I think it's a nasty left-over from
emancipation a while back.

There are many who believe I may be mad, but the enforcement of these
stereotypes which would not be tolerated for women is an increasing problem.

I'm getting ready to burn my jockstrap!

Another word which bugs me for not having a reverse-case : Misogynist.
Similarly to Philanthropy, it's very structure binds it to men. But what's the
reverse case?

[ Reply to This | # ]

Are Governments serious about Sovereignty... or not? That's the issue.
Authored by: Anonymous on Friday, January 19 2007 @ 02:05 PM EST
In the end, all of this only matters if there are governments that seriously want sovereignty. Will they allow a U.S. company to control them? Or not? I think that's what this multi-billion-dollar debate is all about - control and power. In short, who will control access to the documents of the world? A vendor? Or document creators and users?

No matter what ISO does, Microsoft is releasing Office without viable support for OpenDocument. EOOXML is a wink/wink non/nod 'standard' designed to be put on contracts to legally demand a sole supplier, forever. So, what happens next?

Governments can tell Microsoft a thousand times "support OpenDocument so that we can exchange documents without being dependent on any vendor" a thousand times. But talk is cheap. The only reason Microsoft would do anything different than what it's doing today would be if governments are willing to stop buying Microsoft Office, and switch to something else. Given what happened in Massachusetts, it's likely to fight tooth and nail to retail total control over documents. But faced with a serious threat, Microsoft could support a real standard easily if it wanted to. They could even make lots of money at selling products that support it. But they will not give up monopoly control over documents unless they have no alternative.

Microsoft is working to corner the market for printing presses, er, office suites. So far, looks like it's working, unless some are willing to stand up against it. Governments might not even NEED to switch, but they must be willing to change, or Microsoft will have no reason to change.

So, are governments willing to say that sovereignty of their nations from companies is really important? All agree that using open standards enables open competition, and permits countries to be sovereign from their suppliers. But is that so important that they're willing to go through painful changes? If they are, then this ISO decision matters - a lot. If governments don't want sovereignty that much, then it doesn't matter what ISO says; the governments will accept whatever Microsoft says to them, and ISO's decisions will become quickly irrelevant.

[ Reply to This | # ]

Why women fall for it
Authored by: GLJason on Friday, January 19 2007 @ 05:31 PM EST
How do guys like that do it? How do they make good-hearted women believe that they will straighten up and fly right and get them to agree to marry them? Vanity? Inexperience? The blinding power of love? I have no idea, but I observed that creative and convincing half-truths and even lies play a role.

I think women want to believe that they can change a man, that they can have such an influence on another person. It's a romantic fiction. Also guys like that are probably more exciting, and deep down women don't want a boring (albeit secure) guy. Add to that the strong motivation to find a 'soul mate' and the resulting lenses that color their perceptions of potential mates and you have the formula.

[ Reply to This | # ]

RFC: Microsoft's OOXML
Authored by: Anonymous on Saturday, January 20 2007 @ 03:53 AM EST
Surely this 'spec' is screaming for a massively-parallel
FLOSS-type review. With ~15 days and counting we could
easily do what is 'mission-impossible' for any organized
committee: do our own review of this 6000-pages monster.

The spec seems to be available at:

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-376.pdf

with annexes at:

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-376
Annexes.zip

[ Reply to This | # ]

Object to the proposal before it's too late!
Authored by: jhardin on Saturday, January 20 2007 @ 03:35 PM EST
February 5, 2007 is a critical deadline for the future of office productivity software. That is the date by which national standards bodies must submit any objections to fast-track processing of the Microsoft Office Open XML specification by the ISO/IEC international standards body.

Only qualified "P" member bodies of the ISO/IEC Joint Technical Committee 1 ("JTC-1") have legal standing to submit such objections.

In the USA this is the ANSI.

Fire up your mail clients and drop a (polite, technically meritorious) email to isot@ansi.org, or fax something to:

Scully, Henrietta
Program Manager, Standards Facilitation (ISOT)
fax: 212.730.1346

Cornish, Steven P.
Program Director, International Policy
fax: 212.730.1346

Kushnier, Gary W.
Vice President, International Policy
fax: 202.293.9287

Rajchel, Lisa
Director, International Secretariats Standards Facilitation
fax: 212.840.2298

The more protests they get, the more likely our voices are to be heard at the ISO.

Here's the letter I just faxed to them:

http://www.im psec.org/~jhardin/ANSI_MS_OpenXML_letter.xhtml

[ Reply to This | # ]

Who to contact? Look here ...
Authored by: Felix_the_Mac on Saturday, January 20 2007 @ 06:37 PM EST
There is lots of information on GrokDoc, including a list of the most important organi sations to contact

Personally, I think it would be better to wait 1 week whilst the GrokDoc project proceeds before contacting these committee members.

But there are other organsiations in all countries who are allowed to make representations to the National Standards Bodies. Contacting them now would (IMHO) be useful.

If you are in the US you may also contact INCITS - InterNational Committee for Information Technology Standards.

Remember any letters/emails etc which are not polite and technically informative will be COUNTERPRODUCTIVE.

N.B. There are 2 seperate pages on GrokDoc to visit both of which PJ provided links for in the 2nd paragraph of the article above.

[ Reply to This | # ]

Microsoft documentation.
Authored by: Artiken on Sunday, January 21 2007 @ 02:51 PM EST
History always repeats itself.

This may sound like a rant. I don't mean it as such. I just wish to cronicle the
quality of most Microsoft documentation.

I am writing this as a real world example of Microsofts documentation style.
Microsoft and the 'help' (and I use that word loosly) documentation made me feel
stupid. I have been a competent programmer in standard C and Basic for many
years. The several fifteen hundred paged books I have bought and read, written
by Microsoft Press, make good door stops. The books that I have purchased to
replace the M$ documentation all come from other publishers. The other
publishers manage to provide more usefull information in greater detail with
fewer words(pages). Microsoft has always produced huge and useless
documentation. I realise that this is a gross over generalization. I've found
that 95% of their documentation does conform to this rule. I feel that help
documentation shouldn't be obsfiscated. Yet Microsoft manages to do quite well
at just that. The M$OOXML specification is a good example. MSDN is another.

I purchased Microsoft Visual Studio v6.0 Pro. Ed. in 1998 as a college student.
It came with a 1 year subscription to MSDN(Microsoft Developers Network). The
MSDN is supposed to be the online resouce to find answers to all of your
Microsoft Windows programming needs. In other words it is supposed to be the
'help' files for programmers.

My first iritation with MSDN is in the way the information is presented. If you
go to the index, glossary, or search you are given a large number of links, to
read, to find the answers you are looking for. Not that this is a bad thing. The
problem is 99% of the links give you the following type of information. I'm
going to paraphrase. An exact copy would be a copyright violation.

"In this chapter you will learn the holly grail. You will learn xxx, yyy,
zzz.
Now that you have read this chapter you should fully understand xxx, yyy, zzz.
If you need further assistance you may contact a Microsoft support profesional
(at $300.00/hr) through the MSDN website. If you would like you may contact a
Microsoft Engeneer who will be glad to write a solution to your problem. (at
$1,000.00/hr)"

The chapter usually contains 2-6 paragraphs. Does something look like it is
missing? Yes! The middle part. The part that actually gives you an answer. MSDN
is full of this kind of "promise and summary" documentation. Quarterly
for a year I recieved a CDROM with updates. I couldn't tell what they updated.
It was huge so they must have been updating something. MSDN uses over 650
megabytes of Harddrive. It is a waste of space.

The second problem with MSDN is information is burried beneath a myriad of
links.

I had a Hard drive in my Compaq computer die on me. It would no longer boot.
Hardware wise it was working fine. My Master Boot record was corrupted. I needed
to resurect the drive so that I could get my data off of it. I had backups. Not
recent. They were on Tape. The sofware for the internal tape drive required
Win98. Thank you Colorado Systems. (I hadn't heard of Linux at the time.)
I figured how hard could it be to use a sector editor and copy a valid boot
record from a floppy disk or my other Win98 laptop. Change the media descriptor
byte, recreate the partition table, and tell the HD where the starting track and
sector of the root directory. First thing I needed was what those bytes in the
Hex dump meant. I had MSDN it should not be a problem.

Searching for "master boot record" give you 153 responses. (Yes I know
the result is because the search criteria is too broad.) So I ignored the
"Managing WAN traffic in windows NT 4.0" entry. That obviously won't
help. Searching for 'MBR' gives you only 73.

Halfway down the list is a link to 'Master Boot Record" twice. This page
give a short explanation that the MBR is used to start the computer. It also
give a nice Hex dump. Then ends. Not much help.

"Partition Boot Sector" actually gives the hex offsets and what the
byte values are used for. Ok this is part of the answer. Large chunks are
missing.

Several of the 153 links reference to pages that tell you to use 'fdisk /mbr' as
a command to fix the Master Boot Record, Boot code. That doesn't work to fix the
partition table or point to the root directory. It just replaces the boot code.
The partition table must be fixed first.

"Partition Table" gives you the layout of the partition table. Mildly
helpfull.

None of the documentation tells you that there is a duplicate of the boot
sector. I ended up finding it after many hours of searching sector by sector
(cluster by cluster?). The whole time I wondered why the first sector, normaly
the boot sector, was blank. It only contained in ascii the serial number of my
PC. Compaq used the 'original' boot sector to store the serial number of the
computer. I discovered that there is an option to offset your boot sector.
Compaq wasted one whole track. (63 sectors) So the boot sector was offset 64
sectors. Thank you Compaq.

After 4 days of searching I managed to resurect the HD.
I learned the layout is;
Offset, Master Boot Record, First FAT, Backup Master Boot Record, Second FAT
(Backup), Root Directory. (This was many years ago. If might be MBR, Backup MBR,
FAT 1, FAT 2, Root Dir.)
FYI. The fix was easy after I had the numbers.
Copy the backup MBR to the 64th sector (normaly 0 sector)
fdisk to create the partition table (the funky offset was needed),
fdisk /mbr to fix the boot code,
chkdsk to fix the fat and messed up root directory,
sector editor to view the files in the root directory so I could rename them to
what they are supposed to be.
Reboot.

Here is an example, which you can search for using MSDN or Google, to see what
I'm talking about.
Detailed Explanation of FAT Boot Sector - Article ID: Q140418. It is wordy but
not that detailed.
Search MSDN for 'master boot record' or 'partition table' or 'MBR' and see how
many hits you get.

In my search results in MSDN I came up with a humorous result.
List of Confirmed Bugs in Windows NT Version 3.5 - Article ID: Q133320
Now I know this article is 1997, but I wonder how many of the bugs have been
fixed?

To sum up.
Most M$ docs are obsfiscated. You end up with two slices of bread with no meat.
For the more cynical. You end up with a sandwich wrapper with no sandwich. A
1500 layer sandwich wrapper.
Most M$ docs are like spagetti code. You have to wander all around the code to
try and figure out what it is doing. In the end You have a small idea of what it
does, but you get this nagging feeling that you missed something major, like how
it works. You might even miss something important like a show stopper bug or
security hole. We all know that it is easier to scrap spagetti code and re-write
the whole app from scratch. (buy documentation from a second source)

[ Reply to This | # ]

    OOXML is how to NOT properly handle Office 2007 files
    Authored by: tz on Tuesday, January 23 2007 @ 01:51 PM EST
    My problem is more that OOXML isn't guaranteed to have anything to do with
    properly rendering Office 2007 and later (much less earlier) documents.

    Over at (paid to "fix" Wikipedia)
    http://www.oreillynet.com/xml/blog/2007/01/an_interesting_offer.html

    I posted a comment where I was pointing out the Spec wasn't complete and that
    was the complaint. Here is the reply and mine which gets to the problem:

    "tz: Since OOXML is the native saving format for Office 2007, I don't know
    how you can say that it hasn't been designed to support all the information in
    an MS Office document? What magic captures the other information if not the file
    format?"

    No, Microsoft's extended and PARTIALLY UNDOCUMENTED version of OOXML is the
    native saving format for O2007. The entire point is that the 6000 pages
    submitted to ISO is NOT the complete description of what Microsoft uses as
    OOXML.

    Their "native format" includes all the artifacts, sidebands, quirks,
    idiosyncrasies, and hidden emulations (the "Do as Word 5 did" tags).
    To render a document with fidelity, you need to duplicate not only the 6000
    pages of "the standard", but also all these hidden things which aren't
    in the standard. You call it "magic", but it is there.

    To use a more common example, there are plenty of magical things why a perfectly
    conforming page that is right in a perfectly conforming browser but won't render
    or work correctly in Internet Explorer - even version 7. So you either have to
    code differently depending on the browser, or make a page that will look bad in
    a correct browser. OOXML looks to be another cascading style sheet, javascript,
    etc. problem, only worse.

    Their "native format" is a fairly large (and maybe not even a proper)
    superset of what is in the OOXML spec. Or at least the "open" part.

    [ Reply to This | # ]

    Groklaw © Copyright 2003-2013 Pamela Jones.
    All trademarks and copyrights on this page are owned by their respective owners.
    Comments are owned by the individual posters.

    PJ's articles are licensed under a Creative Commons License. ( Details )