ODF Alliance Lauds Accessibility Enhancements, International Adoptions and Launch of New National Chapters

FOR IMMEDIATE RELEASE
Contact:
Kathryn Brownlee, Rational PR, 202-429-1833

Marino Marcich, ODF Alliance, 202-789-4450,
Jomar Silva, ODF Alliance Brasil,

Washington, DC., May 9, 2008. The ODF Alliance today congratulated the Organization for the Advancement of Structured Information Standards (OASIS), which maintains and improves the OpenDocument Format (ODF), on advances that will help people with disabilities gain access to computers and information. The Alliance also welcomed news of international ODF adoptions as well as the launch of national chapters in several additional countries.

“Approval of the accessibility guidelines marks an important milestone in OASIS’s efforts to ensure that users with disabilities are equally able to read, create, and edit ODF documents as their mainstream colleagues. The new guidelines describe what steps must be taken to ensure that users with disabilities achieve these capabilities,” said ODF Alliance managing director Marino Marcich. “The guidelines, together with the enhancements approved last year, will help ensure that ODF continues to meet or exceed the accessibility features of any other document format.” The ODF Accessibility Guidelines v1.0 can be found at:
http://docs.oasis-open.org/office/office-accessibility/v1.0/cs01/.

The accessibility advances come on the heels of announcements by standards bodies in South Africa, Brazil, and Croatia of their approval of ODF as a national standard. The South African Bureau of Standards (SABS) approved ODF as a national standard in April following the government’s announcement late last year that ODF will be the standard for document exchange between government agencies and the public.

The final translated version of ODF was also recently approved by Brazil’s National Standards Association, ABNT, paving the way for ODF’s adoption as a Brazilian national standard (ABNT NBR ISO/IEC 26300:2008).

“The decision should provide strong impetus for other regional and municipal governments in Brazil to adopt ODF for creating, exchanging, and saving documents,” said Jomar Silva, Executive Director, ODF Alliance Brasil. “With this national seal of approval, products implementing support for ODF may also be preferred in government tenders.”

In 2006, with the publication of version 2.0 of its e-Ping Interoperability Framework, Brazil became the first country in South America to officially adopt ODF as its recommended format. In December 2007, Parana, a state in southern Brazil, became the second regional government in South America and sixth globally to adopt ODF.

In addition to adoption by governments, new ODF Alliance national chapters were launched in Hungary in April and Latvia earlier this year. “The launch of an ODF Alliance national chapter in Hungary gives Hungarian citizens a strong voice for widespread use of an open format and open standards generally in the Hungarian public sector,” said Gábor Szentiványi, head of international relations, ODF Alliance Hungary.

“With national chapters now established in Brazil, India, Malaysia, the United Kingdom, Poland, Portugal, Hungary and Latvia, the ODF Alliance has been able to enhance its truly global footprint,” said Marcich. “With the expected arrival of ODF v1.2 later this year, which includes support for extensible metadata, formula, and digital signatures, we expect the ODF-supporting community to continue to grow.”

The OpenDocument Format Alliance is an organization of governments, academic institutions, non-government organizations and industry dedicated to educating policy makers, IT administrators and the public on the benefits and opportunities of ODF.

Washington, DC, April 2, 2008—ODF Alliance managing director Marino Marcich issued the following statement regarding the ISO vote on Microsoft’s Office Open XML.

“The ISO vote on OOXML has raised awareness at the highest levels of government of the importance of preserving access to public information and records. For too long, this information has been locked into the closed, proprietary format controlled by a single vendor. This is increasingly unacceptable. For this reason, governments around the world have been adopting the already-ISO approved OpenDocument Format (ODF).

ODF will continue to be the document format of choice that best meets the needs of governments interested in ensuring access to their own information, now and in the future. The process itself brought to the fore OOXML’s deficiencies that will prevent its use by public administrations, chief among them that OOXML remains a “community of one”—undocumented features, IPR restrictions, and features and functionality linked to other Microsoft products that will prevent OOXML’s use in other software products. Governments will naturally take a “buyer beware” attitude toward OOXML and its lone implementation, Microsoft Office 2007. Nothing about the process will provide governments with any more confidence in OOXML’s openness and interoperability than they had before the vote.

The vote shined a spotlight on OOXML that will not dim. Only in response to growing public pressure has Microsoft promised to make changes to OOXML, and, to be sure, similar promises have been made on numerous occasions. To avoid any questions concerning the legitimacy of the vote, which included many documented irregularities, Microsoft needs to ensure that these promises made to national standards bodies are actually delivered. 

