Texas Legislature - Electronic Documents Hearing

On Wednesday April 9, the Texas House of Representatives Government Reform Committee will be hearing testimony regarding electronic documents.

The notice for the hearing states that the committee is looking to hear about:

Research, investigate, and make recommendations on how electronic documents can be created, maintained, exchanged, and preserved by the state in a manner that encourages appropriate government control, access, choice, interoperability, and vendor neutrality. The committee shall consider, but not be limited to, public access to information, expected storage life of electronic documents, costs of implementation, and savings.

Following last year's multi-state lobbying campaign to enact hard procurement preferences through legislation of mandates for ODF, I am expecting that the same tune will be sung by IBM, Sun, Red Hat, and Google. If they choose to go down the same path of advocating a single format (ODF) rather than taking the time to listen to their customers, it will be a reminder of their single-minded drive to use document formats as a competitive wedge for their products rather than for meeting their customers' needs.

In every single state where there was a hard preference discussion, governments opted to look for first principles appropriate for codification in statute rather than using their legislative powers as a means to pick winners in the marketplace. MA, TX, MN, CT, CA, OR...and not just in the US. This was true all over the world.

First Principles:

The most basic frame for the discussion of electronic documents is simply that all states are seeking to accomplish the provision of services through the use of technology while obtaining the greatest value for money. Within that context the State wants to address the needs of communication with constituents, transacting government business, implementing effective archival policies…all based on the efficient use of resources (people & dollars).

A) Within the context of document formats, constituents want to communicate with the State using many formats – older binary formats, newer XML-based formats, non-modifiable formats, web formats, specialized industry formats (e.g. insurance, healthcare, financial services, etc.), etc. etc. The State will not mandate what products or formats their citizens use.

The best option for the State is to apply a first principles approach that focuses on the top-level goals while leaving maximum room for innovation and competition. For document formats, this would mean establishing statute that says any procured solution must provide effective support of document formats that enable communication with constituents. The State does this today by making information available and receiving information in PDF, DOC, HTML, ODF, Open XML, etc. etc. – any advocacy for going to a single format preference seems to counter the first principle for communications.

B) Transacting government business is based upon applications…not document formats. The apps are the tools used to solve business problems such as the production of complex documents, the manipulation and calculation of information in those documents, etc. This is the crux of business competition from the vendors represented in the hearings on Wednesday. The State should desire greater competition among the vendors to drive innovation and value in the solutions available to them. In fact, this is the exact argument that IBM, Sun, Adobe and others are suggesting - but their approach is flawed when they seek to accomplish this by limiting choice rather than promoting it. (Check out Enderle's post - good points by him on this front.)

If the State were to legislate a single format, they are effectively creating an innovation dead zone by limiting the features / functionality of the applications to the capabilities of a single format. Would IBM and Sun suggest that no state support DAISY? Or the National Library of Medicine formats for research papers? Or PDF for posting of public document for public viewing? ODF (using the generic here on purpose) itself has already progressed beyond the 1.0 ISO version because of the need for the format to represent the innovations in the products that use it. The State of Massachusetts looked carefully at this issue and decided the best path was to set policy at the first principles level and focus on open standards, not on picking one standard over another. This leaves the CIO(s) of the State open to make choices based on value, functionality, and whether or not the products purchased meet the first principles rather than meeting an arbitrary technology mandate.

C) Archival continues to be a critical discussion for governments. If there is any place where first principles are crucial - this is it. The first principle for the State should be one of saying that any solution chosen for office automation technology should provide support of the State’s archival policies and procedures (already defined elsewhere). This includes preservation, access of the data independent of any application, translate-ability of the data from the original format into another, scheduled destruction of the data based on statute, the ability to set custom schema within the context of open standard specification, etc. Then, the CIO's office should be evaluating all solutions against these principles and making the best value for money decision to achieve the stated goals. If done properly, this is an example of using first principles in statute to enable the maximum amount of competition and choice between solutions.

Interoperability:

The last thing I want to point out is that the committee hearing is really about interoperability - JUST LIKE Massachusetts ultimately focused on in their ETRM policy. The marketplace reality is one of multiple document formats. So the question is about translation, it is about building a bridge between formats. It is about dealing not only with the different formats, but about the multiple implementations of the different formats.

