Narrative of the ISO/IEC DIS-29500 BRM Meeting

BRM Summary

I wanted to take the time to give a narrative of what actually happened in the BRM, since we’re now moving onto the final phase and I wanted to get this all in writing before I forgot. I wanted to give an overview of the topics discussed based on the documents that were published last week as well and provide a bit of commentary. While there has been a lot of discussion over the past week or two around the BRM, I think that much of it is misguided. Remember that the BRM wasn’t some sort of competition, and there we no winners or losers. The purpose of the BRM was to approve the changes to the specification necessary to help resolve issues that have been raised by the various national bodies. They kicked off their official review over a year ago (and many had been reviewing content well before that). The final decision on whether or not DIS-29500 will be approved is still a couple weeks away, but in terms of the BRM I believe it was a success and the goals were met.

The DIS-29500 Ballot Resolution Meeting (BRM) was an important milestone along the process of ratification of Office Open XML as an ISO/IEC international standard. On September 2 2007, 87 national bodies (NBs) submitted 3522 comments on the ECMA-376 Office Open XML specification. From these, Ecma International grouped the subjects covered by the 3522 NB comments in 1027 unique Responses, which were provided to all National Bodies on January 14th of this year. The BRM, held in February, passed 43 resolutions that resolved 1014 (98.7%) of the 1027 Responses, leaving only 13 (1.3%) not currently accepted. The details on the accepted dispositions (1014 = 189+825) can be found in the official ISO/IEC document Result of Proposed disposition of comments. The details on the 43 resolutions can be found in the Resolutions of the Meeting. I was personally impressed by the spirit of cooperation, consensus and common work on technical issues that was done during the BRM.

The Ballot Resolution Meeting

The International Standards Organization (ISO) and International Electrotechnical Commission (IEC) held the Ballot Resolution Meeting (BRM) as part of the ratification of the ISO/IEC DIS 29500 (Office Open XML) specification over five days in the last week of February, 2008 in Geneva, Switzerland. ISO/IEC described the goals of the meeting in their press release:

“The purpose of the BRM was to resolve comments submitted by the national member bodies of IEC and ISO on the draft and to reach agreement on proposed modifications arising from these comments with a view to making the document acceptable for publication as an international standard according to IEC/ISO criteria.”

There were two means to adopt proposed modifications:

  • Accept Ecma responses to the comments submitted by national body when those responses provide adequate solutions that enhance the specification. During the BRM, a half day on Wednesday was devoted to decide on the voting model to use in order to approve the dispositions. The voting model was unanimously adopted (29 Yes, 0 No, 2 Abstain) with wide consensus.

  • Raise proposals, create during the BRM new (or modified) responses and vote on them during the BRM. The following table categorizes the work accomplished in the BRM in terms of the individual Ecma responses individually and deeply discussed in the BRM and directly acted upon:

Topic Discussed

Responses Resolved



Better Organization


Better XML


Document conformance & Standards reuse






Grand Total


While the specification is already being implemented by a large number of applications, this meeting helped to improve it further. I assume that many of the folks present at the BRM will also be involved in the maintenance, and it was encouraging to see the group work together so well. We all accomplished a great deal of technical work, and improved the specification in numerous, very specific ways. As I said previously, I was personally impressed by the spirit of cooperation and common work on technical issues that was done during the BRM:

  • The 189 responses that were deeply discussed, modified and adopted by wide consensus during the BRM represent the vast majority of the most difficult and controversial issues that were discussed since more than 1 year by NBs: they correspond, by my estimates, to more than 1000 original NB comments.

  • The show of support for the vast majority of the Ecma responses demonstrates that Ecma took the comment process seriously and discussed in depth with NBs. I want to thank all the members of the NBs that participated in the review of Office Open XML. It also shows that the vast majority of the attendees of the BRM came prepared to properly assess the responses, and cast their vote appropriately.

The Ratification Process

To understand the BRM, it is helpful to have some background. On September 2, 2007, there was a vote by ISO/IEC member bodies on the fast-track adoption of the DIS 29500 Office Open XML specification. A national body (NB) could vote yes (with or without comments), no (with comments), or abstain (with or without comments). By a narrow margin, the specification was not accepted as is in September 2007.

As a result, the project Editor (helped by Ecma) was then tasked with drafting responses (technically termed the “project editor’s proposed dispositions”) about how the specification could potentially be improved. Typically, a response proposes a modification of, an addition to, or deletion from the specification. In some circumstances, a response comprised an explanation of why no modification of the specification was justified.

The process at the BRM consisted of the submission of and voting on resolutions as to whether to accept, modify or reject an existing Ecma response or create an entire new response. A BRM resolution (there were 43 of them, see Resolutions of the Meeting) typically covers one or more related responses, and each response typically covers one or more NB comments. Each attending NB delegation then voted to accept, reject, or abstain on each resolution presented at the BRM. The voting process and the resolution of the 189 responses were accepted by wide consensus.

The BRM Narrative

The following narrative lists the Resolutions of the Meeting that were submitted (in chronological order) during the BRM, the subject matter, the originating member country, a description of the subject of the resolution, optionally a brief description of interesting discussion by members, and the result of the resolution vote.

As an additional technical reference, for each BRM resolution, a list of the originating ISO/IEC member comments and corresponding Ecma responses are supplied in boxed text and take the form:

CountryCode – Comment# (Ecma Response#)

For the reader’s convenience, the first occurrence of a country code will be expanded in brackets, for example:

    [Australia] AU-28 (R 28)

This shorthand notation is used in other documents related to the ratification process. Note that one BRM resolution can cover one or more Ecma responses, and one response may cover one or more comments (in computer parlance, they form one-to-many relationships).

The technical documents produced by the BRM can be found at Documents referenced by the resolutions (1.7MB ZIP)

It is important to note that while specific NBs raised specific issues, the vast majority of the technical solutions were created by multiple NBs (and Ecma) working together.

Monday 2008-02-25


1.    Convert function    [Australia] AU-28 (R 28)
Australia wanted more international support in spreadsheet formulas. Formulas in a spreadsheet can call a function (CONVERT) to convert between various units of measurement. Australia proposed an updated CONVERT function that allows for a more complete and well-defined set of metric, imperial, and local measurements (such as the Japanese Cup). The new CONVERT function is more extensive and culturally inclusive. Approved unanimously.