If anything, this vote has galvanized the ODF community, making us more confident than ever of ODF’s emergence as the document format of the future.”

Easy, interoperable, inexpensive. That was the theme of the event celebrating Document Freedom Day in the Texas State Capitol in Austin. Pino Ferrari of IBM and Nathan Conger of Novell showed how easy it was to peek under the hood of an ODF document (extracting and manipulating data), edit and exchange it on multiple applications and platforms.

The demo, which was attended by representatives from a dozen House and Senate legislators and the Offices of the Speaker and Governor, could not have been more timely. A hearing is scheduled for April 9th before the House Committee on Government Reform to examine the issue. Last year two bills were introduced in Texas, HB 1794 (Rep. Marc Veasey) and SB 446 (Sen. Juan Hinojosa) requiring that state electronic documents be created, exchanged, and maintained in an open format as designated by the State’s Department of Information Resources. Hearings were held, and what emerged from last year’s session were interim charges in both the House and Senate directing the relevant committees to study and make recommendations on the adoption of an open document format.

People will pay attention to what happens in Texas, the second largest economy in the US and the 15th largest in the world. It’s also a rapidly-growing economy whose government is looking to streamline and simplify operations, and save some taxpayer money in the process.

Arguments are often made that having two internationally-approved standards for document formats would encourage choice.  After all, isn’t competition good? South Africa’s Minister of Public Service and Administration, Ms. Geraldine Fraser-Moleketi addressed this issue from the perspective of governments in her opening address at the Idlelo 3 Conference currently underway in Dakar, Senegal:

“South Africa is amongst a growing number of National Governments who have adopted ODF over the past year...It is unfortunate that the leading vendor of office software, which enjoys considerable dominance in the market, chose not to participate and support ODF in its products, but rather to develop its own competing document standard which is now also awaiting judgement in the ISO process. If it is successful, it is difficult to see how consumers will benefit from these two overlapping ISO standards. I would like to appeal to vendors to listen to the demands of consumers as well as Free Software developers. Please work together to produce interoperable document standards. The proliferation of multiple standards in this space is confusing and costly.”

You can read her full address and also upload the video here. To understand why having one ISO-approved standard like ODF (ISO/IEC 26300:2006) means more choice and provides greater benefits to consumers and local IT developers alike, consider the following –

Citizens benefit from choice among competing software products, not competing standards. Document formats are not software products that you can buy. Formats are implemented in software products – applications like Open Office, IBM Symphony, StarOffice, and Google Docs.  File formats are “behind the scenes”, invisible, yet critical to allowing multiple products to share data. Citizens benefit from a single, agreed format implemented in a variety of competing software products, both proprietary and open source. 

Competition comes from, and innovation is built on, single open standards - look at the Internet.  HTML is the single agreed open standard which enables everyone to view web pages across different brands and versions of browsers, operating systems, and hardware.  Email works regardless of the service provider chosen because the provider implements the one open standard, TCP/IP.  Consider the alternative – dueling standards, where web sites are only viewable in a particular brand of browser and in a format controlled by a single software vendor, where messages are returned because the intended recipient uses a different email service. 

With a single standard, local IT investment is protected and development time and costs are reduced.  Small local players can enter the market with the assurance that a single standard is well known and accepted widely, and therefore their investment in time and resources will not be squandered. If multiple standards exist, an entrepreneur looking to launch a new product must weigh the costs and risk of paying extra to develop support for all these standards or guessing which one will succeed.  Whatever choice is made, the result is either at greater expense or greater risk, both of which will reduce the chance of success and might prevent the innovator from entering the market. 

Dual standards create interoperability problems for governments.  Many governments have expressed the “general dissatisfaction with the prospect of having competing standards,” and independent experts and EU advisory bodies have called on industry to work towards a single format. With two standards, governments waste time and resources navigating the interoperability between the file formats to select, develop and/or implement so-called “bridges” – converters, adapters, and translators – that may not work perfectly and require user intervention. 