If I were in the hearings, I would inform the committee of the work that DIN (the German national standards body) kicked off with the Fraunhofer Institute and their SC 34 mirror. If I am not mistaken, this is also part of the SC 34 committee meeting discussion in Oslo where they are thinking about interop between Open XML and ODF as well. At the international standards level, the issue of interoperability is being pursued. Moreover, there are now hundreds of implementations of Open XML, there are similarly numerous implementations of ODF, PDF (at least in output) is supported broadly...so interop is really the name of the game.

Many of the states who were considering mandates last legislative session ultimately decided to kick off study projects to further consider this issue. I do hope that these studies take a long-look at what really matters, where the value is, and how interoperability will work in a multi-format world. The single format argument is a red herring argument.

Comments

• Anonymous
  April 08, 2008
  The comment has been removed

• Anonymous
  April 08, 2008
  "If they choose to go down the same path of advocating a single format (ODF) rather than taking the time to listen to their customers, it will be a reminder of their single-minded drive to use document formats as a competitive wedge for their products rather than for meeting their customers' needs. " As they say, when someone makes an accusation, look first at the accuser.  Multiple standards for the same thing cause nothing but confusion - it means that everyone has to implement two formats rather than one in order to be compatible. You haven't even implemented your own pretend standard properly yet - how do you expect others to do so? Or did Office 2008 suddenly change to saving files as ISO 29500 by default? When you speak of interoperability, it's always one way: towards MS. You dare not give your users an escape route. -cybervegan

• Anonymous
  April 08, 2008
  PingBack from http://medicine.healthfile.info/4896-texas-legislature-electronic-documents-hearing/

• Anonymous
  April 08, 2008
  Come on... Of course Google, IBM and SUN will play very hard for ODF, ditto Microsoft for OOXML and Adobe for PDF (vs XPS). It is a beauty pageant: Contestants will do its best to win, although undue influence are not welcomed. We call this business. If they do not do it, they should be fired. States governments are essentially big business. They have the right to choose to use only one format for everything, if they wish. They also have the duty to make sure that there are fair access for every citizen. Today, the foremost consideration is to not requiring citizens to pay 9or pay the least amount only if there is no way around it) to access documents and not to unduly inconvenience any section of the society. Hence, if they decide to choose only one format they have the obligation to favour a format that has free (as in money) applications to make sure they do not discriminate people based on their financial situation. In fact, one can argue that if you are  less well off, you need to interact with the state more. Thus making free access more important.

• Anonymous
  April 09, 2008
  The comment has been removed

• Anonymous
  April 09, 2008
  Luc Bollen issues this challenge: "Could you please give me the name of a second, competing office suite, in addition to MS Office, able to faithfully represent any OOXML document ?  There is none today, and to my knowledge none has been announced.  Everybody, including Microsoft, agrees that the format translators still have a long road to go before they can achieve near 100% interoperability.   So mandating the use of OOXML today equates mandating the use of MS Office." Answer: iWork'08 for OS/X on the Mac Any other questions?

• Anonymous
  April 09, 2008
  The comment has been removed

• Anonymous
  April 09, 2008
  Ian Easson said: "Answer: iWork'08 for OS/X on the Mac" Response: http://notebook.bekkelund.net/2008/02/13/ooxml-%E2%80%94-the-apple-headache/ I'd say a lot of questions remain and Luc's original comment remains valid. Try again, please. DJ

• Anonymous
  April 09, 2008
  I am curious when Microsoft would take the lesson and provide native support for ODF in its products. Within the context of document formats, constituents want to communicate with the State using many formats – older binary formats, newer XML-based formats, non-modifiable formats, web formats, specialized industry formats etc. etc. The State will not mandate what products or formats their citizens use. The only problem is that Microsoft does not offer adequate support for the open format ODF. But what if public procurement requirements would be convincing arguments? And internally the government needs to take a decision. Either a vendor neutral or a captured format. What a hard choice!

• Anonymous
  April 09, 2008
  Let me answer this: "Not according to the German standards organization DIN, which is looking into this.  Although their report is in preliminary draft stage and is incomplete, it contains sufficient information for any one to understand that Microsoft has been telling the truth about the incompatibility of ODF and OOXML." It is not DIN as an institution but Frauenhofer which created a DIN subcommittee to issue a report. I am not aware of any DIN meeting of that working group. Frauenhofer is a research institution contracted by Microsoft. What the report shows is that OOXML lacks certain features and ODF is the more flexible format. OOXML is incompatible by design, not by semantics. The draft report got released after the OOXML BRM so that no changes would be applied to the format to make it more compatible with ODF. The report shows that OOXML has little to offer that cannot be achieved by taking ODF or adaptions thereof.

