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 (43)

  1. Luc Bollen says:

    MS advocates the choice of office document formats, but still does not propose the choice to use ODF out of the box in MS Office 2007…  OTOH, Open Office 3 will propose the choice to read and save in both ODF and OOXML formats.

    "The State should desire greater competition among the vendors"  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.  And MS Office is not able, out of the box, to handle ODF documents.  Is this what Microsoft calls choice and competition ?

    "If the State were to legislate a single format, they are effectively creating an innovation dead zone"  This is definitively a stupid comment.  Could you confirm that you really believe that the web, which uses a single format (HTML) is an innovation dead zone ?  Microsoft attempted to impose its own variation of the use of HTML, and is changing his mind for Internet Explorer 8.  Is Microsoft convinced, now that they will use the standard version of the HTML single format, that the internet is an innovation dead zone ?

  2. cybervegan says:

    "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

  3. Wu MingShi says:

    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.

  4. Brett says:

    Hey Jason,

    I’d think ODF/PDF/XML would be good choices, why talk about application stacks with the capability of producing highly complex and interwoven/difficult to decipher documents as a selling point on this argument? Even if this were a legislature on electronic production of documents, what you’re suggesting is that the government should be able to use the latest MS Office to create needlessly complex documents that would then require everyone requiring access to those docs to have at least an equivalent or newer MS Office suite leave alone the operating system to run it.

    the biggest stinker for Microsoft will be "Vendor Neutrality", ODF can be implemented just fine if Microsoft wanted, it’d be far easier to write a fully compliant ODF filter for MS Office than it would be for OpenOffice.org, Lotus Synphony, GoogleDocs, etc to get a working implementation of OOXML leave alone MS Office 2007 formatted docs – yes, they’re not the same thing… I can peel off about a hundred different projects that produce fully ODF Compliant docs (Great Selling Point!), I’m not sure even Microsoft can reproduce various flavours of MS Office Docs with full fidelity between various flavours of MS Office Apps and 100% of all MS Office Apps are 0% compliant in ODF capability out of the box and any attempt to ODF’icise MS Office will result in difficulty level set to insane (Not Great Selling Point), I could be wrong tho.

    And on Germany, I see that OOXML won’t be considered for their Foreign Ministry until there’s an independent working implementation for OOXML Editing and creation on Linux and even then there cannot be the possibilities of ambiguities in implementation because of differing interpretations, see http://ec.europa.eu/idabc/en/document/7561 , it’s quite telling really…  I suppose that’s IBM talking too right?

    Telling of a standard that hasn’t been implemented even in Microsoft’s own software don’t you think?  99.9% of documents in the wild today don’t use the "so advanced and unimplementable by others" features in MS Office and the other .1% can be worked around just fine.  I believe Texas are right on this, you’ll probably find they’re sick of having to recover their earlier MS docs from their now upgraded and no longer supporting in original fidelity MS apps.

    It is largely a Microsoft problem that’s prompted these discussions by governments and academia these days, not marketeer assaults by the likes of IBM.  IBM for example has zero input into the work we do, it’s more of lack of openness and interoperability with others and unpredictable behaviour between releases and servicepacks that’s highlighting Microsoft woes.

  5. Ian Easson says:

    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?

  6. Ian Easson says:

    Brett says "the biggest stinker for Microsoft will be "Vendor Neutrality", ODF can be implemented just fine if Microsoft wanted"

    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.

  7. DJ says:

    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

  8. Andre says:

    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!

  9. Andre says:

    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.

  10. Brett says:

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

  11. UrsTruly says:

    Luc: "MS advocates the choice of office document formats, but still does not propose the choice to use ODF out of the box in MS Office 2007…  OTOH, Open Office 3 will propose the choice to read and save in both ODF and OOXML formats."

    What TOH? MS Office 2007 was released, the box and all, to enterprise customers in late 2006. It is 2008 now and OOo 3 is not going to be released for quite some time. I say you are confusing past and future products’ feature sets to draw your otherwise unsubstantiated conclusions.

  12. Ian Easson says:

    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?

  13. Ian Easson says:

    Brett says:

    " How is it possible for iWork’08 to implement OOXML as per ISO since the standard is yet to be released…?? "

    Answer: It doesn’t support IS29500, since that is yet to be published.  "OOXML" refers to the corresponding ECMA standard, which has been out since Dec 2006.

    All the rest of your comment is just junk.  None of the 350 or so OOXML applications have been written by signing any license or commercial agreements with Microsoft.  They were done by reading the ECMA standard for OOXML, and writing the software based on that open spec.

  14. Luc Bollen says:

    @UrsTruly: "MS Office 2007 was released, the box and all, to enterprise customers in late 2006"

    Nice try.  While MS could have included ODF support when MS Office 2007 was released (it is an OASIS published standard since May 2005), everybody knows that it is not the case.  But thanks for reminding this.

    Since then, MS claims high and loud for more than a year that they want to provide choice of format.  So, what prevents MS to *announce* support of ODF in the next version ? They could also use Office Update to download an ODF converter, in the same way they downloaded the OOXML compatibility pack for older versions of MS Office.

    What is the current situation ?

    – MS claims they want to offer choice of format, but do not even announce support of ODF in a next version

    – MS claims that OpenOffice wants to limit choice of format, but a beta version of OOo 3 with support of OOXML is already available.

    Quite a difference between MS words and actions, isn’t it ?

  15. Luc Bollen says:

    @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".

  16. voice/from/the/dark says:

    Luc, get your facts straight: ODF became ISO/IEC 26300:2006 on November 30, 2006 – on precisely the same day Microsoft Office 2007 was released to enterprises. Office 2007 was in development for more than three years by that time. There is no way to add something as big as ODF support to something as huge as Office 2007 in zero time.

    Are you saying that Microsoft should have implemented ODF as it was rubber stamped by Sun and IBM in OASIS? It was a very raw and OOo/SO centric standard at this point, not yet scrutinized by ISO. Not that it ever were anyway. Implementing ODF fresh out of OASIS oven, less than a year and half from the release date would be insanity. No, suicide.

  17. Ian Easson says:

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

  18. Dave S. says:

    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.

  19. Dave S. says:

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

  20. Luc Bollen says:

    @Voice: "Are you saying that Microsoft should have implemented ODF…"

    No, I never claimed that MS *should* have done this.  I’ve only said that they *could*.  Apart from this, I agree with your comment.

    But since ODF has not changed by a comma since May 2005 (which is a pity, I also agree), MS has had nearly 3 years now to think about it and make an *announcement* that they *will* support ODF out of the box in the *next* version of MS Office.

    Jason, you seem to be very quite currently.  I would be interested to know your view: will MS provide native support for ODF in MS Office any time soon ? If not, can you explain again to me what MS means when they say that they want to promote the choice of formats ?  Thanks.

  21. reward says:

    @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

  22. Brett says:

    Ian,

    Fair enough, iWork’08 doesn’t comply with ISO’s version of OOXML, but what you’re now saying is that it’s had two years to work with ECMA’s standard and still can’t get 100% fidelity and certainly doesn’t have any capability to write out OOXML of any type, how can you call that a supporting application?  Luc Bollen is quite justified by saying iWork’08 isn’t an acceptible answer to his question of a supporting app.  It doesn’t give any meaningful support insofar as OOXML usability is concerned, it can’t even create OOXML files, how can it be useful as anything other than a gimmick as far as OOXML is concerned?  would you honestly run a business with it if you had OOXML requirements?

    As for the other 350 odd OOXML applications you tout, how many if any can produce OOXML that are 100% compliant? in fact, can any produce OOXML Docs at all?  Can I see one?  The Link you so totally don’t want to acknowledge on iwork’08 versus OOXML is as recent as mid-february, any number of other sites and reviews give similar accounts on the infidelity between document rendering where they can be opened.  I have a list if you care to check and discount each one.  If I can find this many people accrueing issues with OOXML Rendering then surely something isn’t going right somewhere…  A number of commercial entities including both Apple and Adobe have summised that even where it is possible to comply with this standard, it would take an inordinate amount of manpower to get it working close to 100%, somewhere in the vicinity of 120 man years, see http://blogs.adobe.com/shebanation/2006/12/is_office_open_xml_a_oneway_st.html

    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??  We’d also have to ask how non-windows platforms would implement SSPI and OLE as referenced (but alas, undefined!) by these standards, even as it is, any other application provider on Windows would still need to reverse-engineer these to get workable solutions. The whole standard is littered with ambiguities like this.  How is anyone supposed to make it work??  You might have given an app that can almost use these standards but none are 100% and even the example s that do work aren’t 100%, they’re missing lines, font spacing is out of whack, even for the same given font and point, etc.

    as for the rest of my commentary being crap, thanks for the disrespect.  Are you saying my concerns based on court verifiable facts are unfounded and deserve no answer?  I’ll reiterate again, Microsoft have historically "Embraced and Extended" all sorts of technologies by bolting on proprietary and often patented extensions wheter purposefully or not has conveniently broken key competitors standards and/or technologies… Things like Java, Web Standards, DR-Dos, Word Perfect, Kerberos and Active Directory, so on.  When we’ve been exposed to the OOXML Standards, we can’t help but see this as an unwieldy piece of unimplementable standard designed to stave off any hope of OOXML Capability until it gets superceded or dies a silent death through passive neglect as background noise, especially given that MS Office 2007 silently breaks doc outputs now from time to time when VBA or OLE action goes on, see http://www.codeproject.com/KB/cs/office2007bin.aspx , again it does look like Microsoft just want’s to misdirect any meaningful compliance to their formats while everyone wanting to implement working solutions chases them for related specs. By then, maybe a couple of years the standard would’ve been superceded with a new and improved spec, probably several more thousand pages than the one we have now or everyone would’ve just dropped it as a bad idea and be chasing Microsoft’s proprietary standards once again.

    How about you not redirect this time and indulge me my answers, I do genuinely want to know?

    voice/from/the/dark,

    MS Office 2007 have been able to update with servicepacks and file format downloads/upgrades, It’s even possible to update MS Office versions as early as MS Office 97 with MS Office 2007 read and write capability but still not one iota of support for ODF apart from "there’s a filter project going on over there somewhere".. There are quite a number of Office Suites that have ODF as their native format now and have had rolling updates since before it became a standard… You might be surprised to know that the ODF standard before being ratified by ISO was fully implementable and changed very little from it’s original submission.  

    I can see how you could make that mistake if you’d based your usability/implementability standards on the OOXML experience, knowing what I know of it, I wouldn’t be able to implement it even now post ratification by ISO.

  23. Ian Easson says:

    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.

  24. Ian Easson says:

    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.

  25. Bruno says:

    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.

  26. voice/from/the/dark says:

    Luc: "But since ODF has not changed by a comma since May 2005 (which is a pity, I also agree), MS has had nearly 3 years now to think about it and make an *announcement* that they *will* support ODF out of the box in the *next* version of MS Office."

    I find this suggestion self-contradictory: you agree that ODF did not change a bit of its OOo/SO centric nature during ISO process and then you suggest Microsoft announce ODF support in Office. Why? Even OOo is not fully compatible with ISO ODF 1.0 standard (see Brian’s blog for examples).

  27. voice/from/the/dark says:

    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?

  28. Ian Easson says:

    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.

  29. reward says:

    @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

  30. Brett says:

    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

  31. voice/from/the/dark says:

    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?

  32. Ian Easson says:

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

  33. Doug Mahugh says:

    Like a few other people, I’ve been taking a break from blogging since the Open XML vote was final, to

  34. Brett says:

    # 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…

  35. reward says:

    G’day folks,

    A couple of comments, relating to the discussion above but not directly targeted at anyone.  

    1. IS 29500 explicitly tries to describe legacy documents accurately, so that future parties can reliably access past content.  However, it does this in the context of describing a new format (OOXML), rather than directly describing earlier binary formats.  An explicit mapping from the binary formats to OOXML has been mentioned as a desirable addition to the 29500 Standard, but hasn’t been adopted.  

    2. IS 29500 tries to present a "level playing field" for parties desiring interoperability.  Now, no human-produce document is *ever* likely to be *perfect* — "produce" is poor grammar, and should be written as "produced" earlier in this sentence — but a Standard tries to carve out a shared space, and to describe the boundaries of that space clearly.  Correctness of the boundary description is very important.  

    (Starting to get a little philosophical here:)  Accuracy is important in describing the boundaries, but I believe that the key deliverable of a Standard is trust, and accuracy is just one component feeding into this characteristic.  For example, where components such as nuts and bolts need to be trusted as fasteners; there are an array of items that can undermine trust, such as input material characteristics, manufacturing processes, and physical conformance to specifications such as length, diameter, thread pitch, handedness and depth.  

    While the specification — the Standard — specifies "perfect" dimensions for these physical characteristics, the nature of the real world is that absolute conformance is impossible.  Trust, in this case, comes from the inclusion of *tolerances* — how much a component may vary from the ideal without impacting its suitability for performing its intended purpose.  

    It seems to me that IS 29500 suffers from being pulled in a number of rather-incompatible directions, and that the argument happening here is a result of different weightings applied by different parties to the various forces.  My main feeling is that the legacy representation-versus-interoperability playing field struggle is the most fundamental tension, to the point where I would prefer to see these items addressed in different Standards.  The perfection-versus-trust comment partially flows out from this tension, but I’d like to see it dealt with more cleanly, as demands for perfection almost always create a straw man, whereas I believe that discussion about trust would be more productive.  

    Hope that this posting is useful (and congratulations for reading this far!)  

    –reward

  36. voice/from/the/dark says:

    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 🙂

  37. Ian Easson says:

    reward said:

    "it does this in the context of describing a new format (OOXML), rather than directly describing earlier binary formats.  An explicit mapping from the binary formats to OOXML has been mentioned as a desirable addition to the 29500 Standard, but hasn’t been adopted."

    The ECMA and ISO/IEC seriously considered the possibility of adding a description of the old binary formats and a mapping between them and OOXML.  After due consideration, they rejected that as being outside the scope of OOXML.  (I happen to agree: the OOXML spec is fairly complex as it is).

    However, in response to this decision, Microsoft changed how people can obtain the detailed documentation on the binary formats, so that you can just download them, without having to send an email to MS first.   (This is how you have been able to obtain them since about 1999, despite lies to the contrary from the anti-OOXML zealots!).  

    If you want this documentation, just download it from Microsoft.

    Having said that, you should be aware that this documentation needs some work to make it better to read, and to make clear the mapping between the old and the new.  

    Mind you, once the IS 29500 standard is actually published within a few months, it would then make sense for MS to document the mapping between the old binary formats and the new IS 29500 one.

    Satisfied?  

    (Probably not: I’m sure you’ll invent some reason to be upset.)

  38. Ian Easson says:

    reward said:

    "Trust, in this case, comes from the inclusion of *tolerances* — how much a component may vary from the ideal without impacting its suitability for performing its intended purpose. "

    This is why the ECMA proposed, and the ISO/IEC accepted at the BRM, the carving of the OOXML standards into "conformance classes", each with its own specification for what it means to conform to that subset of OOXML.

    There is, in the case of OOXML, no single "ideal", just a collection of conformance classes.  Depending on the needs of each programmer, they can choose which conformance class(es) their programming project is aimed to satisfy.

    I think if you really look at the standard (as opposed to taking at fair value the rants from IBM and groklaw and Andy O.), it meets all your objections.

  39. Brett says:

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

  40. reward says:

    @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

  41. Ian Easson says:

    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.

  42. Ancil says:

    Accuracy is important in describing the boundaries, but I believe that the key deliverable of a Standard is trust, and accuracy is just one component feeding into this characteristic. 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 implementer gained access to information not included in any standard. 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.

    ——————————–

    Ancil

    <a href="http://www.bestapartmentsinlongview.com&quot; rel="dofollow" rel="nofollow">Apartments in Longview, Texas</a>

Skip to main content