Dueling standards limit the usability and accessibility for citizens to the devices and applications that implement them.  Remember VHS and Beta.  Today, digital image formats (e.g., JPEG) and digital media formats (e.g., MPEG) are trumpeted as examples of where multiple overlapping standards co-exist. Yet these formats serve altogether different objectives (images and streamed video).  OOXML and ODF serve the same purpose – the production of office documents (text documents, spreadsheets, and presentations).  Moreover, many of the “dueling” formats cited (e.g., MPEG-1, MPEG-2, MPEG-3) simply represent updated versions of the same format.  Innovation and advancement yes, but around a single format.

You will hear the word “choice” being used repeatedly in defense of having two internationally-approved standards for document formats. What are customers - in this case governments like South Africa, significant consumers of IT products in their own right - saying? True choice results not from competing standards in which there is over 90 percent functional overlap (as is the case with OOXML and ODF), but from multiple implementations of the same open standard which compete on features, functionality and price. In other words, competing software products, not competing standards.

With the input of our members, we’ve taken a first cut at the Top 10 Worst Responses (reproduced below) to the 3,522 comments submitted by National Bodies. We have yet to complete a review of all 2,293 pages of Ecma’s responses (over a 1,000 proposed fixes, no less). You can help! Provide your own Top 10 list, or better yet, let us know of particularly egregious ones that we’ve missed.

If you have the unenviable task of reviewing Ecma’s Proposed Disposition of Comments on DIS 29500 - the OOXML specification – you might initially be impressed that Microsoft and Ecma have produced answers for all of the thousands of concerns raised about the specification. However, if you take the time to become more familiar with the content of those answers, you will see that not all of the concerns are resolved in a way that improves or moves the specification forward.  To have some fun, here is a list (with apologies to Dave Letterman) of the Top Ten Worst Ecma Responses:

10. Worst Ignored Request - Response 620 - Identifies ‘w:sz’ as an element with ‘major internal inconsistencies’.  Elements have units of half points, points, pixels, percentages, etc, depending on the context, and when used as an attribute it can be eighths of a point, hundredths of a point, percentage of the screen, or even the values “full”, “half”, and “quarter”.  The response agrees that “the sz attribute/element has different meaning depending upon its parent element”, but is determined to keep things the same.  No change is offered.

9. Worst non-Answer - TIE!! Responses 759 and 862 - Both merely quote the comment. For Response 759 the proposed disposition states: “In the Numbering row of the table in Part 4, §2.16.5 page 1508, the second part of the description of ‘Numbering’ makes no sense.” Just that, no changes.

8. Worst use of XML - Response 559 - The use of the element ‘e’ breaks XML usage conventions. Ecma’s response lists 18 different uses for the element ‘e’ but does not solve the issue, rather it further emphasizes the poor quality of this specification and improper way in which XML has been used.  No change is offered.

7. Worst Introduction of Security Holes - Response 102 - This Ecma response supplies a list of reserved values for hashing algorithms, the first four of which (MD2, MD4, MD5, and RIPEMD-128) are followed by this note: “It is recommended that applications should avoid using this algorithm to store new hash values, due to publically known breaks.”

6. Worst ‘Back Door’ Tactic - Response 82 - The comments ask to ‘specify’ or ‘remove’ the ink element which is a placeholder for a non-interoperable application-defined functionality. Ecma’s proposal adds a type element to the XML schema and recommends using InkML, which is a W3C Working Draft, but leaves open their ability to use non-interoperable application-defined formats. To make matters worse the response is littered with references to VML which is proposed to be deprecated in other responses, even stating ‘An ink object is a VML object...”.  Is VML reentering the specification?

5. Worst ‘Baby and Bathwater’ (part of a popular US phrase that means throwing away the good with the bad) - Another TIE! Responses 425 and 624 - The comments ask for explicit support for embedded objects from KDE and Gnome, in addition to Microsoft’s OLE objects. Ecma’s response states that OOXML allows for “a general method for embedding objects from an external component technology” and removes all references to OLE.  In light of the heavy use of OLE embedding in current MS Office documents, interoperability greatly depends on this functionality. Changing the language of the specification to not directly call embedded objects ‘OLE objects’ (i.e. removing the normative reference) has the potential to substantially degrade interoperability of OOXML documents.  This makes embedded objects implementation-specific in the eyes of the specification.