• Anonymous
  April 09, 2008
  "Answer: iWork'08 for OS/X on the Mac Any other questions?" Yes Ian, I have some.  How is it possible for iWork'08 to implement OOXML as per ISO since the standard is yet to be released...??    I can understand it having close to full MS Office read and write but this was no doubt done in conjunction with commercial negotiations and licensing with Microsoft, it was never an original implementation from a stand alone standard registered with any International Standards Body.  You surely have to know yourself it's not possible...  For me to write an independent OOXML implementation requires me to forego any commercial aspirations and GPL'ing my resulting code would also be a no-no.  So effectively this standard is designed to give Microsoft it's ISO marketing bling while simultaneously hamstringing any worthy competitor from implementing a clean-room filter for this format that actually works.  Everyone sees this.  What's more, what happens when Microsoft decides it wants to "Innovate" again and intoduces new "features" that are no longer compatible with the ISO certified standard?  I won't be surprised to see iWork'08 no longer being able to reproduce the latest MS Office docs in full fidelity anymore, I'm surprised it has full fidelity with MS Office Apps now....oh wait, it doesn't. See Review at http://arstechnica.com/reviews/apps/iwork-08-review.ars/5 which shows in practise, exporting MS XML isn't possible, the importation of MS XML and even other earlier MS Docs are quite hit and miss on formatting and fidelity... =D As for incompatabilities between ODF and OOXML, I'm not at all surprised.  Microsoft did a great job of implementing incompatible features into well-established standards for it's OOXML.  Simple things like control characters in XML and ambiguous naming conventions where unambiguous naming conventions are supposed to permeate. I don't suppose there's a link to this preliminary report?  I still don't believe that Microsoft with all it's resources couldn't possibly implement ODF when it can quite happily create software that saves into a wide variety of other lesser formats just fine, Older MS Office Docs, HTML, RTF, even Text for example but not ODF because it's "incompatible"  Almost every other above-par office suite can read/write ODF fine and simultaneously MS Office Docs as best as possible without MS agreements and licensing, I don't believe for a minute that Microsoft programmers are that inept to not do this.  In fact historically Microsoft has conveniently broken standards to accommodate their apparent ingenuity to achieve what it calls "Innovation" in it's objectives...ironically at the expense of it's main competitors at any given time.

• Anonymous
  April 09, 2008
  The comment has been removed

• Anonymous
  April 10, 2008
  DJ, Read the comments section of the link you provided.  Other users are not having the same problem this person is having.  All you need is the latest version of iWorks'08, and you can render all OOXML documents just fine. In fact, why don't you look at the video of this, as well as the videos showing the same thing on the iPhone (again, contrary to what is claimed in the link you provide): http://www.youtube.com/user/OpenXML Any other questions?

• Anonymous
  April 10, 2008
  The comment has been removed

• Anonymous
  April 10, 2008
  The comment has been removed

• Anonymous
  April 10, 2008
  @Ian:

1. iWorks'08 is available only on Mac OS (< 5% of the market share).  So for all the companies and administrations making use of Windows or Linux, iWorks'08 is not an alternative.
2. iWorks'08 does not reliably handles all the OOXML files. So, for an administration or a company, it is useless as a OOXML consumer.  If you can only process 90% or even 95% or 98% of the files you receive from your customers, this is not commercially acceptable.  Note that it is exactly the claim of MS against ODF: MS cannot use ODF "because there is a small percentage of OOXML features that cannot be reproduced reliably in ODF" (I paraphrase). Sorry, we are back at the starting point: you cannot name a valid  alternative to MS Office for reliably consuming any OOXML file.  This is true for Windows, for MacOS and for Linux.  So, I repeat: mandating the use of OOXML is the same as mandating the use of MS Office.  Welcome to "the community of One".

• Anonymous
  April 10, 2008
  The comment has been removed

• Anonymous
  April 11, 2008
  Luc, First, let's get something clear.  No one has proposed mandating the exclusive use of OOXML.  In fact, MS has been advocating document choice, so the whole premise of your argument is vacuous. Having said that, you are changing the basis of your question after I answered it.  You said to name one, and I did.  Now you say it runs only on OS/X, and you say what about Linux.  Sorry, you asked for one.  And by the way, there are solutions other than iWorks08.  I only mentioned that one because you asked for just one.  So don't come back and say I've only given you one. Also, your claim that iWork08 cannot reliably process OOXML files is unsubstantiated.  Care to back it up?  (And don't give me that link to the blog of guy who had an older version of iWorks08 that didn't support OOXML.  He just needs to update.)

