Wow. My previous post seems to have attracted some attention. When I woke up on Monday morning, made my coffee and logged into to my email, I found out that my geeky little analysis of Office 2007 SP2’s ODF support had sparked some interest. I did not intend it to be more than an update for the handful of the “usual suspects” who regularly follow ODF issues via various blogs, many of which you see listed to your right. If I had any foreknowledge or expectation that this post would end up being on SlashDot, GrokLaw, ZDnet, IDG, Reuters, CNet, etc., I would have done a better job spell checking, and maybe toned down the rhetoric a little (just a little).<\/p>\n
But this widespread interest in the topic tells me one thing: ODF is important. People care about it. People want it to succeed, and when this success is threatened, whether for deliberate or accidental reasons, they are upset. Although Office 2007 SP2 also added PDF and XPS support, you don’t see many stories on that at all.<\/p>\n
I’ve been trying to respond to the many comments by anonymous FUDsters and Fanboys on various web sites where my post is being discussed. However, it is getting rather laborious swatting all the gnats. They obviously breed in stagnant waters, and there is an awful lot of that on the web. Since all links lead back here anyways, it will be much simpler to do a recap here and address some of the more widespread errors.<\/p>\n
The talking points from Redmond seem to be consistent, along the lines of:<\/p>\n
We did a 100% perfect and conforming implementation of ODF 1.1 to the letter of the standard. If it is not interoperable, then it is the fault of the standard or the other applications or some guy we saw sneaking around back on the night of the fire. In any case, it is not our fault. We just design, write, test and sell software to users, businesses, governments and educational institutions. We have no influence over whether our products are interoperable or not. What effect SP2 has on users or the market — that’s not our concern. Come back in 50 years when you have a 100% perfect standard and maybe we’ll talk.<\/p><\/blockquote>\n
In other words, all of those Interoperability Directors and Interoperability Architects at Microsoft seem to have (hopefully temporarily) switched into Minimal Conformance Directors and Minimal Conformance Architects, and are gazing at their navels. I hope they did not suffer a reduction in salary commensurate with the reduction in their claimed responsibilities.<\/p>\n
In any case, their argument might be challenged on several grounds. First up is the question of whether the ODF documents written by Excel 2007 SP2 indeed conform to the ODF 1.1 standard. This is not a hard question to answer, but please excuse this short technical diversion.<\/p>\n
Let’s see what the ODF 1.1 standard says in section 8.1.3 (Table Cell):<\/p>\n
Addresses of cells that contain numbers. The addresses can be relative or absolute, see section 8.3.1. Addresses in formulas start with a \u201c[\u201c and end with a \u201c]\u201d. See sections 8.3.1 and 8.3.1 for information about how to address a cell or cell range.<\/p><\/blockquote>\n
And the referenced section 8.3.1 further says:<\/p>\n
To reference table cells so called cell addresses are used. The structure of a cell address is as follows:<\/p>\n
\n
- The name of the table.<\/li>\n
- A dot (.)<\/li>\n
- An alphabetic value representing the column. The letter A represents column 1, B represents column 2, and so on. AA represents column 27, AB represents column 28, and so on.<\/li>\n
- A numeric value representing the row. The number 1 represents the first row, the number 2 represents the second row, and so on.<\/li>\n
This means that A1 represents the cell in column 1 and row 1. B1 represents the cell in column 2 and row 1. A2 represents the cell in column 1 and row 2.<\/p>\n
For example, in a table with the name SampleTable the cell in column 34 and row 16 is referenced by the cell address SampleTable.AH16. In some cases it is not necessary to provide the name of the table. However, the dot must be present. When the table name is not required, the address in the previous example is .AH16<\/ol>\n<\/blockquote>\n
So, going back to my test spreadsheets from all of the various ODF applications, how do these applications encode formulas with cell addresses:<\/p>\n
\n
- Symphony 1.3: =[.E12]+[.C13]-[.D13]<\/li>\n
- Microsoft\/CleverAge 3.0: =[.E12]+[.C13]-[.D13]<\/li>\n
- KSpread 1.6.3: =[.E12]+[.C13]-[.D13]<\/li>\n
- Google Spreadsheets: =[.E12]+[.C13]-[.D13]<\/li>\n
- OpenOffice 3.01: =[.E12]+[.C13]-[.D13]<\/li>\n
- Sun Plugin 3.0: [.E12]+[.C13]-[.D13]<\/li>\n
- Excel 2007 SP2: =E12+C13-D13<\/li>\n<\/ul>\n
I’ll leave it as an exercise to the reader to determine which one of these seven is wrong and does not conform to the ODF 1.1 standard.<\/p>\n
Next is the question of the relationship between interoperability and conformance. So we are not building skyscrapers in the air, let’s start with a working definition of interoperability, say that given by ISO\/IEC 2382-01, “Information Technology Vocabulary, Fundamental Terms”:<\/p>\n
The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units<\/p><\/blockquote>\n
I think we probably have a better sense of what conformance is. Something conforms when it meets the requirements defined by a standard.<\/p>\n
So let’s explore explore the relationship between conformance to a standard and interoperability.<\/p>\n
First, does interoperability require a standard? No. There have been interoperable systems without formal standards. For example, there is a degree of interoperability among spreadsheet vendors on the basis of the legacy Excel binary file format (XLS), even though the binary format was never standardized and never defines spreadsheet formulas. Another example is the SAX<\/a> XML parsing API. Widely implemented, but never standardized. We may call them informal or de facto standards.<\/p>\n
Additionally, many standards start out as informal technical agreements and specifications that achieve interoperability among a small group of users, who then move it forward to standardization so that a broader audience can benefit. But the interoperability came first and the formal standard came second. See the history of the Atom<\/a> syndication format for a good example.<\/p>\n
Second, Is interoperability possible in the presence of non-conformance? Yes. For example, it is well known that the vast majority of web pages (93% by one estimate<\/a>) on the web today do not conform to the HTML standard. But there is a not unsubstantial degree of interoperability on the web today in spite of this lack of conformance. Generally, interoperability does not require perfection. It requires good faith and hard work. If perfection were required, nothing would work in this world, would it?<\/p>\n
Third, if a standard does not define something (like spreadsheet formulas) then I am allowed to do whatever I want, right? This is true. But further, even if ODF 1.1 did define spreadsheet formulas you would still be allowed to do whatever you want. Remember, these are voluntary standards. We can’t force you to do anything, whether we define it or not.<\/p>\n
So what then is the precise relationship between conformance and interoperability? I’d state it as:<\/p>\n
\n
- In general, conformance is neither necessary nor sufficient for to achieve interoperability.<\/li>\n
- But interoperability is most efficiently<\/em> achieved by conformance to an open standard<\/em> where the standard clearly states those requirements which must be met to achieve interoperability.<\/li>\n<\/ul>\n
In other words, the relationship is due to the efficiency of this configuration to those who wish to interoperate. Conformance is neither necessary nor sufficient to achieve interoperability in general, but interoperability is most efficiently achieved when conformance guarantees interoperability. When I talk about “standards-based interoperability” I’m talking about the situation when you are in the neighborhood of that optimal point.<\/p>\n
The inefficiency of other orientations is seen with HTML and Web browsers. Because of the historically low level of HTML conformance by authoring tools and users who hand-edit HTML, browsers today are much more complex then they would otherwise need to be. They need to handle all sorts of mal-formed HTML documents. This complexity extends to any tool that needs to process HTML. Sure, we have a pretty good grip on this now, with tools like HTML Tidy<\/a> and other robust parsers, but this has come at a cost. Complexity eats up resources, both to coders and testers, but also runtime resources, memory and processing cycles. More complex code is harder to maintain and secure and tends to have more bugs. Greater conformance would have lead to a more efficient relationship between conformance and interoperability.<\/p>\n
Similarly, the many years of non-conformance in browsers, most notably Internet Explorer, to the CSS2 standard has resulted in an inefficiency there. From the perspective of web designers, tool authors and competing browser vendors, the lack of conformance to the standards has increased the cost needed to achieve interoperability, a cost transferred from a dominate vendor who chose not to conform to the standards, to other vendors who did conform.<\/p>\n
The efficiency of conformance to open standards in particular is the clarity and freedom it provides around access to the standard and the contingent IP rights needed to implement the standard.<\/p>\n
So back to ODF 1.1. What is the relationship between conformance and interoperability there? Clearly, it is not yet at that optimal point (which few standards ever achieve) where interoperability is most-efficiently achieved. We’re working on it. ODF 1.2 will be better in that regard than ODF 1.1, and the next version will improve on that, and so on.<\/p>\n
Does this mean that you cannot create interoperable solutions with ODF? No, it just means that, like most standards in IT today, you need to do some interoperability testing with other vendor’s products to make sure your product interoperates, and make conformant adjustments to your product in order to achieve real-world nteroperability. Most vendors who don’t have a monopoly would do this naturally and in fact have done this, as my chart indicated. Complaining about this is like complaining about gravity or friction or entropy. Sure, it sucks. Deal with it. Although it may not pay as much as being a professional mourner<\/a>, work as a programmer is more regular. And giving value to customers will always bring more satisfaction than than standing there weeping about how code is hard.<\/p>\n
In any case, this comes down to why do you implement a standard. What are your goals? If your goal is be interoperable, then you perform interoperability testing and make those adjustments to your product necessary to make it be both conformant and interoperable. But if your goal is to simply fulfill a checkbox requirement without actually providing any tangible customer benefit, then you will do as little as needed. However, if your goal is to destroy a standard, then you will create a non-conformant, non-interoperable implementation, automatically download it to millions of users and sow confusion in the marketplace by flooding it with millions of incompatible documents. It all depends on your goals. Voluntary standards do not force, or prevent, one approach or another.<\/p>\n
To wrap this up, I stand on the table of interoperability results in the previous post. SP2 has reduced the level of interoperability among ODF spreadsheets, by failing to produce conforming ODF documents, and failing to take note of the spreadsheet formula conventions that had been adopted by all of the other vendors and which are working their way through OASIS as a standard.<\/p>\n
If we note the arguments used by Microsoft in the recent past, they have argued that OOXML must be exactly what it is — flaws and all — in order to be compatible with legacy binary Office documents. Then they argued that OOXML can not be changed in ISO, because that would create incompatibility with the “new legacy” documents in Office 2007 XML format. But when it comes to ODF, they have disregarded all legacy ODF documents created by all other ODF vendors and take an aloof stance that looks with disdain on interoperability with other vendor’s documents, or even documents produced by their own ODF Add-in. The sacrosanctness of legacy compatibility appears to be reserved, for strategic reasons, for some formats but not others. We’ll redefine the Gregorian calender in ISO to be interoperable with one format if we need to, but we won’t deign, won’t stoop, won’t dirty ourselves to use the code we already have from the ODF Add-in for Microsoft Office, to make SP2 formulas interoperable with the other vendors’ products, to benefit our own users who are asking for ODF support in Office. As I said before, this ain’t right.<\/p>\n","protected":false},"excerpt":{"rendered":"
Wow. My previous post seems to have attracted some attention. When I woke up on Monday morning, made my coffee and logged into to my email, I found out that my geeky little analysis of Office 2007 SP2’s ODF support had sparked some interest. I did not intend it to be more than an update […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[9],"tags":[],"class_list":{"0":"post-222","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-odf","7":"entry"},"_links":{"self":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/222","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/comments?post=222"}],"version-history":[{"count":1,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/222\/revisions"}],"predecessor-version":[{"id":354,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/posts\/222\/revisions\/354"}],"wp:attachment":[{"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/media?parent=222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/categories?post=222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.robweir.com\/blog\/wp-json\/wp\/v2\/tags?post=222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}