4. Worst Standardizing of a Microsoft Bug - Response 782 - The comment questions an example for FILESIZE where 4660736 bytes is rounded to 4661 kb.  This is incorrect; it uses a division by 1000 instead of 1024. The result should be 4552 kb.  Instead of fixing the example, the Ecma proposal changes the unit from ‘kilobyte’ to ‘thousand bytes’ (and ‘megabyte’ to ‘million bytes’).  This is odd because file sizes are normally calculated in kilobytes and megabytes.  This proposal suggests a bug in Microsoft’s current application, where the programmer divided by 1000 instead of 1024 (and 1000000 instead of 1048576 which is 1024*1024) The Ecma proposal favors an existing bug over obvious behavior.

3. Worst ‘Most ways to Skin a Cat’ Answer - Response 43 - Ecma’s response suggests that instead of having one standardized way of representing dates (ISO 8601), that there should be five!  In addition to ISO 8601, they propose two legacy representations with base dates 1900 and 1904 with no support for dates before these years, plus two brand new representations based on the 1900 and 1904 systems which handle years before the base date but are not thoroughly defined.

2. Worst Dueling Answers -Response 222 and Response 691 – In this example, of considerable importance, the two proposals come to the opposite conclusion on a question over precedence between the text and the schemas in the electronic annexes. Which of these two sources is definitive is extremely important to the specification. Response 222 proposes to remove a line of text giving precedence to the schemas, stating “Agreed; this statement should be eliminated”. Response 691 rejects that very suggestion, stating “Disagreed.” and “… the ZIP file versions should be considered the definitive versions.”.

1.Worst Case for spending days of my life reading through these answers - Response 885 - “Agreed; deprecated features should not be used in newly created Office Open XML documents.” ALL OOXML documents will be NEWLY CREATED.  While there are many documents in the legacy binary format, only a few are in the OOXML format which is not even finalized yet.  Except for an extremely small number of documents (a rounding error compared to the oft quoted ‘corpus of existing documents’), all OOXML documents will be “newly created” either by creating them from scratch or by converting existing binary documents.  If the differentiator between OOXML and ODF is the legacy compatibility features (see Response 926 for the revised scope), and these features are deprecated and not to be used, then why are we doing this in the first place?

But wait, there’s a Bonus Worst ...:

Worst ‘We’ll Get to it Later’ – (A TIE!)

Response 803 - The comments ask for a clear definition of the parameters in function definitions.  Ecma’s response promises these, but only supplies 3 examples of how changes will be made. Because the definition of the functions is central to the interoperability of spreadsheets, these are highly consequential changes.

Response 1 - Improper use of the word ‘shall’. There are over 6000 instances of them and Ecma’s response is: “Agreed; some uses of “shall,” “may,” and so on, are inconsistent. Rather than enumerate all places that need changes in this response, general comments on such usage will be addressed in an editorial pass over all parts.”

Interestingly, neither of these proposed dispositions (if accepted at the BRM) can be reviewed until the final draft of DIS 29500 is available, which is likely to be after many of the National Bodies will meet to finalize their votes.

For those with access to Ecma’s proposed disposition document, here are the NB comment numbers referenced to the Ecma responses:

Response 1 (AU-0007, DE-0042, DK-0076, ECMA-0018, GB-0014, JP-0006,
JP-0007, JP-0008)

Response 43 (AU-0016, BR-0046, CA-0044, CH-0006, CH-0007, CH-0017,
CL-0013, CL-0147, CO-0035, CO-0154, CO-0155, CO-0156, CZ-0009, DE-0030,
DE-0031, DE-0032 ,DE-0072 ,DK-0033, DK-0136, DK-0137, DK-0153, FI-0013,
FR-0182, FR-0183, FR-0351, GB-0300, GB-0301, GB-0304, GB-0363, GB-0364,
GH-0002, GR-0003, GR-0004, GR-0005, GR-0006, IE-0002, IN-0007, IN-0057,
IN-0058, IN-0061, IN-0080, IR-0001, IR-0002, KE-0054, KE-0055, MX-0005,
PE-0002, PE-0003, PH-0005, PT-0085, SG-0002, US-0130, US-0131, UY-0003,
VE-0011, VE-0060, ZA-0014)

Response 82 (BR-0057, CL-0209, FR-0373, GB-0485, PT-0111, US-0157)

Response 102 (CA-0037, CL-0027, CL-0028, CL-0055, CL-0197, CL-0202,
CO-0096, CO-0143, CO-0146, DK-0030, DK-0114, DK-0139, FR-0338, FR-0341,
FR-0345, GB-0219, GB-0291, GB-0292, B-0298, GH-0008, GR-0021, GR-0022,
GR-0076, IN-0010, IN-0026, IN-0063, IN-0064, IN-0077, IR-0012, IR-0047,
JP-0068, KR-0024, MY-0017, PT-0090, PT-0091, PT-0093, US-0027, US-0051,
US-0138, US-0144, US-0252, VE-0001, VE-0017, VE-0054, ZA-0009)