2    Accessibility    [Canada] CA-69 (R 119), CA-72 (R 120), CA-73 (R 121), CA-75 (R 91), CA-78 (R 94)
Accessibility mechanisms in file formats improve access to documents for people with disabilities, and are especially important for technologies such as screen readers for the sight impaired. Canada wanted additional support for and documentation about accessibility. Although Office Open XML already contained a rich set of accessibility features Canada proposed a set of additional accessibility functionalities which currently exist in other document formats. Equally important for developers, an Accessibility Guidelines supplement is now included as an official annex to the spec. Approved.

3.    Browser compatibility    [Brazil] BR-7 (R 42)
Brazil wanted improved interoperability with existing W3C standards by eliminating dependencies on specific Web browsers, such as Mozilla Firefox, Microsoft Internet Explorer, or Apple Safari. Instead, Brazil proposed a mechanism where applications can optionally customize content for browsers according to their support for different levels of W3C HTML, XHTML, and CSS content. Approved.

4.    Language identification      [Czech Republic] CZ-6 (R 16)
The Czech Republic requested that the standard use BCP 47 for language identification. Language codes are used in documents to identify the language and locale of the content, for example, English as used in Canada. These codes are especially important in multilingual documents. Office Open XML originally represented these through the use of predefined two-digit hexadecimal codes. To increase interoperability, the Czech Republic proposed that the primary mechanism to identify languages be changed in accordance with an existing international standard (IETF BCP 47), which uses a string pair representation, for example “en-CA”.

To preserve fidelity in field codes, the standard also provides transitional support for the use of legacy language codes. The standard includes a complete mapping between legacy language codes and BCP 47.

This level of language support enhances interoperability in two ways:

•    Using BCP 47 codes enables interoperability with other applications that use BCP 47.

•    This approach also enables legacy documents to be converted to Open XML with fidelity.


5.    Units of measurement     [Finland] FI-10 (R 705)
Finland wanted changes in the specification to make the resulting markup much more readable and consistent with regards to units of measurement. Office Open XML supported a wide variety of length measurements used to specify characteristics of graphical objects, such as fonts, geometric shapes, cell sizes, and so on. However to increase uniformity and processing efficiency, Czech Republic proposed that lengths should be represented as defined by the international standard ISO/IEC 10179 (DSSSL). This standard also limits length units to only cm, mm, in, pt, and pc. Approved.

6.    Percentages     [Finland] FI-10 (R 705)
Finland wanted changes in the specification to make the resulting markup much more readable and consistent with regards to percentages. Office Open XML supported a wide variety of notations to represent percentages. Finland proposed that percentages be represented in a decimal format, for example “12.3%”. Exceptions to this rule are allowed when homogeneously representing 50ths and 1000ths of a percent. This improvement makes the resulting markup more readable and consistent. Approved.

7.    Dates     [Germany] DE-28 (R 18), DE-30 (R 43)
Treatment of dates going forward is perhaps the most important improvement produced by the BRM. At the same time, the transitional features of Open XML adopted by the BRM preserves fidelity of legacy documents, which is a primary design goal of Open XML.

For technical and legacy reasons, the representation of dates is a complex and sometimes contentious topic. For example, spreadsheet calculations can have deep dependencies on dates and preserving the same calculated values is of utmost importance with legacy documents. Also for processing efficiency that scales to very large spreadsheets, Office Open XML represented dates as serial numeric values. Germany proposed to create a new datatype on cells for storing dates per the ISO 8601 standard. For the purpose of calculations, it’s necessary at times to convert a date into a serial value and the date bases are used for this purpose (just like ODF and OpenFormula do). Additionally, the BRM considered how to deal with legacy spreadsheets that may have hidden dependencies on a leap-year bug introduced by Lotus 1-2-3 in the mid-1980s.

Thirty three national bodies requested that the standard use ISO 8601 for dates. This topic was perhaps the most animated agenda item of the BRM. Australia suggested using the approach to dates taken by ODF. With only 3 of 31 delegations dissenting, the BRM approved Germany’s proposal, and defines storage of dates solely in conformance to ISO 8601. This consensus of the participants of the BRM on this important topic validates the effectiveness of the BRM. Approved with 19 in favor, 3 against, 9 abstentions.

8.    Equations in VML     [Greece] GR-14 (R 80)
Because mathematical equations use specific features that are not support in MathML, they are represented by the Office Math Markup Language (OMML). Open XML also allows implementers to provide math equations using the W3C MathML. In this proposal about VML, Greece proposed an editorial correction of the Office OpenXML spec, specifically that in referring to MathML the phrase “Working Draft specification” be replaced with “Recommendation MathML version 2.0”. Approved.

9.    Equations in VML     [Greece] GR-14 (R 80)
Office OpenXML flexibly supports graphical and geometric objects primarily through the DrawingML and legacy VML markup languages, which like OMML, are shared among all the office document formats. Greece noted that the legacy VML specification allowed equations to be represented as an application-defined string of escaped XML characters. Instead, Greece proposed that a new equationXml element contain this information. To transitionally support legacy applications, the escaped XML string can be optionally supported. Approved.

10.    Conformance classes, strict and transitional      [India] IN-56 (R 472, see also R 92)
India had concerns with the concept of “Deprecated features” and an important discussion was held during the BRM. Canada took the action items to draft a new approach.Canada proposed to introduce strict and transitional conformance classes in order to implement a more formal separation between features that should be used generally and certain features that are only used to enable a high fidelity migration of legacy documents. The new specification will reflect this organization and schemas for strict conformance created. This emulates the strict and transitional concepts of html. This important work clarifies and informs application developers on appropriate approaches towards specification conformance. Approved.

Draft: Compatibility settings    [Ireland] IE-10 (R 34)
Ireland proposed that this response be amended to delete the sentence: “In addition, we will remove each of these settings (and all other application compatibility settings) from their current location in the specification (Part 4, §2.15.3, pages 1,368-1,487), and place them into a new annex for deprecated features”. Rejected (but see following and related resolution (11) that was approved).