• Anonymous
  April 11, 2008
  Ian, from http://www.apple.com/iwork/pages/#compatible "When it’s time to share Pages documents with friends and colleagues, you can export them as PDF documents, in Word .doc format, as RTF, or as plain text documents. " No OOXML support there. As you have not named one yet, try again.

• Anonymous
  April 11, 2008
  "For document formats, this would mean establishing statute that says any procured solution must provide effective support of document formats that enable communication with constituents." This is not a rational approach. It invites the idea that any format submitted to the State becomes one the State must devote time and resources to support. "Transacting government business is based upon applications…not document formats." This -is- sensible. To that end I just downloaded Open Office. I had not thought to do so previously, but MS bloggers kept pointing out that ODF was worth their worry. Looks better than I thought and the price was better too. No Ribbon, either. Better to standardize on free applications that are available to the greatest portion of the populace. No licensing, no maintenance, no worries about audits, no costly upgrades. "This includes preservation, access of the data independent of any application, translate-ability of the data from the original format into another, scheduled destruction of the data based on statute, the ability to set custom schema within the context of open standard specification, etc." OK, First you say that applications matter, then say they should not matter. Which is it? How can the data be accessed without an application? Statute related data destruction is orthogonal to format - Neither has anything to do with the other. What does custom schema have to do with the format question either? If I have meta-data to relate to a file, it can certainly be zipped with the original, untouched file, colocated in a directory, or related via a database.

• Anonymous
  April 11, 2008
  The comment has been removed

• Anonymous
  April 11, 2008
  @Ian, It's impossible to reliably implement OOXML file reliably, using only standard information.  For example, how can any third-party application possibly "reliably" implement an underspecified element such as "autoSpaceLikeWord95"?   Claiming that this item may become "deprecated" does not stop it being part of the Standard, and this argument is even less applicable for pre-IS 29500 documents such as ECMA 376, which is the version you're referring to.   So, can you clarify what you mean when you claim that third-party applications can "reliably process OOXML files"?   %reward

• Anonymous
  April 12, 2008
  The comment has been removed

• Anonymous
  April 14, 2008
  Brett said: "Since you're in the know, How about I ask you then, if it's all so easy to comply with this standard, Where do I find out how "FooterLikeWord95" is defined?  How about lineWrapLikeWord6, shapeLayoutLikeWW8, useWord97LineBreakRules or useWord2002TableStyleRules?? " Those are all 100% specified in the IS 29500 standard, even though they are obsolete.  Enough NB's asked for it, so it was done. You really should keep up on these things, rather than bringing out obsolete arguments.

• Anonymous
  April 14, 2008
  reward said: "For example, how can any third-party application possibly "reliably" implement an underspecified element such as "autoSpaceLikeWord95"? " I will give you the same answer I gave Brett.  That and all the other obsolete aspects of the ECMA version of OOXML are now all totally decribed in the ISO/IEC version called IS 29500. Really, if you are going to be critical of something, you can at least keep up to date to see if your old arguments are still valid.

• Anonymous
  April 14, 2008
  Microsoft is creating an OOXML SDK: http://tirania.org/blog/archive/2008/Mar-22.html So that will lead to lots of third party OOXML apps.

• Anonymous
  April 14, 2008
  The comment has been removed

• Anonymous
  April 14, 2008
  Brett, you answered your own question: Microsoft can update existing Office releases to support ISO OOXML standard the same way you suggest they add ODF support. Only ISO OOXML support is much more plausible. I apologize for not taking your "fully implementable" bait :) As far as I understand OOXML can be partially implemented by design and standard. No application is mandated to fully implement ISO OOXML to be considered compatible with the standard. As for ODF, see my reply to Luc: OOo is not fully compatible with ISO ODF 1.0. Can you tell us what other suits you mentioned are fully compatible with ISO ODF 1.0?

• Anonymous
  April 15, 2008
  Brett, Since you make a big deal out of iWork'08 not being able to handle OOXML properly, I thought it would be worthwhile for others to see the relevant quoted parts of the article you linked to on Ars Technica, so they can judge for themselves: "I also downloaded a random .docx file from microsoft.com and imported it in both Pages and NeoOffice. In Pages, the page number showed up twice, but there was no text in the footer, which was there in NeoOffice. ... Importing and exporting presentations in PowerPoint format works well in Keynote, with a missing transition here or there and only occasionally an image that can't be converted. In practice, however, PowerPoint presentations often use fonts that aren't present on the Mac. The replacement fonts make the text bigger (usually) or smaller, which can wreak havoc on a carefully crafted presentation. " Here's my summary:  