Response 222 (GB-0061)

Response 425 (DK-0031)

Response 559 (GB-0537)

Response 620 (IN-0011)

Response 624 (DK-0032 and ECMA-0045)

Response 691 (DK-0053)

Response 759 (FR-0147)

Response 782 (FR-0269)

Response 803 (FR-0453)

Response 862 (FR-0356)

Response 885 (GB-0013)

The ISO/IEC JTC 1 SC 34 Secretariat has published an informative guide to the rules for the Ballot Resolution Meeting (BRM) . The “Convenor,” Alex Brown, has used his blog to clarify the procedures and supply additional supporting information. Dubbed the “Man with the Gavel,” Brown has the unenviable task of running a 35-hour meeting involving 120 participants and 1000+ comments (whittled down from 3,522).

One issue that has arisen is whether National Bodies (NBs) should only concern themselves with Ecma’s responses to their own country’s comments. In his latest blog entry titled Tracking OOXML Issues, Brown chooses not to deviate from the JTC 1 Directives in passing judgment on this question: 

As the JTC 1 Directives explicitly state, the reason why all NB comments are distributed is to allow all NBs to form an opinion on all of them:

Upon receipt of the ballot results, and any comments, the SC Secretariat shall distribute this material to the SC NBs […] The NBs shall be requested to consider the comments and to form opinions on their acceptability. (13.6)

By extension, of course, NBs shall naturally be considering Ecma’s responses to these comments too. It is this considered national position that delegations will be taking to Geneva:

NBs […] shall appoint to the ballot resolution group one or more representatives who are well aware of the NB’s position. (13.7)

So, NBs need to do their homework so that delegations arriving at the BRM in Geneva are fully briefed. The delegation should ideally know their national position on all 1,000 or so distinct comment/responses that could be discussed. It is the responsibility of the delegation to faithfully represent their national position (not individual divergent delegate views), and to be prepared to respond to any fresh issues that arise in line with guidance their NB has given them.

I can understand why the “Man with the Gavel” wants to stick to the rules for what could be a difficult meeting to manage.  Beyond the rules, NBs should consider the comments of other NBs and form opinions on them.  After all, the new document that will likely be produced after the BRM will be significantly different from what was reviewed before September 2. Changes can be made for other NBs that affect the comments of your own NB, as well as modify the document in serious ways or raise new concerns for your NB.

Recall that Microsoft’s Office Open XML (OOXML) failed to achieve approval in the first round of balloting that ended September 2 2007. ISO fast-track procedures provide the submitter of a proposed standard, in this case Ecma, the opportunity to address the problems that national standards bodies (NBs) identified in the hope of persuading them to change their vote. Ecma’s Proposed Disposition of Comments was published on January 14, leaving precious little time for NBs before the Feb 25-29 Ballot Resolution Meeting (BRM). 

Consider the task ahead for any NB reconsidering its vote:
6,045 pages—the length of the OOXML specification
3,522 comments—the number of errors, ambiguities and omissions submitted by national standards bodies
2,293 pages—the length of Ecma’s proposed “fixes”

“Ecma’s Proposed Disposition of Comments on OOXML: How we got here; What is missing; Why you should vote no” will both lighten your reading load and explain just what is missing from the proposed “fixes”? Beyond the inadequacy of a six-week review period for over 1,000 changes (the total number of “fixes” proposed by Ecma) and the inappropriateness of the “fast-track” procedure (when normal procedures are available) for a specification of this magnitude, the proposal:

-Ignores the request from several countries and EU advisory bodies for harmonization between OOXML and the already ISO-approved ODF.

-Adds to the confusion between the trademarked name of OpenOffice (ODF’s first implementation) and the proposed standard, Office Open XML, or OOXML.

-Introduces new errors, inadequately addresses existing ones, and ignores many other errors altogether.

-Inhibits interoperability.

-Proposes contradictory solutions.

With just four weeks to go before the BRM, it is important for National Bodies to consider what has been “agreed” but not actually resolved; what has been “promised” but not actually delivered; and what has been left unaddressed altogether.

Marino Marcich
ODF Alliance