11.    Compatibility settings    [Ireland] IE-10 (R 34)The legacy compatibility settings is one of the subjects that received perhaps the most attention during the process of approval of DIS 29500. One of the principle goals of DIS 29500 is the faithful representation of legacy documents. The project’s editor/ Ecma responses provided full description of the compatibility settings. They were accepted in resolution 33 (see below). In this resolution (11), Ireland proposed that all compatibility setting be considered as a transitional features.  Approved.

12.    Unicode enhanced support [Israel] IL-23 (R 729)
Unicode is the primary international standard for encoding text information, covering almost all writing alphabets/scripts in current use today. Office Open XML was created with Unicode support as a foundation, as it assures interoperability and portability of content with the wide range of existing and future applications. Israel proposed that this support be explicitly pledged to follow the existing Unicode Consortium and W3C Unicode standards, and that a new annex be added that describes the implementation of bidirectional formatting. The support of right-to-left (RTL) and bidirectional string runs enables Office Open XML formats to represent and display national languages and multilingual documents with high fidelity. Approved

13.    OPC conformance           [Japan] JP-40, JP-46 
When reviewing the section on Open Package Convention (OPC), Japan noticed that the text could be clarified in four areas, for example the title of Annex H was somewhat misleading. Ecma revised these areas, ensuring that this area of the spec is complete and unambiguous. Approved.

14.    DrawingML spec organization     [South Korea] KR-18 to KR-24
South Korea proposed that the comprehension of the section on DrawingML could be improved if it was reorganized into the two subsections:

  • DrawingML Framework — describes the overall drawing framework.

  • DrawingML Components — details individual component text, charts, tables, and diagrams.

The proposal from South Korea was accepted. Approved.

15.    Conformance class spec                [South Korea] KR (See BRM resolution #10)
BRM resolution #10 defined distinct conformance classes to represent strict and transitional features; documents and applications must support the former and may optionally support the latter.  After reviewing the documentation for the proposed changes, South Korea noted a number of areas where the documentation could be improved, mainly through reorganization and clarification of phrasing. Resolution 20 approved the standard be split in Parts. This resolutions defined the number of Parts to be 4.Approved. 

16.    General documentation               [Canada] CA (ad hoc)
As a technical editorial change, Canada proposed to remove the phrase “(all parts)” from any reference in the specification to ISO/IEC 10646:2003, which specifies the Universal Multiple-Octet Coded Character Set. Approved. 

Tuesday 2008-02-26


17.    VML as a transitional feature        [Mexico] MX-3 (R 857) MX-6 (R 92)
VML is a legacy graphical markup language used in legacy versions of office documents. Mexico proposed wording to explain why VML needed to be kept as part of the standard but that all of the VML specification be placed into the transitional section.Approved.

18.    Accessibility        [New Zealand] NZ-11 (R 94)
New Zealand wanted more clarification on accessibility. The proposal was that a reference to the W3C Web Accessibility Initiative (WAI – see documentation on accessibility shall be inserted by the Editor. Approved.

Draft: Scope        [Norway] NO-1 (R 925)
Make the overall scope of ISO/IEC DIS 29500 the following: “This International Standard defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. The goal of this standard is to represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been produced by Microsoft Office applications. It also specifies requirements for consumers and producers of Office Open XML.” Rejected: 10-13.

19.    Scope        [Norway] NO-1 (R 925)
Norway wished to have clarity on exactly which versions of Microsoft Office are relevant to the purpose of DIS 29500, specifically to the ability to move documents forward with high fidelity (legacy format support). The proposal was to clarify the scope of the DIS by specifying that whenever Microsoft Office is referred to in scope texts, the texts should indicate that the relevant versions of Microsoft Office are from Microsoft Office 97 to Microsoft Office 2008 inclusive. Approved.

20.    Scope and Multi-part [Norway] NO-1 (R 925)
Norway wished to have more clarity on the scope and multi-part nature of the proposed standard. Many NBs worked together (US on the multi-part subject, Switzerland on the scope subject) .The final proposal agreed upon by consensus was to divide the specification into four parts (please refer also to resolution 15)

1) Fundamentals and Markup Language Reference
2) Open Packaging Convention
3) Markup Compatibility and Extensibility
4) Transitional Features

This important work makes the specification more readable and approachable. The scope of each part was also clarified and agreed upon by consensus. The conformance classes introduced in Resolution 11, used in conjunction with the new multi-part structure of the standard means that users and procurement policies can now ask explicitly that applications should save for example documents with a conformance class “strict” or as another example, archiving libraries can procure software that support both strict and transitional classes. Approved.

21.    Differences between ECMA-376:2006 and ISO/IEC 29500     BRM Procedural
The BRM instructed the editor to incorporate an informative specification of the differences between ECMA-376:2006 and ISO/IEC 29500. (ECMA-376 is the original Office Open XML specification published by Ecma in December 2006.) This will be an important part of the specification. It will make it easier for implementers of the specification to understand the differences between the ECMA and ISO standards. Approved.