1. Don't use fonts that the receiving person doesn't have (This has nothing specific to do with OOXML)
2. There is a small bug to do with some images
3. There is another one in which transitions aren't preserved.
4. There is a small bug in footers.   My own conclusion: If that's all, that's pretty good for a first release.

• Anonymous
  April 15, 2008
  @Ian, Thanks for responding to my comment.   By pointing out that the BRM made significant changes to try and clarify the interpretation of autoSpaceLikeWord95, you have acknowledged and accepted my point that all pre-BRM versions of the OOXML standard (Ecma 376 and earlier DIS 29500 version(s)) were in fact deficient in explaining this item.   Therefore, I repeat my claim that the presence of such insufficiently-documented clauses in the earlier Standards means that reliable third-party implementations of OOXML were not possible -- either some items were not fully implemented, or the implementor gained access to information not included in any standard.  (The ECMA-proposed clarifications only become part of a standard when IS 29500 is published, which hasn't happened yet.)   Second, the term "obsolete" in your objection bothers me.  At a mildly pedantic level, "deprecated" seems to be the preferred term, e.g. see http://www.dis29500.org/sg-0001/ More importantly, the presence of these items that Microsoft already implements, but are otherwise a dead end, helps create an interoperability barrier:  Others have to invest significant effort to conform to these specifications -- and remember, if an implementation does not conform to the Standard, then Microsoft's Covenant Not To Sue does not apply -- with the resources spent on this effort generating little or no direct return.   A couple of other notes arising from some of your other comments:  

• The significance of a bug depends on your viewpoint: A "small" bug from one viewpoint may be a "large" bug from another viewpoint.  This is particularly true when looking at interoperability -- I remember a vendor proudly proclaiming in the mid-1980s that they had produced hardware that was "bug-for-bug compatible" with Digital's VAXen.  
• I wouldn't be so cavalier about fonts; for example, mandatory font embedding is one of the major differences between PDF and XPS, and can result in PDF documents suffering degraded font handling relative to XPS documents, particularly where XPS compatibility is demanded by Microsoft in order to obtain "Vista-Compatible" certification for third-party hardware.   Also, where the producer is a government agency, and the potential consumers include all citizens of the nation, establishing an agreed set of baseline fonts can be unrealistic.  This is especially true if the font environment has recently undergone a major change, such as the many new Microsoft-owned fonts that have recently been introduced as part of the Vista OS.   --reward

• Anonymous
  April 16, 2008
  Ian Easson said: "Those are all 100% specified in the IS 29500 standard, even though they are obsolete.  Enough NB's asked for it, so it was done. You really should keep up on these things, rather than bringing out obsolete arguments." Ian, These aren't obsolete arguments.  If you have these definitions then where are they?  Can I download the spec from somewhere?  To everyone who isn't the editor, they are yet to be defined and aren't usable or implementable to that end.  I'm aware that MS-ECMA addressed 101% of all concerns raised a week before they were submitted to the BRM for discussion however nobody has these apparent "Resolutions" nor updated docs yet, just because they were addressed by MS-ECMA doesn't make them sufficient or workable in practice, I am hoping I'm wrong on this but I'll wait to be convinced. Reward has covered most other concerns I'd have mentioned again so I'll not double up. Thanks in advance, Brett

• Anonymous
  April 16, 2008
  reward, are you seriously complaining about pre-standardization documents being less than perfect? I see the only reason for this: you lack arguments to complain about the standard itself :) For the "bug for bug" compatibility please read my reply to Brett: ISO OOXML standard permits partial implementations. Here you can implement every little compatibility quirk or just the core of the specification, it is up to developer which way to choose. I call it freedom. You?

