Freigeben über

Narrative of the ISO/IEC DIS-29500 BRM Meeting

  • Artikel

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

Accessibility

5

Better Organization

3

Better XML

4

Document conformance & Standards reuse

143

Internationalization

8

Multi-platform

26

Grand Total

189

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

Resolutions:

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.

Approved.

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

Resolutions:

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 https://www.w3.org/WAI) 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

Resolutions:

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

Resolutions:

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 (https://www.ecma-international.org/publications/standards/Ecma-376.htm).

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 https://www.itscj.ipsj.or.jp/sc34/open/0989_reference_docs.zip. 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 (https://adjb.net/index.php?entry=entry080310-094712 and https://adjb.net/index.php?entry=entry080306-082306 ). The official BRM Documents from ISO/IEC can be downloaded from the SC34 web site as PDF files:

Alex's blog (https://adjb.net) also contains other useful information about the BRM and the Office OpenXML standardization process.

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

Comments

  • Anonymous
    March 16, 2008
    The comment has been removed

  • Anonymous
    March 16, 2008
    The comment has been removed

  • Anonymous
    March 16, 2008
    "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.

  • Anonymous
    March 16, 2008
    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. Thanks!

  • Anonymous
    March 16, 2008
    The comment has been removed

  • Anonymous
    March 16, 2008
    The comment has been removed

  • Anonymous
    March 17, 2008
    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% () http://www.noooxml.org/forum/t-43510/ivory-coast-represented-by-microsoft-senegal-at-the-brm 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 ): http://www.aiim.org/documents/standards/isoformatting_070719.pdf http://blog.wired.com/monkeybites/2008/01/adobe-pdf-forma.html  --marc

  • Anonymous
    March 17, 2008
    Regarding those little technical details, here's first hand experiences from someone actually trying to code and implement OOXML in real life: http://blogs.sun.com/GullFOSS/entry/ooxml_import_in_writer_a 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..

  • Anonymous
    March 17, 2008
    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?

  • Anonymous
    March 17, 2008
    The comment has been removed

  • Anonymous
    March 17, 2008
    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!". :o) Please look at the summary Adobe made on what they changed for the ISO-version at http://www.adobe.com/devnet/pdf/pdfs/ISOFormatting_070604C.pdf 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?

  • Anonymous
    March 17, 2008
    The comment has been removed

  • Anonymous
    March 18, 2008
    [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 !!!

  • Anonymous
    March 18, 2008
    The comment has been removed

  • Anonymous
    March 18, 2008
    The comment has been removed

  • Anonymous
    March 18, 2008
    The comment has been removed

  • Anonymous
    March 18, 2008
    "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?

  • Anonymous
    March 18, 2008
    The comment has been removed

  • Anonymous
    March 18, 2008
    The comment has been removed

  • Anonymous
    March 18, 2008
    The comment has been removed

  • Anonymous
    March 18, 2008
    The comment has been removed

  • Anonymous
    March 18, 2008
    The comment has been removed

  • Anonymous
    March 19, 2008
    The comment has been removed

  • Anonymous
    March 25, 2008
    Pour faire référence à mon précédent post , voici un petit compte rendu rapide de cette journée, ou plutôt

  • Anonymous
    March 28, 2008
    The comment has been removed

  • Anonymous
    June 05, 2008
    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