22.    Errors in XML examples        [Poland] PL-3 (R 190
Poland proposed that all examples throughout ISO/IEC DIS 29500 shall be well formed

XML, valid (following the schemas), but taking in account that ellipses may be used to shorten examples. Also, in the course of checking the examples, Great Britain developed a checking tool that it was willing to share. Approved.

23.    Clarity of content type        [Portugal] PT-60 (R 98
Portugal wanted to enable producers to generate content that can be more easily handled by any consumer. There are several areas in the specification where components such as images, text, equations, or audio may be included as part of an Open XML document. The resolution was to add a table with a minimal number of encouraged standard formats, including:

•    Images: png, jpg

•    Text: UTF-16, HTML

•    Audio: mpeg audio

•    Video: mpeg video

•    Math, Equations: MathML 2.0, OpenXML Math

•    Annotations: InkML

The proposal was approved.

24.    Application conformance        [Portugal] PT-60 (R 98)
Great Britain and Portugal wanted to define more exactly what a conforming application is. Furthermore, they desired to define a “base” application conformance class (has an understanding of at least one feature within its conformance class), and a “full” application conformance class (has an understanding of every feature within its conformance class). This important resolution makes it easier for developers of a producer or consumer of Open XML to categorize the behavior of their applications. Approved.

25.    Bitfields (bitmasks)       [Great Britain] GB-182 (R 135)
Great Britain, along with a number of other countries, took exception to the use of bitfields in an XML document. While bitfields could be processed by traditional XML processing tools, it is more readable to avoid using bitfields. Ecma was sensitive to this, and proposed replacing all bitfields with sets of attributes. This increases the readability of the resulting XML, and simplifies its processing. Approved.

26.    List numbering        [US] US-75 (R 65)
The Ecma responses proposed an important set of changes and the United States sought some more clarity on the way numbered lists were handled from an international point of view. The BRM accepted the Ecma responses and approved the US needs for clarifications. Approved.

27.    Schemas line-numbered in an Annex    [Australia] AU-12 (R 9)
The BRM decides that ISO/IEC DIS 29500 shall be contained in a normative annex and shall be line numbered. Approved.

28.    No normative schemas repeated in the body text     [Australia] AU-28 (R 9)
The BRM decides that no part of the schemas shall be repeated normatively in the body text. This proscription avoids unnecessary duplication and minimizes version conflicts. The body text shall refer to schema constructs by: annex number, clause or subclause number, and declaration name; and by the line number for convenience. Approved.

Draft: No normative schemas repeated in the body text     BRM Procedural
Canada moved that no part of the schemas shall be repeated in the body text. Rejected: 7-19.

29.    Appropriate handling of escaped characters        [Canada] CA-64 (R 84)
To allow maximum interoperability with other XML standards such as SOAP and RDF, Canada wanted a canonical approach with regards to XML and escaped characters. Canada proposed that the inclusion of escaped non-XML characters should be transitional and not allowed for new documents . Approved.

30.    Security descriptors        [Brazil] BR-43, CA-41 (R 74)
Brazil and Canada wanted better XML practices when specifying security descriptors. Security descriptors define the user accounts that may edit a particular range. The attribute that used a non-standard form of specification of multiple values was moved to the transitional section, and a new repeating element named securityDescriptor was introduced. The new element then can specify multiple user accounts without specifying multiple values in a single attribute. This results in clearer XML that is easier to program with. Approved.

31.    Hashing algorithms        [Czech Republic] CZ-53 (R 41)
The Czech Republic wanted clarifications for how to use using UTF-16 encoded strings with the hashing algorithms. Additionally South Africa’s wanted to remove the legacy hashing algorithm but this was countered by Denmark and the United States who noted that legacy documents must be supported and the legacy hashing algorithm was kept in the standard. The proposed resolution approves the Czec Republic proposal and clarifies that the leading BOM character in the encoded password is removed before hash calculation. Approved.

32.    Hashing algorithms        [Czech Republic] CZ-53 (R 41)
The Czech Republic wanted clarifications for how to use using UTF-16 encoded strings with the hashing algorithms This resolution clarifies that a string shall be converted to UTF-16LE before hash calculation. Approved.

33.    Legacy compatibility settings        [Denmark] DK (R 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 34)
The legacy compatibility settings is one of the subjects that received perhaps the most attention during the process of approval of DIS 29500. One of the principle goals of DIS 29500 is the faithful representation of legacy documents. The project’s editor/ Ecma responses provided full description of the compatibility settings. In addition of accepting the project editor’s responses to document legacy compatibility settings, there was a proposal to include a bi-directional cross-reference between the legacy compatibility settings and the new compatibility settings element. Approved.

34.    Eliminating repetitive text        [Finland] FI-6 (R 21)
Finland wanted to reduce redundant text, which would then reduce the size of the specification, and proposed an approach such that certain text (for example the value of a complex type) would only be written once into the specification. This ‘base’ text would then be referenced from other places. This proposal results in a specification that is shorter, easier to read, and easier to maintain. Approved.

35.    Alternative format input parts        [Germany] DE-150 (R 140)
A WordprocessingML document is composed of one or more parts and the spec allows these parts to use an alternative format. Nine national bodies submitted comments regarding the alternate format input part. The BRM discussion considered a number of alternative formats, including OO Math Markup Language and MathML, and support for legacy formats. Germany proposed to limit alternative format input parts to content in one of the following four standardized formats: text, HTML, XHTML, and WordprocessingML. This enables flexible importing of a wide variety of data, but by limiting to these formats, interoperability is improved. Approved.

Wednesday 2008-02-27


36.    Miscellaneous editorial proposals           BRM Procedural (see description)
The Ecma responses have been available to NBs since January 14, 2008.  Because these proposals were editorial and straightforward, they generated little need for full discussion of the NB members during the BRM.  This resolution proposed that the following responses be accepted without individual discussion (“R” prefix implied for each):
104, 171, 193, 197, 217, 218, 219, 242, 250, 253, 259, 260, 262, 275, 277, 278, 281, 297, 298, 314, 320, 321, 360, 367, 381, 382, 395, 398, 399, 400, 401, 404, 406, 407, 408, 420, 437, 442, 443, 446, 449, 451, 455, 456, 457, 459, 460, 478, 487, 488, 496, 513, 518, 520, 523, 524, 525, 527, 528, 547, 549, 560, 561, 563, 565, 608, 611, 632, 637, 638, 639, 648, 649, 650, 651, 652, 653, 654, 655, 656, 657,661, 662, 663, 664, 665, 666, 667, 668, 669, 670, 671, 672, 673, 674, 675, 677, 679, 680, 681, 682, 683, 684, 685, 686, 687, 688, 737, 739, 740, 768, 814, 825, 827, 851, 852, 868, 873, 881, 896, 912, 916, 919, 922, 941, 984.

This proposal was approved with only three national bodies opposed. 

Draft: Voting procedures for remaining proposals      BRM Procedural (all remaining)
Four variations on voting on the remaining responses were considered including voting to accept all the remaining responses, and to reject all the remaining responses. These drafts were either rejected or did not reach the consensus needed to be considered.

  • 37.    Remaining proposals      BRM Procedural (all remaining)
    The convener devised a process whereby each delegation could prioritize which topics where most important to them and discuss them during the BRM. There was a need to decide how to treat the remaining Ecma responses.  A half day on Wednesday was devoted to decide on the voting model to use in order to approve the remaining responses. As a result, this resolution proposed that the disposition of the remaining responses be decided by simple majority using a paper ballet.  The paper ballot enabled the delegations to individually approve or reject each of the project editor responses.  The ballets were distributed Thursday afternoon and the votes were tabulated on Friday. Approved. The voting model was unanimously adopted (29 Yes, 0 No, 2 Abstain).

Thursday 2008-02-28


38.    Internationalization                [Israel] IL-31(R-703), IL-27(R-701), IL-4(R-726), IL-1(R-732), IL-19(736)
Israel noted the need for clarification to some of the parts of the specification concerning the following topics, respectively:

  • Better examples in the descriptions of the RTL properties used in the DrawingML spec.

  • Mirror indents of paragraphs in WordprocessingML.

  • Description of the rtl element in paragraph runs in WordprocessingML.

  • Descriptions of various elements that define paragraph layouts in in WordprocessingML.

  • RTL use in the ST_BrClear simple type in WordprocessingML.

Those dispositions provide significant advances in Internationalization and bidirectional language script to enable better support of languages such as Urdu, Hebrew and Arabic This proposal was approved. 

39.    Multiple schema processors        [Japan] JP-02(R-344)
XML schemas are used by XML parsers for validating the structure and content of XML files using the matching data model.  The Open XML reference schemas were fully compatible with the W3C XSD schema standard; however, the implementations of XML parsers have varying levels of XSD standard conformance.  Japan discovered during testing that these schemas were not processible by the Apache Xerces-J and Sun’s MSV validators because of a module importation problem.  Ecma agreed that supporting the broadest range of development and testing tools is an important priority and therefore modified the Office XML schemas to be compatible with many validators including the 2 previously cited by Japan. The updated Ecma schemas were adopted. Approved.

40.    Multiple schema support             [Japan] JP-05, JP-70, JP-74(R-634)
Many schema validation languages exist; each typically has its own strengths. Japan noticed that the Office OpenXML schemas were only supplied as XML Schemas, potentially limiting their use.  Ecma agreed that to guarantee widespread development and testing, the schemas should be available in other formats. For this release of the specification, Japan, in coordination with Ecma, has authored a version of the Office schemas in RELAX NG and updated the specification accordingly. Approved.

41.    Multiple \e switches in ADDRESSBLOCK        [Chile] CL-108 (R-147)
Chile wanted clarification on the behavior when multiple \e switches are specified for the ADDRESSBLOCK field code. The proposed disposition specified that multiple \e switches are allowed, and that more than one country or region can be excluded by specifying multiple switches. Approved.

42.    CEILING function        [Malaysia] MY-15 (R-30)
[Brian Upated 3-18-08 (I actually had the wrong resolution down, it’s now corrected though)] Malaysia noted that the CEILING function was not implemented in accordance with common practice (due to legacy support) when applied to negative numbers. The proposal was to use namespacing and create a new iso.ceiling function that had the correct behavior, and ecma.ceiling that would be marked as transitional and maintain the legacy behavior. Approved.

43.    Clarification of compression algorithms        [Mexico] MX-1 (R-231)
Mexico desired to have a normative reference to the compression algorithm used in ZIP (within OPC) by DIS 29500. The resolution stipulated that the implementer shall not use any compression algorithm other than DEFLATE. Approved.

For More Information

The ECMA 376 Office Open XML specification is available as a five-part Adobe PDF download from the Ecma International Web site (

The Ecma responses reference these format specs. These responses – in the form of separate HTML, Microsoft Word and PDF files – are available as a zipped archive at All of these documents are highly technical.

The BRM Convener, Alex Brown, has posted links to the official ISO/IEC BRM Documents on his blog ( and ). The official BRM Documents from ISO/IEC can be downloaded from the SC34 web site as PDF files:

Alex’s blog ( also contains other useful information about the BRM and the Office OpenXML standardization process.

Additionally, the Office Open XML Developer site ( is also is a great source for news, tools, demos, and detailed developer information about the Office Open XML formats.

Comments (26)

  1. yoonkit says:


    Hi. I think the burden of work during the last day must have gotten to you. CEILING was proposed to have 3 parameters, but Ecma said that this would break everything, and other countries would vote it down. So Rick and I spent the Friday morning trying to come up with a compromise and its now a prepended with a dot.

    i.e. iso.ceiling() gives the right answer while ecma.ceiling() gives the wrong answer for negative numbers.

    [We wanted namespace type syntax i.e. iso:ceiling() and ecma:ceiling() but your techie said that your 1 token look ahead parser wouldnt be able to tell apart the XML namespace ‘:’ with the array range symbol as parameters. We took their word on good faith, and compromised with the dot notation]



  2. yoonkit says:

    Perhaps if you could, indicate WHEN these were resolved and Approved. Instead of giving the timetable when the items were raised, its more telling when the vote and final discussion took place.

    I believe then the proceedings wouldn’t look so orderly as your blog post may indicate.

    e.g. Monday and Tuesday probably had 98.4% items taken ‘off-line’ and resolved on Thursday or Friday.



  3. Andre says:

    "Germany proposed to limit alternative format input parts to content in one of the following four standardized formats: text, HTML, XHTML, and WordprocessingML. This enables flexible importing of a wide variety of data, but by limiting to these formats, interoperability is improved. Approved."

    Which would mean that e.g. OOXML could not become a container for the ODF file format.

  4. Marcus says:

    Hi Brian it’s a useful summary.

    One thing you didn’t mention is that a lot of the dispositions were already discussed before the BRM, so there was plenty of time to raise and consider issues before the meeting.


  5. Bob Jolliffe says:

    Hi Brian

    Whereas I think your narrative account is a useful addition to the various such accounts on the web, I find your characterisation of 189 "individual Ecma responses individually and deeply discussed in the BRM" something of an exaggeration.  As you point out yourself, some 126 responses were passed in a batch as being simply editorial.  The actual number discussed was much fewer.

    It seems that argument over the extent of the work done at the BRM is becoming something of a political football at present, with various parties trying to exaggerate the outcomes.  My own perspective (and I was also there) is that much of the work that was done was really good, but it was nowhere near the scale you suggest.  

    The majority of responses remained undiscussed.  Those which were discussed almost all resulted in a change to the original ECMA response.  Many of the discussions which occurred offline were resolved in something of a rush on Friday, with more than one resolution being approved before the text of that resolution was made available to the meeting.  You might recall South Africa raising an objection to this.

    Let us by all means acknowledge the good work which was done, but don’t try and extrapolate this into fantasy to make things look better than they in fact were.


  6. Rob Brown says:

    Hi Brian,

    I think you’re a pretty good wordsmith, and I admire your positive outlook. But (and there had to be a ‘but’ 🙂 this post is a clumsy bit of spin and doesn’t add anything to the information that’s already available.

    Let’s take the phrase "wide consensus", which you’ve helpfully highlighted in bold and italic. When referring to the no-discussion, paper vote adoption of 80% of the proposed responses, Jesper Lund Stocholm ( characterises it as grudging acceptance; other commentators have been a lot less diplomatic. Your version doesn’t wash.

    Likewise, in bold and underline this time, you’ve said that the "deeply discussed" 189 responses correspond "to more than 1000 original NB comments". What an odd choice of statistic! The immediate (and correct) rejoinder is "what about the complete lack of discussion on the other 2500 original NB comments?". If you think you can convince anyone that those 189 responses were all of the important ones, and the other 800 were somehow comparatively minor, you’re dreaming. And as for leaving those other issues until maintenance, that comes down to whether Microsoft can be trusted to diligently follow them up. You know how I stand on that point.

    Finally, a little story: Stephane Rodriguez ( and Rob Weir have posted factual articles on technical deficiencies in OOXML. I wanted to experience it for myself, and see if I could do some things with MS Office 2007/OOXML that I can already do with Calc/ODF. I tried to download a trial copy of MS Office 2007, but when I arrived at the registration screen the only choice for "Country" was "United States". This was even after I navigated to the site starting from I suppose I could have put in a bogus address, but it didn’t seem right. After trying for 45 minutes, using Firefox on Linux and Windows and also IE7 on Windows, I gave up. Was this just a temporary problem?

  7. marc says:

    Regarding the "wide consensus" , Brian, thank you for your kind PR words…

    But i stand by my numbers

    BRM abstention + refusal to vote + negative votes per country:

    Country         abst+no+refusal   Percentage

    ———–     —————   ———–

    China                     1027    100.00%

    Ireland                   1027    100.00%

    Ecuador                   1027    100.00%

    Netherland                1027    100.00%

    Mexico                    1027    100.00%

    Malaysia                  1022     99.51%

    Korea (s)                 1021     99.42%

    New Zealand               1018     99.12%

    Australia                 1008     98.15%

    India                     1005     97.86%

    Italy                      995     96.88%

    Belgium                    986     96.01%

    Israel                     983     95.72%

    Kenya                      970     94.45%

    US                         966     94.06%

    France                     965     93.96%

    Greece                     963     93.77%

    Portugal                   935     91.04%

    Japan                      934     90.94%

    Germany                    912     88.80%

    Canada                     886     86.27%

    South Africa               875     85.20%

    Denmark                    871     84.81%

    Brazil                     573     55.79%

    Switzerland                349     33.98%

    UK                         187     18.21%

    Czech                        7     0.68%

    Finland                      6     0.58%

    Poland (O member)            4     0.39%

    Chile (O member)             1     0.10%

    Ivory Coast (MS HOD)(*)      0     0.00%

    Norway                       0     0.00%


    By the way, you (Microsoft) and ECMA should be ashamed to use the fast-track mechanism to put another bulk of pages ( +400 ) with wide changes ( including change of scope and conformance terminology for god sake! ) that try to address the problems that should have been fixed by Microsoft/ECMA *before* throwing this beast to fast-track.

    I will suggest Microsoft XML team and ECMA to learn a little of "standardization behaviour" from the Adobe team: they did their homework  lot of months *before* ever thinking about submitting PDF to ISO guts and before any ballot ( note: PDF has been fast-tracked with a 93% approval vote ):


  8. Anonymous Coward says:

    Regarding those little technical details, here’s first hand experiences from someone actually trying to code and implement OOXML in real life:

    Just proves what have been posted about it earlier, others will have to check both the standard OOXML and the OOXML produced by the de facto reference implementation. So here we go back to the ’90s, to the days of IE/HTML/CSS games..

  9. hAl says:

    marc, you table is menaingless unless when you ad certain columns even though th colums were seperate in the source.

    Why don’t opponents not show us the original voting numbers but their own intepreted version?

    Why is there a need for opponent to alter the voting figures to try and make a point?

    As it the task of the BRM to accept changes to the proposed draft why are you not producing numbers that shows how many changes were accepted by the BRM. Your numbers are purpously altered in such a way that they do not show the actual result of the BRM anymore. I guess that is what being against Ofice Open XML is about?

    Manipulating the numbers when you don’t like them?

  10. marc says:


    "marc, you table is menaingless unless when you ad certain columns even though th colums were seperate in the source."

    you are free to interpret the numbers as you like, i only posted them; if you find any mistake in the numbers, let me know ( but i won’t send you a check like Donald Knuth 😉

    "Why is there a need for opponent to alter the voting figures to try and make a point?"

    first, i’m not an opponent, i’m an advocate of restoring the quality in standardization instead of "standardizing by corporations" [1]

    If you read my comments in brian’s blog you will see that i’m consistent in my critics since day one [2].

    Second, i didn’t altered anything;

    for example you can ask[3] Wemba Opota about his bulk approve. By the way ask Wemba Opota why he approved ECMA responses 240 , 245 , 246 , 635  even though Japan National Body delegates expressly alerted about "several errors" in this responses "based on misunderstandings on Japanese/Asian text handling" ( Japan voted "disapprove" in BRM to all this ECMA responses, but the bulk approvers reversed this vote ). Totally *irresponsible*.

    Shame on Côte d’Ivoire citizens: they have a Microsoft manager in charge of its national interests in international standardization matters ( and they are P-members of ISO JTC1 !   thanks to JTC1 diligent work: they gave  Côte d’Ivoire P-member status a few days before September/2007 ballot closing, just to cast an "unconditional approval" vote ).

    Shame on ISO JTC1 that gave power of vote to O ( OBSERVING not PARTICIPATING ) members like Poland and Chile at the BRM, contradicting the spirit of JTC1 Directives ( clauses 3.2, 7.7.4, 9.1.4 ) [4] . This O members didn’t participate in the BRM ( the Chilean HOD arrived at Geneva on Wednesday, attended the BRM only Thursday and Friday, only to threw a bulk approve to 1027 comments and leave Geneva the following day. Poland delegations virtually didn’t speak at BRM.

    "Your numbers are purpously altered in such a way that they do not show the actual result of the BRM anymore."

    Give me a break, i didn’t alter anything. Request from ISO JTC1 the numbers if you don’t believe me or search the spreadsheet yourself on the internet ( it was posted online a week ago ).






  11. marc,

    it’s funny you should mention PDF in ISO, because that standardisation process contains all the fuel that feeds the flames of the ODF/OOXML-debate: proprietary formats, backwards compatibility, no community involvement in the process etc.

    Given the interest in the OOXML-standardisation due to "pure principal arguments" and underlining the importance of standardisation through broad industry consensus and not stand-alone corporations, I’m surprised you guys have not been equally frantic about IS 32000.

    Two possible reasons for this could be:

    1. It’s not as fun attacking Adobe as it is atacking Microsoft

    2. Have you read the spec? It’s really hard to read and a totally different spec than both ODF and OOXML

    Just for the fun of it – look at chapter 3 p. 56 where it says:

    Hexadecimal Strings

    Strings may also be written in hexadecimal form, which is useful for including arbitrary binary data in a PDF file. A hexadecimal string is written as a sequence of hexadecimal digits (0–9 and either A–F or a–f) enclosed within angle brackets (< and >):

    < 4E6F762073686D6F7A206B6120706F702E >

    OMG – where is all the people screaming "Arbitrary binary data?, PDF is a ticking security-nightmare!" or "Arbitrary binary data?, a clear case of vendor lockin!".


    Please look at the summary Adobe made on what they changed for the ISO-version at

    Notice the paragraph saying:

    "The following is a summary of the changes that were made to the to the publicly available Adobe PDF 1.7 Reference in order to produce the ISO Draft. The technical content was maintained; only the presentation was changed."

    Where have you guys been?

  12. hp says:

    As someone said earlier, kudos to your wordsmithing.  It looks like the stuff you have put up here is going to be the basis of your organization’s efforts in trying to explain to not-fully-clued-in national bodies.  Par for the course I guess.  I appreciate that fact that you are trying to be fair and honest, but when facts are screaming out otherwise, why do you toe the official line?  Enough information from other BRM attendees point to a different reality than what you paint.  It is perhaps a big mistake that the BRM was not recorded for something as contentious as this should have been.

  13. hAl says:

    [quote]you are free to interpret the numbers as you like, i only posted them[/quote]

    That would hard as you did not post the original source info but only the manipulated info. I can’t change your manipulations back to for instance show seperate columns for approval and disapproval.

    I still wonder why you did not show those original numbers. You say you are not an opponent but showing the figures like you did by adding abstain votes to disapporval is only done by opponents. If you are not an opponent then don’t act like one !!!

  14. marc says:

    "I still wonder why you did not show those original numbers. You say you are not an opponent but showing the figures like you did by adding abstain votes to disapporval is only done by opponents. If you are not an opponent then don’t act like one !!!"

    i’m showing what i’m showing because my point is about the lack of consensus, lack of review and lack of quality of this DIS 29500 fast-track.

    jesper, about the binary thing in PDF, you seems to forget that PDF is not an XML format and that the PDF specification was *properly* published fifteen years ago [1] and that the Adobe CEO never wrote:


    One thing we have got to change in our strategy – allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company. We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities.

    "  [2]

    besides that,  my point was about taking seriously the work in standardization ( Microsoft and ECMA weren’t serious, they are just gamers of the system, but this is its nature, how do you think you keep billions of u$s stream in Office business? being really open and fostering competition in office applications?

    i’m surprised that you, that seems to *work* in standards matters advocate this crazy rushed process ; you have many things to learn from people like Martin Bryan, Alex Brown, why not? Donald Knuth  😉




  15. Ian Easson says:

    In case a random visitor to this blog reads what "marc" has to say and thinks it is anywhere near the unbiased truth, they should go and see a very different view of consensus at the BRM and what the BRM accomplished.

    A very balanced view (my opinion, of course) is from the ex-Secretary General of the ECMA.  Look at his blog posting at

    The high-level summary from his first paragraph says:

    "Ten days after the actual BRM, a view of what really happened during this event has now emerged: Consensus prevailed in the BRM and the specification became better."

  16. Rob Brown says:

    I have to admit that, even though I’m reading from a fairly anti-OOXML viewpoint, I still haven’t figured out what marc’s figures are actually saying! (No offence intended marc.) But surely it’s time to let the arguing over "what really happened at the BRM" end? We know what the resolutions were; I don’t think anyone’s going to seriously challenge any perceived irregularities.

    It’s all down to the NBs now, although I’m sure there’s lots of backroom activity going on that we will never find out about. Unfortunately for the NBs, no revised text of DIS29500 has been produced (to my knowledge) so each of them will have to do a lot of cutting and pasting to even get a document to review!

  17. Andre says:

    "Notice the paragraph saying:

    "The following is a summary of the changes that were made to the to the publicly available Adobe PDF 1.7 Reference in order to produce the ISO Draft. The technical content was maintained; only the presentation was changed."

    Where have you guys been?"

    You are right about the fun. But principles matter. It is of no use to say: others are equally bad.

    This format matters to the business environment. It is a multi-billion dollar business and why should we compromise with a second best solution?

  18. marc says:

    "A very balanced view (my opinion, of course) is from the ex-Secretary General of the ECMA.  Look at his blog posting at "

    Yes, balanced, good joke

    Jan Van der Beld is now paid by Microsoft to lobby for OOXML in National Bodies. He is one of the "standardization by corporations" champions


    (this was in an event last week in Lisbon)

    Jan Van den Beld said at 4:30:

    "ECMA for instance has made all the standards for DVD and optical disks. There were 5 recording formats. So there you are a little bit uneasy, of course. And again after a few beers I can ask the people in the room. Why do you want to have 5 formats? Do you still call that standardization?

    The answer is always the same:

    You are well paid. Shut up"



  19. Ian Easson says:

    I listened to that video.  All he way saying at 4:30 was that he was a paid employee of ECMA at the time the question of multiple DVD standards arose, and it was not up to him to question the need for multiple standards.

    ECMA is an industry standards organization.  If you find this world-threatening, you are paranoid.

    I saw nothing in the video that said "he is now paid by Microsoft to lobby for OOXML in National Bodies", as you claim.  What is your source for that astounding accusation?

    According to his blog profile, "I’m consultant in IT Standardization issues, working for organizations like Ecma International, CompTIA, SNV (Swiss National Standards Body)."

    Microsoft is not listed.

    Brian, any comment?  

  20. says:

    Sorry for not replying sooner folks:

    Yoon Kit,

    (1) Ceiling description was incorrect, and is now updated. Sorry about that. I appreciate again the work you and Rick did to pull together the proposal.

    Note that the issue with using ":" instead of "." wasn’t really as much around Excel itself but around the grammar for formulas. ":" already had a well defined meaning, and it wasn’t a good idea to override that. "iso:sum" could be viewed as a range of columns, or a namespaced function if we had gone with ":" instead of "."

    (2) I think showing these items in terms of when they were initially discussed and the offline work began is more appropriate. I agree that more things were closed out on Friday, but the work actually began after the intial discussion. When items were taken "off-line" that meant the countries interested worked on coming to a resolution they were happy with, and then presenting that resolution.



    You are absolutely correct, the review of these items started months ago. The first draft of the Ecma responses was given to the national bodies back in November, and we opened a line of communication at that point where NBs could contact us with questions. We continued that leading up to the BRM.

    The BRM was really the time where people brought up the issues they were not yet satisfied with and wanted to see further changes made.



    Sorry if it seems I’m trying to over exaggerate the results. Like you I agree that there was a lot of great work done. I also think we made a lot of progress in the months leading up to the BRM. I don’t remember South Africa calling in to any of the earlier discussions, but we did talk to a number of national bodies and aimed to pull together a response that would make everyone happy.

    If you look at the meaty topics discussed, they translated into a much larger number of national body comments. Most of the ones we discussed were raised by a number of countries, and often they were raised more than once by one country. So I think the percentages discussed were actually pretty good given the time we had.

    I’m really looking forward to continuing this work in maintenance.



    Not sure why you’re having those problems getting at the trial. You could also experiment with the Open XML support in OpenOffice in the mean time though.



    I agree with other folks that those numbers don’t really show much. I don’t even know how to reply as I’m not sure what the point is. I saw that table first from Andy Updegrove (OASIS attorney) and I didn’t see the purpose there either.



    I agree. The purpose of this blog was to primarily show what the changes were that happened so folks know what the final spec will look like.

    At this point it’s really up to the NBs to decide what they want to see happen with the spec


    Ian and Marc,

    Not sure about Jan’s employment. I talked to him briefly at the BRM, but we haven’t actually had a chance to sit down and chat since he retired from Ecma.


  21. marc,

    "jesper, about the binary thing in PDF, you seems to forget that PDF is not an XML format"

    Woah – so in your words, from an applications-perspective, interop- and security issues of including arbitrary binary chunks of data into a document format are only relevant, when the document format is XML?

    Pardon my French, marc, but are you nuts? :o)

    Also I think you need to pick up your favorite DOCX/PDF-version of the OOXML-spec and take a look at the binary blobs that have been so widely critizised and look how they are embedded in the document format. Hint: they are not embedded in the XML-files but in the OPC-package.

    "the PDF specification was *properly* published fifteen years ago [1] "

    So it is not really a big deal that the document format is vendor controlled – only when Microsoft is the vendor? It is not really a big deal that development is exclusive to the originator of the formet – only when the vendor is Microsoft? It is not really a big deal that the specification barely changed during ISO-submission and that the comments from the ballot has yet to be dealt with – only when the vendor is Microsoft?

    "[and] that the Adobe CEO never wrote:"

    I’m sorry to be the one to break the news to you, but it’s 2008 now and the software-world has changed quite a bit. That you use quotations from Bill Gates from 10 years ago as basis for your argument is really mind-baffling. I am sure, though, that you can find similar quotes from IBM-execs from the IBM-golden days in the 70ties that speak more or less to the same merit as the words of Bill Gates. As with Microsoft, IBM is a different company now.

    "i’m surprised that you, that seems to *work* in standards matters advocate this crazy rushed process ;"

    I am not advocating "this crazy rushed process" as such – I am advocating that the ISO-rules should be applied to ECMA as well as they were to OASIS when submitting their document formats. By changing the ISO-rules in the middle of the process (e.g. terminating the FT-process, which is not possible with the current ISO-rules) would have ISO create a defacto-monopoly for document formats … and we don’t want that, do we?

    "you have many things to learn from people like Martin Bryan, Alex Brown, why not? Donald Knuth  ;-)"

    Well, I think we all have a lot to learn yet … but why is Donald Knut relevant?


  22. Andre,

    "But principles matter. It is of no use to say: others are equally bad."

    I am not saying that.

    What I am saying is, that "you guys" (in a general setting) have been talking so much about principles, purity, community-involvement, engineering efforts, quality etc as your "pseudo"-arguments against OOXML. But if this was in fact true, you would have been banging no less on the doorsteps of Adobe and flooding their blogs for the last year or so as well.

    That the anti-OOXML lobby hasn’t done this tells me, that they don’t really care about these things anyway … this is just their chance to slap Microsoft around a bit. It’s just much less fun to beat on Adobe than on Microsoft.

    What’s the word I am looking for … ah yes … hypocricy.


    "why should we compromise with a second best solution?"

    We should not comprise with a second best solution. ISO has already decided what they regard as the characteristics for a document format to get ISO-approval (in PDF), and OOXML should be evaluated on the same characteristics. Otherwise the ISO-rules themselves will effectively be just another tool to hinder competition.

  23. marc says:

    "I saw nothing in the video that said "he is now paid by Microsoft to lobby for OOXML in National Bodies", as you claim.  What is your source for that astounding accusation?"

    one recent example:

  24. Pour faire référence à mon précédent post , voici un petit compte rendu rapide de cette journée, ou plutôt

  25. Tomorrow ( March 29th 2008 ) is the final day in which national bodies can reconsider their position

  26. Weddings says:

    BRM Summary I wanted to take the time to give a narrative of what actually happened in the BRM, since we’re now moving onto the final phase and I wanted to get this all in writing before I forgot. I wanted to give an overview of the topics discussed base