• Anonymous
  April 17, 2008
  Brett & reward: Regardless of whether you call them obsolete, depcrecated, or transitional (the name that was adopted at the BRM meeting), the fact is that documentation on those features was not actually needed at all by any developer, since those features dissappeared long ago.  But, the ECMA was very accomodating to requests prior to the BRM, and documented them all in detail. If you really intend to do some software development using these obsolete features (which I strongly doubt!), just download the documentation from the ECMA.  That will have to be the source, until the complete draft of ISO/IEC 29500 becomes available. Both of you, along with a lot of others, are just using this as a red herring.  There never was any issue with undocumented capabilities in the ECMA version of the standard; there is no interoperability barrier at all.  (Just ask anyone who is doing REAL WORK with the standard, instead of parroting some ignorant person's arguments.)

• Anonymous
  April 17, 2008
  Like a few other people, I've been taking a break from blogging since the Open XML vote was final, to

• Anonymous
  April 17, 2008

voice/from/the/dark said:

"For the "bug for bug" compatibility please read my reply to Brett: ISO OOXML standard permits partial implementations. Here you can implement every little compatibility quirk or just the core of the specification, it is up to developer which way to choose. I call it freedom. You?" voice/from/the/dark, I'd call that a vague, unworkable contradictory mess just waiting to happen.  It would mean that this ISO standard won't do what MS says it's intended to do.  It'll also mean that MS doesn't have to implement their ISO standard and that the documents produced won't necessarily be read/writable by other OOXML attempting apps...   I hope you're wrong on that but I'm not at all surprised if that is the case...

• Anonymous
  April 17, 2008
  The comment has been removed

• Anonymous
  April 17, 2008
  Brett, you mean that if OOXML requires full implementation then it is not implementable and if it allows partial implementations then it is unworkable contradictory mess? Truly Microsoft cannot do anything good :)

• Anonymous
  April 18, 2008
  The comment has been removed

• Anonymous
  April 18, 2008
  The comment has been removed

• Anonymous
  April 18, 2008

voice/from/the/dark said:

"Brett, you mean that if OOXML requires full implementation then it is not implementable and if it allows partial implementations then it is unworkable contradictory mess? Truly Microsoft cannot do anything good :)" Well, Yes.  The idea of a standard is to be an implementation of a format that isn't open to interpretation and accurately describes the constructs to allow reading and writing in the highest resolution possible while allowing the widest capability to implement. OOXML doesn't seem do any of this. It's so long and convoluted it's hard for anyone outside of Microsoft to make it work.  Many of the definitions are ambiguous and allow  a wide range of interpretations meaning it's all too easy to have two different apps do two different things with the same tag data. As for partial implementation meaning it can also be in conformance with the standard, all that means is Microsoft stands up and calls all the half-working non-Microsoft vendors' OOXML apps (and for that matter MS Office Doc read/writing apps who want nothing to do with OOXML) as conforming to and supporting OOXML despite not really working while simultaneously allowing Microsoft to be vague enough in it's implementation to conform and still maintain it's monopoly edge. The implication is all the Government and Industry mandates allowing or requiring OOXML can only use Microsoft Products. a double whammy such as we're just seeing coming out of France now, Government mandates can list OOXML because of these loose compliance "Features" in the standard allowing Government agencies to justify their continued lockin because let's face it, nothing else is really usable. so it's a Win/Win for Microsoft, everyone else is in the same boat they were before MS-ISO-OOXML. Jason, I've further looked into the links you provided on the OOXML Successes in the wild and I don't see the extolling of any virtues of OOXML outside of Microsoft's tools and apps.  It still looks more to me like a promotion of how third parties have been able to leverage Microsoft Software to do stuff they actually want it to do.  Admittedly this is better than ten years ago but we still don't have vendor neutrality in OOXML and likely never will.

• Anonymous
  April 19, 2008
  @Ian, "[...]  despite lies to the contrary from the anti-OOXML zealots! [...] Satisfied?   (Probably not: I'm sure you'll invent some reason to be upset.)" I find these comments unhelpful, and possibly mistaken or misdirected.  Can you provide any evidence to back up your claims that I've quoted above?   --reward

• Anonymous
  April 20, 2008
  I'm not sure which it is that you find unhelpful:

• The fact that the binary format documentation has been easily available since 1999 (and has been used by many companies like IBM, Sun, Corel, Novel, Scansoft, Adobe, etc. to build software that reads and writes these binary formats), or that
• The fact that anti-OOXML zealots have said that isn't the case, i.e. they lied about its availability.  (This has happened so frequently that you must have run across these claims at least once!  I call it a lie because it is:manifestly untrue, constantly repeated, and repeated even after the person has been pointed to the documentation.) Re my "satisfied" comment.  Sorry.  I was feeling testy at that moment.  I was attributing to you the same attitude that most others who ask the same questions and make the same comments you have.

• Anonymous
  August 15, 2008
  The comment has been removed