decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
The Edited Notes and the Resolutions from the BRM - Updated 2Xs
Thursday, March 06 2008 @ 02:32 PM EST

Alex Brown has provided two documents from the BRM on OOXML on his blog. He got them from the open collection of documents published by ISO, another resource for us. You'll find many other documents in that same collection.

One of the documents Brown has provided is an edited version of the notes from the meeting [PDF]. Obviously, that isn't sufficient, since one has no way to know all that was edited out. The other is a list of the resolutions. Apart from wanting to see unexpurgated notes, and to listen to the audio reportedly made of the meeting, what is the most interesting from the documents, as Groklaw member PolR emailed me, is that even the edited notes confirm some details we've been reading. I think they also raise some procedural questions.

Here's what PolR noticed:

What stands out is the story published by Rob Weir on the four proposals, leading to the ballot is correct. The form ballot shown by Greece's delegate Antonis Christofides is also accurate. Alex Brown lists the options presented to the delegates but does not list what is option 3, just saying that it received no significant support. He also does not list the original option 4, just that it was amended. From Rob Weir's The Art of Being Mugged we learn that it was: "Option 3: Neutral third-party (ITTF) decides which Ecma responses are accepted" and "Option 4: Voting (approve + disapprove) must be at least 9 votes. Abstentions not counted". This ballot resulted into a resolution as follow:
Resolution 37 "Option 4 prime": The BRM decides to use the following form to decide, by majority voting, on each disposition of comments proposed by the Editor ("Response") which has not been explicitly accepted or rejected by the BRM in other ways (list enclosed). A simple majority of "Approved"s of the votes on that "Response" will be required to implement each Response; abstentions are not counted. In the event of a tie on a "Response", no editing instruction will result from that "Response" results of the vote: 29 in favour; none against; two abstentions (DE, BE): so resolved.

The other thing that stands out is the option 1 to accept all dispositions and option 2 to reject them all have been discarded by lack of consensus. So we can say that Alex claims they have used a consensus rule to discard the requirement of consensus for changing the DIS.

You can see the form ballot on page 5 of the resolutions document, along with the notes about switching to "simple majority":

Resolution 37 “Option 4 prime”: The BRM decides to use the following form to decide, by majority voting, on each disposition of comments proposed by the Editor (“Response”) which has not been explicitly accepted or rejected by the BRM in other ways (list enclosed). A simple majority of “Approved”s of the votes on that “Response” will be required to implement each Response; abstentions are not counted. In the event of a tie on a “Response”, no editing instruction will result from that “Response” — results of the vote: 29 in favour; none against; two abstentions (DE, BE): so resolved.

I think X marks the spot right there, where they may have run off the procedural rails. I have been unable to find anything from any Directive that would make a simple majority vote as they defined it the way to go or any evidence that rules can be invented midstream by NBs or that these four options are appropriate or the only choices to be presented. I'm still searching, of course, but making up rules on the fly is definitely drawing my eye. And you'll find the notes about deciding how to vote on pages 10 and 11 of the edited meeting notes, and there it's stated that "the Convenor presented four options". That would be Brown, and as I showed you the other day, he seemed to realize long before the BRM that there would be no time to cover all the resolutions unless something was done to put matters to a vote without discussion on each resolution. The availability of a form to distribute seems to me to confirm. So my question is, why not advise each NB in advance that this would be an issue, so folks could be prepared properly, if in fact NBs get to decide such things, which I doubt. It raises the question in my mind whether there were special detours and procedural favors designed to push this format forward when it otherwise would have died a natural death.

The question has to be, I think whether anyone with an agenda pushed simple majority as eventually defined because it was the only way to move the OOXML format onward as if it were succeeding. If you recall Weir told us in his article on The Art of Being Mugged: "We were told that these options are not in the Directives and that were are given these choices because ITTF 'needs to act in the best interests of the IEC'." So. That must be one part edited out of the edited meeting notes. I'm guessing the investigation into this whole process by the EU Commission will be looking into things like this, so I'm not overly worried, but I am disturbed and a bit shocked. How can NBs vote to establish a new process for the fast track in the middle of one? Did the NBs who were hurriedly voting have access to legal advice on the significance of their votes, for example? Is this normally what happens or was this specially conceived and implemented just for Microsoft's format? I think those are valid questions, and only the audio can establish the answers definitively.

Update: I note that Brown indicated back in January, in a comment in answer to a question, that the FAQ's interpretations were done by ITTF. Also, he has edited that article, which I quoted in the Malaysia article, so that it now reads as follows:

Now, paper balloting follows normal JTC 1 in-meeting rules:
In a meeting, except as otherwise specified in these directives, questions are decided by a majority of the votes cast at the meeting by P-members expressing either approval or disapproval. (9.1.4)

[Update 2008-03-06. This was the wrong clause. In-meeting Fast Track BRM voting is for resolving the comments of a constituency determined by the combined voting procedure (O-members + P-members) as per the JTC 1 Directives 9.5, and that is the understanding of the "normal JTC 1 procedures" in 13.8.]

Uh huh. Editing after the fact. I am supposing that this means they don't intend to admit this thing was and is a mess.

Rob Weir has an interesting article now, called "JTC1 Improv Comedy Theater", which points out that citing this clause, 9.5, can't be correct:

This is absurd. First, the combined voting procedure is for letter ballots given to an NB, not for a BRM meeting vote by a delegation. Second, the BRM was not voting on an FDIS, DIS, FDAM, DAM or FDISP. We were voting on whether to include changes into a set of meeting resolutions. We were told repeatedly that the BRM could not take a position on the DIS. Finally, if combined voting procedures are read as applying to Fast Track, then they would also need to apply to PAS, since both PAS and Fast Track are DIS's. But as shown earlier, the PAS process explicitly calls for P-member majority voting according to 9.1.4.

One does not arrive at the voting rules of 9.5 by any straightforward reading of the Directives.

So again, repeating from JTC1 Directions 1.2:

These Directives shall be complied with in all respects and no deviations can be made without the consent of the Secretaries-General.

I wasn't in favor of having any batch ballot, because it violates the spirit of the consensus process, as defined in JTC1 Directives 1.2:

These Directives are inspired by the principle that the objective in the development of International Standards should be the achievement of consensus between those concerned rather than a decision based on counting votes.

[Note: Consensus is defined as general agreement, characterised by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments. Consensus need not imply unanimity. (ISO/IEC Guide 2:1996)]

To resort to "counting votes" on the vast majority of the technical issues of DIS 29500, without discussion or opportunity for objection, this is a failure of the JTC1 process. But if we are to have a vote at all, it must be done in accordance with the rules.

So, let's stop the nonsense. Let's quit the tortuous post facto reinterpretation of the rules. Let's recount and republish the results of the BRM and move on with the process. If JTC1 cannot consistently adhere to its own rules, then it should consider another line of business.

[End update.]

Someone just sent me, appropriately enough, these documents in ODF format, and after I do the HTML, I'd like to post them here in plain text so those who depend on readers can easily follow along as well and so that they become more easily searchable. If anyone could volunteer to do the HTML and the check on those documents, I'd appreciate the help. Just email me if you can, with a comment left so we don't duplicate effort. Thank you.

Here are the Resolutions, followed by the Edited Notes, as text, thanks to Groklaw member ausage:

**********************************

ISO/IEC JTC 1/SC 34 SC 34 N 989

ISO/IEC DIS 29500 BALLOT RESOLUTION MEETING

Geneva, 2008-02-25..29

RESOLUTIONS OF THE MEETING GB 2008-03-01 18:20

Legend:

Red italics are used for Resolutions.

R mmmm =
Response “mmmm” contained in SC 34 N 980, i.e. a disposition of comments proposed by the Editor of ISO/IEC DIS 29500.

The files referred to are available on the BRM web site, managed by the ISO/IEC JTC 1/SC 34 Secretariat, or by default in a zip file available from ITTF.

Resolution 1: The BRM approves the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/AU28-draft.htm as a replacement for R 28 — so resolved.

Resolution 2: The BRM decides to accept the instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0075_and_CA-0078_Accessibility_Annex_V2.doc as a replacement for R 91; those in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0072_Document_Navigation.doc as an addendum to R 120, which is accepted; those in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0073_Image_Maps.doc as a replacement for R 121; those in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_NZ-0011_Table_Captions.doc as a replacement for R 94; and those in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0069_Labels.doc as an addition to R 119, which is accepted — so resolved.

Resolution 3: The BRM accepts the proposed response to BR-7 contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_BR-0007_Web_Browsers.doc but with an addition which makes it clear that the list is open-ended and with a correct reference for each entry — so resolved.

Resolution 4: The BRM accepts the proposed response to CZ-6 contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CZ-0006_ST_LangCode.doc as a replacement for R 16, but with the following change: column 2 of the first table shall be headed “Description (informative)” — so resolved.

Resolution 5: The BRM accepts the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0010_measurements_v2.doc with “informal” being replaced by “informative”, in replacement of R 364, R 19, R 705, R 362, R 620 and R 103 — so resolved.

Resolution 6: Additionally, the BRM accepts the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0010_percentages.doc but with the following changes: throughout the text, add the specific Unicode value U+0025 for the percentage sign; and

1 / 6 gb/jtc1/ooxml/brm/BRM_resolutions.doc

change all ranges to use the English words “from x up to [and including] infinity”, “inclusive[ly]”/&lduo;exclusive[ly]” etc. — so resolved.

KR objected to Resolution 6.

Decision: The BRM decided to retain the valIso, val, maxValIso, maxVal, refreshedDate and refreshedDateIso attributes and mark val, maxVal, refreshedDate “transitional”.

ZA and DE opposed the above decision.

Resolution 7: The BRM resolves to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_DE-0028_dates_v9.doc in replacement of R 18 and R 43, but with the following corrections: the words “ISO value” shall be replaced by the words “ISO 8601 value”; page 9, line 24 shall be restored and line 23 shall be marked “transitional”; and all changes as well as choices among alternatives rendered necessary by the Decision above shall be made — results of the vote: 19 in favour; 3 against (EC, US, ZA); 9 abstentions (JP, KR, IE, AU, BR, CN, NL, MX and GR): so resolved.

Resolution 8: In Part 4, 6.1.2.19, equationxml, p 4653, the Note shall reference “Recommendation MathML version 2.0”, not “Working Draft specification” — so resolved.

Resolution 9: The BRM resolves to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_GR-0014_equationxml.doc in replacement of R 80, but with the following change: the attribute proposed for removal shall be made into a “transitional” attribute instead of being removed, with a note making clear that the new mechanism is preferred — so resolved by consensus, with CZ, DE and JP dissenting.

Resolution 10: The BRM accepts R 92 and R 992 with the changes to these responses contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/CA_Conformance_Class_Proposa_Draft4.doc — so resolved.

Resolution 11: The BRM decides to accept R 34 with the change contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/IE-0010r.doc — so resolved.

Resolution 12: The BRM decides to accept the changes contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_IL-0023_bidirectional_annex.doc in replacement of R 729 — so resolved.

Resolution 13: The BRM accepts the proposed response to JP-40 and JP-46 contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/JP-040_and_JP-046_OPC_Conformance_-_Revised_v3.doc, in amendment of R 224 and R 211 which are otherwise accepted — so resolved.

Resolution 14: The BRM accepts the editing instructions contained in the section “ECMA: Proposal for Reorganizing DrawingML” of http://www.itscj.ipsj.or.jp/sc34/def/BRM/KR-18-24-DrawingML-ECMA.doc — so resolved.

Resolution 15: The BRM accepts the editing instructions contained in the following three files: http://www.itscj.ipsj.or.jp/sc34/def/BRM/Part_1_of_5_Conformance.doc , http://www.itscj.ipsj.or.jp/sc34/def/BRM/Part_5_of_5_Conformance.doc and http://www.itscj.ipsj.or.jp/sc34/def/BRM/US-multi-part_proposal_final.doc; with the understanding that the Scopes may be changed in a later Resolution, and the following changes: the proposed Part 4 (Primer) and the Annex covering accessibility guidelines shall become Annexes of the new Part 1; the following sentence shall be added after the sentence commencing “The Editor shall”: “The Editor is instructed to use ISO conformance language, ‘shall’, ‘should’ etc., in all normative text” — so resolved.

2 / 6 Resolutions of BRM 2008-02-25..29

Resolution 16: Remove “(all parts)” from any reference in the text to ISO/IEC 10646:2003: so resolved.

Resolution 17: The BRM accepts the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_MX-0003_VML.doc, as an amendment to R 92 in addition to those in Resolution 10 — so resolved.

Resolution 18: The BRM decides that a reference to the W3C “WAI” document on accessibility shall be inserted by the Editor — so resolved.

Resolution 19: The BRM decides that the text “(from Microsoft Office 97 to Microsoft Office 2008 inclusive)” shall appear in Scope texts after the text “Microsoft Office applications” — votes in favour: 17; against: 6; abstentions: 9; so resolved.

Resolution 20: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/MulitPartAndScope.doc, ignoring everything after “Pro- posed resolution”, and with the following additions: a forward pointer to any terms defined elsewhere shall be used as necessary; and the text “(from Microsoft Office 97 to Microsoft Office 2008 inclusive)” shall appear after “Microsoft Office applications” — so resolved.

FR objected to Resolution 20.

Resolution 21: The BRM decides to instruct the Editor to incorporate an informative specification of the following, with a reference to it from the Scope:
- All XML elements which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All XML elements which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All XML attributes which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All XML attributes which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All enumeration values which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All enumeration values which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All simple types which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All simple types which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
so resolved.

Resolution 22: The BRM decides that all examples throughout ISO/IEC DIS 29500 shall be well-balanced XML feasibly valid to the normative schemas, taking account of ellipses which may be used to shorten examples. The Editor is instructed to make these corrections, for checking by ITTF — so resolved.

Resolution 23: The BRM accepts the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/PT-60A2.doc as modifications to R 93, R 98, R 78, R 80, R 82 and R 100, which are otherwise accepted except as modified in other Resolutions; with the following changes: the MIME type of text shall be given as “text/plain” and the MIME type of HTML shall be given as “text/html”; and “Open XML Math” shall be replaced with a reference to the appropriate part of this specification — so resolved.

CA and CZ objected to Resolution 23.

Resolution 24: The BRM accepts the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/PT-60B2.doc — so resolved.

Resolution 25: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_0135_bitfields.doc in place of R 135, replacing “deprecated” by “transitional”, and with the following addition: The Editor shall ensure that all existing attributes defining the bitfields described above shall be “transitional” — so resolved.

3/ 6 Resolutions of BRM 2008-02-25..29

Resolution 26: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_US-0075_numbering.doc as a replacement for R 65, replacing in lowerLetter and upperLetter descriptions the word “language” with “script” and striking out the word “modern” — so resolved.

Resolution 27: The BRM decides that ISO/IEC DIS 29500 shall be changed so that the XML schemas are normative. The schemas shall be contained in a normative Annex and shall be line-numbered — so resolved.

Resolution 28: The BRM decides that no part of the schemas shall be repeated normatively in the body text. 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 — so resolved.

CA objected to Resolution 28.

Resolution 29: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0064_escaped_characters.doc in addition to R 84, which is otherwise accepted — so resolved.

Resolution 30: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/CA-041_BR-043_Security_Descriptor.doc in replacement of R 74, but changing maxOccurs of the securityDescriptor element from 255 to unbounded — so resolved.

Resolution 31: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/CZ-0053-corrected.pdf in replacement of R 41, and also to correct in the same way all other occurrences of UTF-16 in the context of serializing Unicode strings for cryptographic operations — so resolved.

Resolution 32: The BRM decides to accept1 the new text contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CZ-0053_hashing.doc — so resolved.

Resolution 33: With respect to “compatibility settings” the BRM accepts the Editor’s proposed editing instructions on this subject as captured by responses 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133 and 34, but additionally the Editor shall include a bi-directional cross-reference between the legacy compatibility settings and the new compatibility settings element — so resolved.

BR objected to Resolution 33.

Resolution 34: The BRM decides to accept the instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0006_repeated_complex_types.doc as an addition to R 21 which is otherwise accepted — so resolved.

Resolution 35: The BRM decides to accept the instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_DE-0150_alternative_format_import_part.doc as a replacement for R 140, with the following changes: the MIME types shall be corrected as in Resolution 23 — so resolved.

CZ objected to Resolution 35.

Resolution 36: The following responses are accepted and the corresponding editing instructions are issued to the Editor with the additional instructions given at the end: 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,


1 Note possible interference with R 102.

4 / 6 Resolutions of BRM 2008-02-25..29

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. In R 651, “when” shall be deleted. In R 739 and R 768 the NB proposed change shall be implemented. The change described in the NB proposed change in R 768 shall also be made in 2.16.5.44 and 2.16.5.45. In R 941 only the change from “contain” to “have” shall be made — resolved by consensus with three NBs opposed: BR, MY, ZA.

Resolution 37 “Option 4 prime”: The BRM decides to use the following form to decide, by majority voting, on each disposition of comments proposed by the Editor (“Response”) which has not been explicitly accepted or rejected by the BRM in other ways (list enclosed). A simple majority of “Approved”s of the votes on that “Response” will be required to implement each Response; absten- tions are not counted. In the event of a tie on a “Response”, no editing instruction will result from that “Response” — results of the vote: 29 in favour; none against; two abstentions (DE, BE): so resolved.

ISO/IEC DIS 29500 Ballot Resolution Meeting

== Voting Paper ==

National Bodies are requested to use this form to record their positions on proposed dispositions by the Project Editor as recorded in N 980, in accord with the resolution passed by the meeting.

Note: decisions taken in meeting sessions which apply to proposed dispositions shall override any results arrived at through counting National Body votes as registered using this form.

National Body _____________

We wish to record the following position for responses not otherwise decided upon in the resolutions of the meeting.

Approve [ ] Disapprove [ ] Abstain [ ]

We do not wish to record any position [ ]

Exceptions

Exceptions to the above default position (if any) may be recorded in the following table. If no default position is given above, the following are the votes we wish to submit.

Response
Number
Position
Approve [ ] Disapprove [ ] Abstain [ ]
Approve [ ] Disapprove [ ] Abstain [ ]
Approve [ ] Disapprove [ ] Abstain [ ]
Approve [ ] Disapprove [ ] Abstain [ ]
Approve [ ] Disapprove [ ] Abstain [ ]
Approve [ ] Disapprove [ ] Abstain [ ]

Responses decided upon in the BRM and therefore not subject to voting by the voting form:
9, 16, 18, 19, 21, 28, 30, 34, 41, 42, 43, 65, 74, 78, 80, 82, 84, 91, 92, 93, 94, 98, 100, 103, 104, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 140, 147, 171, 190, 193, 197, 211, 217, 218, 219, 224, 231, 242, 250, 253, 259, 260, 262, 275, 277, 278, 281, 297, 298, 314, 320, 321, 344, 360, 362, 364, 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,

5 / 6 Resolutions of BRM 2008-02-25..29

560, 561, 563, 565, 608, 611, 620, 632, 634, 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, 701, 703, 705, 726, 729, 732, 736, 737, 739, 740, 768, 814, 825, 827, 851, 852, 868, 873, 881, 890, 896, 912, 916, 919, 922, 925, 941, 973, 984 and 992.

Resolution 38: The BRM accepts, as a modification to the relevant Responses 703, 701, 726, 732 and 736 respectively which are otherwise accepted, the editing instructions contained in the five files: http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0001-Mati.doc, http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0004-Mati.doc, http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0019-Mati.doc, http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0027-Mati.doc and http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0031.doc, with the following change: example 2.18.44 shall be updated in an identical manner to example 2.3.1.13 — so resolved.

Resolution 39: The BRM accepts R 344 — so resolved.

Resolution 40: The BRM accepts R 634 and the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_JP-0070.pdf — so resolved.

Resolution 41: The BRM accepts R 147 — so resolved.

Resolution 42: The BRM accepts the editing instructions in the section “Option 2” contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/MY-0015-CEILING-Response-30-v9.pdf as a replacement of R 30 — so resolved.

Resolution 43: The BRM accepts R 973, and the instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/MX-0001_ZIP_compression_Proposal.doc as a replacement of R 231 — so resolved.

END

6 / 6 Resolutions of BRM 2008-02-25..29

**************************************

[Editor: Short blue lines have been added between entries in an attempt to separate the issues for easier reading. These lines are not in the original PDF and have been arbitrarily placed by the editor.]

ISO/IEC JTC 1/SC 34SC 34 N 990

ISO/IEC DIS 29500 BALLOT RESOLUTION MEETING

Geneva, 2008-02-25..29

EDITED NOTES OF THE MEETINGGB 2008-03-01 18:30

Legend:

Red italics are used for Resolutions.

CY-nnnn (where CY is a two-letter ISO country code) =
comment no. “nnnn” from country “CY” contained in SC 34 N 980.

R mmmm =
Response “mmmm” contained in SC 34 N 980, i.e. a disposition of comments proposed by the Editor of ISO/IEC DIS 29500.

The day shown does not usually correspond to the day the Resolutions were finally taken, but to the day the subject was first raised.


Monday 2008-02-25

Locale

AU-28 (R 28)

AU: Add a Locale attribute of ST type to the F element.

Ecma: list of enumerated values (for Locale attr.?).

Resolution 1: The BRM approves the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/AU28-draft.htm as a replacement for R 28 — so resolved.


BE: requests future convergence of all ISs in this area; no editing instruction for Edition 1.


CA-69 (R 119), 72 (R 120), 73 (R 121), 75 (R 91), 78

Accessibility for people with disabilities

Reference in R 91

Ecma: openxmldeveloper/../OpenXMLAccessibilityGuidelines.aspx, proposed for incorporation in future maintenance

CA: has submitted 12 pp of comments to these “Guidelines”, the response to which has generated more questions and comments from CA.

R 119 (CA-69), R 120 (CA-72), R 121 (CA-73): have generated/will generate proposed additions to the “Guidelines”, which will be added before it is inserted into DIS.

Resolution 2: The BRM decides to accept the instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0075_and_CA-0078_Accessibility_Annex_V2.doc as a replacement for R 91; those in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0072_Document_Navigation.doc as an addendum to R 120, which is accepted; those in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0073_Image_Maps.doc as a replacement for R 121; those in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_NZ-0011_Table_Captions.doc as a replacement for R 94; and those in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0069_Labels.doc as an addition to R 119, which is accepted — so resolved.

1 / 12 gb/jtc1/ooxml/brm/BRM_edited_notes.doc


BR-7 (R 42), compatibility with browsers:

Resolution 3: The BRM accepts the proposed response to BR-7 contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_BR-0007_Web_Browsers.doc but with an addition which makes it clear that the list is open-ended and with a correct reference for each entry — so resolved.


CN, CI: no editing instructions; CL, CO, CR absent at that time.


CZ-6 (R 16)

Resolution 4: The BRM accepts the proposed response to CZ-6 contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CZ-0006_ST_LangCode.doc as a replacement for R 16, but with the following change: column 2 of the first table shall be headed “Description (informative)” — so resolved.

The BRM decided that “the Legacy Language Identifier table shall be ‘transitional’.”


DK: no editing instructions beyond the Editor’s proposed resolutions of DK’s comments, which DK finds satisfactory, and would recommend the BRM to resolve to accept them.


EC-1 (R 1009): will support any acceptable solution to the date problem.


Units of measurement

FI-10 (R 705)

Ecma: the goals of Edition 1 are satisfied by the granularity chosen; the improvement proposed should be worked out thoroughly during maintenance.

Resolution 5: The BRM accepts the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0010_measurements_v2.doc with “informal” being replaced by “informative”, in replacement of R 364, R 19, R 705, R 362, R 620 and R 103 — so resolved.

Resolution 6: Additionally, the BRM accepts the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0010_percentages.doc but with the following changes: throughout the text, add the specific Unicode value U+0025 for the percentage sign; and change all ranges to use the English words “from x up to [and including] infinity”, “inclusive[ly]”/”exclusive[ly]” etc. — so resolved.

KR objected to Resolution 6.

p. 9: 92.000 or the alternative, but not both.

FR: wishes a distinction to be made in the standard between specifications for new OOXML docs and specifications for backwards compatibility [“deprecated”?], possibly by splitting into separate parts.


DE-28 (R 18), 30 (R 43) and a number of other NB comments: dates

DE and a number of NBs propose to use only ISO 8601 format, with a simple flag concerning what assumption about 1900 is implied (since only storage and not algorithmic treatment is concerned); US and many other NBs believe that backwards compatibility should be in an annex and deprecated; CH believes “ISO-8601-only” will not work because it is an oversimplification.

AU believes the ODF approach would be more effective.

2 / 12 Edited notes of BRM 2008-02-25..29


Decision: The BRM decided to retain the valIso, val, maxValIso, maxVal, refreshedDate and refreshedDateIso attributes and mark val, maxVal, refreshedDate “transitional”.

ZA and DE opposed the above decision.

Resolution 7: The BRM resolves to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_DE-0028_dates_v9.doc in replacement of R 18 and R 43, but with the following corrections: the words “ISO value” shall be replaced by the words “ISO 8601 value”; page 9, line 24 shall be restored and line 23 shall be marked “transitional”; and all changes as well as choices among alternatives rendered necessary by the Decision above shall be made — results of the vote: 19 in favour; 3 against (EC, US, ZA); 9 abstentions (JP, KR, IE, AU, BR, CN, NL, MX and GR): so resolved.


GR-14 (R 80)

Resolution 8: In Part 4, 6.1.2.19, equationxml, p 4653, the Note shall reference “Recommendation MathML version 2.0”, not “Working Draft specification” — so resolved.

Ecma: The whole escaping mechanism is deprecated within the VML section.

BR: existence of the future Annex to contain VML is not yet certain.

CN: believes that much that is deprecated is actually derived from actual (past) implementations, and that the number of specifications which are deprecated should be limited.

GB: to improve the syntax as GR suggests may have knock-on effects which would cause damage.

Resolution 9: The BRM resolves to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_GR-0014_equationxml.doc in replacement of R 80, but with the following change: the attribute proposed for removal shall be made into a “transitional” attribute instead of being removed, with a note making clear that the new mechanism is preferred — so resolved by consensus, with CZ, DE and JP dissenting.


IN-56 (R 472); see R 92:

Draft resolution (IN, BR): In R 92, p. 404, second para. of Proposed Disposition: accept the editing instruction constituted by the sentence beginning “Accordingly” but replacing the parenthesis by “(including those created by migrating existing binary documents)” and the word “should” by “shall”.

Resolution 10: The BRM accepts R 92 and R 992 with the changes to these responses contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/CA_Conformance_Class_Proposa_Draft4.doc — so resolved.

Original CA proposal: “Deprecated” is renamed as “Class 2”, feature by feature. In addition to all the conformance conditions not involving Class 2 features, the conformance clause is modified so that a Class 1 conformant document shall only contain Class 1 features; a document containing one or more Class 2 features is a Class 2 conformant document.

Ecma: the attempt to translate a document containing deprecated features, into one without them, sometimes involves loss of information.

GB: A phased approach to the migration from deprecated features to the others is needed, including the possibility to write documents with deprecated features.

DE: would favour this phased approach only for unmappable (i.e. not perfectly mappable) features.

AU: two conformance levels (two classes to which conformity may be claimed): full OOXML and legacy OOXML?

3 / 12 Edited notes of BRM 2008-02-25..29


IN, BR, CA, US, IE and any others will consult to describe the different cases of “deprecated”, to try and clarify the issues connected with legacy features. A draft resolution will be produced, for decision later in the BRM.


IE-2 (dates), 4 (ST_LangCode), 9 (Deprecation): already decided for more discussion and resolution later in the BRM.


IE-10 (R 34, Compatibility settings):

Draft resolution: An informative Annex giving references to all deprecated features, including compatibility settings, will be inserted in the standard.

Draft resolution: The semantics for compatibility settings should be included in the body of Word-ProcessingML.

IE proposal:

Draft Resolution: Accept R 34 with the deletion of 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.

Resolution 11: The BRM decides to accept R 34 with the change contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/IE-0010r.doc — so resolved.


IL-23 (R 729): Previous resolution:

  • p 1688, add to 1st bullet: Similarly, a run with rtl=0 shall not contain strong RTL characters
  • p 1692 l 5: directionality → order
  • p 1684, “bdo” → “dir” x 2 in box at top of page
  • p 1692, l 4 of table: “bdo” → “dir”.

Resolution 12: The BRM decides to accept the changes contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_IL-0023_bidirectional_annex.doc in replacement of R 729 — so resolved.

  • Five terms to express “right-to-left” (to be supplied by IL); replace by e.g. “rtlDisplay”
  • p 1685 ff: ensure all features provided in x.2 to apply to x.3, x.4 and x.5 — to be decided on Friday morning.

IT-2: would like to invite any NBs interested in this proposal to contact the IT delegation.


JP-40, 46:

Resolution 13: The BRM accepts the proposed response to JP-40 and JP-46 contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/JP-040_and_JP-046_OPC_Conformance_-_Revised_v3.doc, in amendment of R 224 and R 211 which are otherwise accepted — so resolved.

Previous draft: Accept the Conformance clause (clause 2) for Part 2 as specified in R 202 (DE-154) and R 992 (JP-27,28,29) with the following two modifications:

  • 4th para to be repeated for data streams, i.e. add the following paragraph: “A data stream is defined to be of conformance class OPC if it satisfies all the conditions applicable to data streams listed in this Part.”;
  • in 4th para, add “applicable to applications” in the relevant place.

4 / 12 Edited notes of BRM 2008-02-25..29


KE: no editing.


KR-18 to 24: proposal to remove components and/or separate them into different parts:

Resolution 14: The BRM accepts the editing instructions contained in the section “ECMA: Proposal for Reorganizing DrawingML” of http://www.itscj.ipsj.or.jp/sc34/def/BRM/KR-18-24-DrawingML-ECMA.doc — so resolved.

Resolution 15: The BRM accepts the editing instructions contained in the following three files: http://www.itscj.ipsj.or.jp/sc34/def/BRM/Part_1_of_5_Conformance.doc , http://www.itscj.ipsj.or.jp/sc34/def/BRM/Part_5_of_5_Conformance.doc and http://www.itscj.ipsj.or.jp/sc34/def/BRM/US-multi-part_proposal_final.doc; with the understanding that the Scopes may be changed in a later Resolution, and the following changes: the proposed Part 4 (Primer) and the Annex covering accessibility guidelines shall become Annexes of the new Part 1; the following sentence shall be added after the sentence commencing “The Editor shall”: “The Editor is instructed to use ISO conformance language, ‘shall’, ‘should’ etc., in all normative text” — so resolved.

CA:

Resolution 16: Remove “(all parts)” from any reference in the text to ISO/IEC 10646:2003: so resolved.


MY-16: Names

No consensus emerged on the MY proposal; a reformulation by MY remained possible.


Tuesday 2008-02-26

MX-3 (R 857), MX-6 (R 92)

Part of “deprecate” discussion. All of VML will be displaced into a (normative) (“deprecated”) Annex.

Resolution 17: The BRM accepts the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_MX-0003_VML.doc, as an amendment to R 92 in addition to those in Resolution 10 — so resolved.


NL: no draft editing instructions or discussion points.


NZ-11 (R 94) Accessibility: five proposals.

Resolution 18: The BRM decides that a reference to the W3C “WAI” document on accessibility shall be inserted by the Editor — so resolved.


NO-1 (R 925), Scope

Draft resolution

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

— result of the vote: for 10; against 13 — rejected.

5 / 12 Edited notes of BRM 2008-02-25..29


Resolution 19: The BRM decides that the text “(from Microsoft Office 97 to Microsoft Office 2008 inclusive)” shall appear in Scope texts after the text “Microsoft Office applications” — votes in favour: 17; against: 6; abstentions: 9; so resolved.

Resolution 20: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/MulitPartAndScope.doc, ignoring everything after “Proposed resolution”, and with the following additions: a forward pointer to any terms defined elsewhere shall be used as necessary; and the text “(from Microsoft Office 97 to Microsoft Office 2008 inclusive)” shall appear after “Microsoft Office applications” — so resolved.

FR objected to Resolution 20.

It was previously proposed to replace the Scopes of the various parts by the relevant re-edited versions of 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, on the one hand, to represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been [previously?] produced by Microsoft Office applications (from Microsoft Office 97 to Microsoft Office 2008 inclusive) and, on the other hand, to facilitate extensibility and interoperability. It also specifies requirements for consumers and producers of Office Open XML.”

Resolution 21: The BRM decides to instruct the Editor to incorporate an informative specification of the following, with a reference to it from the Scope:
- All XML elements which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All XML elements which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All XML attributes which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All XML attributes which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All enumeration values which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All enumeration values which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
- All simple types which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006
- All simple types which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006
so resolved.


PL-3 (R 190): errors in XML examples

UK: found many genuine errors (beyond ellipses and the fragment-ness of the examples), and are willing to share the results of the software tool used to check XML.

Resolution 22: The BRM decides that all examples throughout ISO/IEC DIS 29500 shall be well-balanced XML feasibly valid to the normative schemas, taking account of ellipses which may be used to shorten examples. The Editor is instructed to make these corrections, for checking by ITTF — so resolved.


PT-60 (R 98):

Resolution 23: The BRM accepts the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/PT-60A2.doc as modifications to R 93, R 98, R 78, R 80, R 82 and R 100, which are otherwise accepted except as modified in other Resolutions; with the following changes: the MIME type of text shall be given as “text/plain” and the MIME type of HTML shall be given as “text/html”; and “Open XML Math” shall be replaced with a reference to the appropriate part of this specification — so resolved.

CA and CZ objected to Resolution 23.

Resolution 24: The BRM accepts the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/PT-60B2.doc — so resolved.

6 / 12 Edited notes of BRM 2008-02-25..29


ZA-6 (R 6)

Restructuring into parts (“deprecated”, Primer): there should be a clear Scope for any (new) Part decided.

Ecma: R 6 gives a road map (overall architecture) of the Parts proposed.

ZA: believes R 6 is not precise enough and requests clear instructions to the Editor to be generated. (The proposed treatment of the Primer is acceptable.)

US: is already working with BR, KR & Ecma on this problem, and would be glad to involve other NBs: what new structure (Parts), ... .

AU: R 6 meets AU’s requirements already, and AU proposes to accept it (for now).

The BRM decided that ISO/IEC DIS 29500 would be split into multiple Parts (29500-1, 29500-2, 29500-3 etc.). Conformance criteria needed to be clearly stated for each Part.

BR objected to the above decision.

Proposed: The proposal in R 6 for 29500-1, 29500-2 and 29500-3 is accepted in principle. A Resolution must be drafted to describe precisely what is in each Part (including the Primer, “deprecated” features, conformance classes, etc.), and conformance must be clearly stated for each Part.


CH-17 (R 43)

Dates settled in a previous Resolution.


GB-182 et al (R 135): bit masks for values.

Proposal: change from bit fields to XML elements, except for fonts (which follow the relevant ISO standard).

DK: supports.

Resolution 25: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_0135_bitfields.doc in place of R 135, replacing “deprecated” by “transitional”, and with the following addition: The Editor shall ensure that all existing attributes defining the bitfields described above shall be “transitional” — so resolved.


US-75 (R 65): enumeration formats (Part 4):

Resolution 26: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_US-0075_numbering.doc as a replacement for R 65, replacing in lowerLetter and upperLetter descriptions the word “language” with “script” and striking out the word “modern” — so resolved.


AU-12 (R 9):

The repetition of complex type declarations in Part 4 introduces errors and gives duplicate and redundant normative text.

CA: some constraints may not be present elsewhere; even if they are, more work may be involved in looking them up if they are not included in line.

Resolution 27: The BRM decides that ISO/IEC DIS 29500 shall be changed so that the XML schemas are normative. The schemas shall be contained in a normative Annex and shall be line-numbered — so resolved.

Resolution 28: The BRM decides that no part of the schemas shall be repeated normatively in the body text. 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 — so resolved.

7 / 12 Edited notes of BRM 2008-02-25..29


CA objected to Resolution 28.

Draft resolution: No part of the schemas shall be repeated in the body text — results of the vote: 7 for, 19 against — rejected.

IL: same applies to descriptions of complex types: will be dealt with when separately raised.

BE


CA-64 (R 84): non-XML characters

CA Proposal: inclusion of non-XML characters should be “deprecated” (or equivalent).

BR proposal: OPC should be only method used for binary encapsulation.

Ecma: agrees with BR; word “binary” should be deleted; only strings are intended. Agrees with CA to “deprecate”.

CA: software can easily make sure that no such characters are written; future standard should guarantee this.

Ecma will propose a definition of “new document”, as in “A new document shall not be created using deprecated features; only revision of an existing document may do this.”

Resolution 29: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CA-0064_escaped_characters.doc in addition to R 84, which is otherwise accepted — so resolved.


BR-43 (R 74) (related to CA-41): securityDescriptor

Resolution 30: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/CA-041_BR-043_Security_Descriptor.doc in replacement of R 74, but changing maxOccurs of the securityDescriptor element from 255 to unbounded — so resolved.


CZ-53 (R 41)

Resolution 31: The BRM decides to accept the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/CZ-0053-corrected.pdf in replacement of R 41, and also to correct in the same way all other occurrences of UTF-16 in the context of serializing Unicode strings for cryptographic operations — so resolved.

Resolution 32: The BRM decides to accept1 the new text contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_CZ-0053_hashing.doc — so resolved.

ZA: The hash algorithm should be improved in spite of the desire to guarantee backwards compatibility.

DK, US: The hashes actually stored in legacy documents must be able to be dealt with in some fashion.

CA: Any use of an unsatisfactory hash, including that stored in a legacy document, raises incorrect expectations as to the document’s integrity, and so it should be omitted totally.

DK: It would be even worse if the spec mentioned nothing. Whether false expectations are set is up to the application.

CA: With the two sets of attributes the following may be the correct solution: when there is no algorithm name and the attributes are transitional ones, apply the legacy algorithm; if the attributes are strict ones the algorithm name must be specified.


1 Note possible interference with R 102.

8 / 12 Edited notes of BRM 2008-02-25..29


US: Clarify strict vs. transitional; default hash; thoroughly check this redesign. The issue is not a security one for the document (which is not protected), but only to protect the unencrypted version of the password itself.

ZA, CA, DK, US will work on this, for possible solution before Friday 17:00.

DK

Resolution 33: With respect to “compatibility settings” the BRM accepts the Editor’s proposed editing instructions on this subject as captured by responses 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133 and 34, but additionally the Editor shall include a bi-directional cross-reference between the legacy compatibility settings and the new compatibility settings element — so resolved.

BR objected to Resolution 33.

EC-1 Wishes to consider a text from GR on dates, and will work with GR off-line.


FI-6 (R 21)

R 21 raises a question on redundancy of complex type attribute descriptions.

Resolution 34: The BRM decides to accept the instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_FI-0006_repeated_complex_types.doc as an addition to R 21 which is otherwise accepted — so resolved.

FR has no items it wishes to have discussed currently.


DE-150 (R 140), 161

Ecma is willing to remove this feature.

Resolution 35: The BRM decides to accept the instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_DE-0150_alternative_format_import_part.doc as a replacement for R 140, with the following changes: the MIME types shall be corrected as in Resolution 23 — so resolved.

CZ objected to Resolution 35.

US: Delete lines 15-17 of page 28 of ISO/IEC DIS 29500 (Part 1, 11.3.1).

UK


GR-92 (R 93)

GR: extra functionality provided by OO Math Markup Language can better be implemented as a separate namespace vocabulary in MathML, rather than as an incompatible self-contained specification as is contained in ISO/IEC DIS 25900.

AU: elements not allowed by the schema being used are not possible in MathML v3 (schemas specify the elements they will allow, and if this is a closed set — no wildcard — then foreign elements will be illegal) [this was later contradicted].

Ecma: MathML is not designed to be extended (as confirmed by W3C), and the OOXML solution was proposed for this reason.

9 / 12 Edited notes of BRM 2008-02-25..29


ZA: OO MML is a large innovation, so an approach such as that suggested by GR would have merit.

CA: accessibility remains important, as much for OXML as for MathML, and CA is willing to work with others to advance this in the future.


IN-51 (R 973)

Ref. to external web site: ISO/IEC JTC 1 Directives and ITTF policy cover this, and the required specification will be and remain publicly available to users of International Standards.


IE-9 (R 92)

Continued compliance of legacy documents once future editions of OOXML are published (which presumably lose “deprecated” features).

CA: has some text concerning conformance classes which will be proposed when ready.

US: the corpus using “deprecated” features will continue to exist, and will continue to be conformant, because NBs will probably decide to retain the legacy features in future editions of ISO/IEC 29500.

MX: Legacy documents may be conformant to a specific part of 29500, which exists precisely to cover the existing corpus before edition 1 of 29500.


Wednesday 2008-02-27

Editorial: list provided by the Convenor:

Resolution 36: The following responses are accepted and the corresponding editing instructions are issued to the Editor with the additional instructions given at the end: 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. In R 651, “when” shall be deleted. In R 739 and R 768 the NB proposed change shall be implemented. The change described in the NB proposed change in R 768 shall also be made in 2.16.5.44 and 2.16.5.45. In R 941 only the change from “contain” to “have” shall be made — resolved by consensus with three NBs opposed: BR, MY, ZA..

Three priority issues: dates; conformance classes incl. “deprecation”; restructuring (linked to previous item).

Ecma update on ongoing tasks.

Discussion on possible treatment of all responses which will not have been discussed by the end of the BRM: the Convenor presented four options.

Draft Resolution “Option 1”: The BRM decides to accept and implement all the dispositions of comments proposed by the Editor (“Responses”) which have not been explicitly accepted or rejected by the BRM in other ways (list enclosed) — no consensus.

Draft Resolution “Option 2”: The BRM decides to reject all the dispositions of comments proposed by the Editor (“Responses”) which have not been explicitly accepted or rejected by the BRM in other ways (list enclosed) — no consensus.

10 / 12 Edited notes of BRM 2008-02-25..29


Option 3 received no significant support.

Option 4 was modified in discussion (Option 4 prime):

Resolution 37 “Option 4 prime”: The BRM decides to use the following form to decide, by majority voting, on each disposition of comments proposed by the Editor (“Response”) which has not been explicitly accepted or rejected by the BRM in other ways (list enclosed). A simple majority of “Approved”s of the votes on that “Response” will be required to implement each Response; abstentions are not counted. In the event of a tie on a “Response”, no editing instruction will result from that “Response” — results of the vote: 29 in favour; none against; two abstentions (DE, BE): so resolved.

ISO/IEC DIS 29500 Ballot Resolution Meeting

== Voting Paper ==

National Bodies are requested to use this form to record their positions on proposed dispositions by the Project Editor as recorded in N 980, in accord with the resolution passed by the meeting.

Note: decisions taken in meeting sessions which apply to proposed dispositions shall override any results arrived at through counting National Body votes as registered using this form.

National Body __________

We wish to record the following position for responses not otherwise decided upon in the resolutions of the meeting.

Approve [ ] Disapprove [ ] Abstain [ ]

We do not wish to record any position [ ]

Exceptions

Exceptions to the above default position (if any) may be recorded in the following table. If no default position is given above, the following are the votes we wish to submit.

Response
Number
Position
Approve [ ] Disapprove [ ] Abstain [ ]
Approve [ ] Disapprove [ ] Abstain [ ]
Approve [ ] Disapprove [ ] Abstain [ ]
Approve [ ] Disapprove [ ] Abstain [ ]
Approve [ ] Disapprove [ ] Abstain [ ]
Approve [ ] Disapprove [ ] Abstain [ ]

Responses decided upon in the BRM and therefore not subject to voting by the voting form: 9, 16, 18, 19, 21, 28, 30, 34, 41, 42, 43, 65, 74, 78, 80, 82, 84, 91, 92, 93, 94, 98, 100, 103, 104, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 140, 147, 171, 190, 193, 197, 211, 217, 218, 219, 224, 231, 242, 250, 253, 259, 260, 262, 275, 277, 278, 281, 297, 298, 314, 320, 321, 344, 360, 362, 364, 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, 620, 632, 634, 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, 701, 703, 705, 726, 729, 732, 736, 737, 739, 740, 768, 814, 825, 827, 851, 852, 868, 873, 881, 890, 896, 912, 916, 919, 922, 925, 941, 973, 984 and 992.

11 / 12 Edited notes of BRM 2008-02-25..29



Thursday 2008-02-28

Two rounds of review of all, and adoption of some, outstanding draft resolutions.

IL-31, IL-27, IL-4, IL-1, IL-19:

Resolution 38: The BRM accepts, as a modification to the relevant Responses 703, 701, 726, 732 and 736 respectively which are otherwise accepted, the editing instructions contained in the five files:
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0001-Mati.doc,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0004-Mati.doc,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0019-Mati.doc,
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0027-Mati.doc and
http://www.itscj.ipsj.or.jp/sc34/def/BRM/IL-0031.doc, with the following change: example 2.18.44 shall be updated in an identical manner to example 2.3.1.13 — so resolved.


IT: on a BE comment (R 44): proposal to come.


JP:

Resolution 39: The BRM accepts R 344 — so resolved.


R 229, R 634 — JP & Ecma

Resolution 40: The BRM accepts R 634 and the editing instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/Response_JP-0070.pdf — so resolved.


CL-108 (R 147): How many /e switches are allowed? Arbitrarily many (like all switches).

Resolution 41: The BRM accepts R 147 — so resolved.


MY-15 (R 30)

Resolution 42: The BRM accepts the editing instructions in the section “Option 2” contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/MY-0015-CEILING-Response-30-v9.pdf as a replacement of R 30 — so resolved.


MX-1 (R 231)

Resolution 43: The BRM accepts R 973, and the instructions contained in http://www.itscj.ipsj.or.jp/sc34/def/BRM/MX-0001_ZIP_compression_Proposal.doc as a replacement of R 231 — so resolved.


NL: none to discuss.


NZ-6, NZ-12, NZ-14, NZ-15, NZ-52: document provided on Thursday; resolved elsewhere.


NO:

R 425, R 624, R 977: object linking.

Draft Resolution: The BRM accepts R 425, R 624, R 977 — was intended to be decided on Friday.


Friday 2008-02-29

Discussions and approval/rejection of various draft resolutions.

END

12 / 12 Edited notes of BRM 2008-02-25..29



  


The Edited Notes and the Resolutions from the BRM - Updated 2Xs | 173 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
OT - Off Topic here
Authored by: SpaceLifeForm on Thursday, March 06 2008 @ 02:40 PM EST
Please make any links clickable.


---

You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

Corrections here
Authored by: SpaceLifeForm on Thursday, March 06 2008 @ 02:41 PM EST
If any.

---

You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

News Picks commentary
Authored by: SpaceLifeForm on Thursday, March 06 2008 @ 02:43 PM EST
Please note which article you are referencing in your subject line.

---

You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

Is this the same Alex Brown who is supporting MSOOXML to the UK? See:
Authored by: Anonymous on Thursday, March 06 2008 @ 02:50 PM EST
Is this the same Alex Brown who is supporting MSOOXML to the UK? See:

Alex Brown shows his bias to a UK government committee. - Authored by: Brian S. on Thursday, March 06 2008 @ 08:37 AM EST

[ Reply to This | # ]

Alex in Wonderland
Authored by: Anonymous on Thursday, March 06 2008 @ 03:29 PM EST
> So we can say that Alex claims they have used
> a consensus rule to discard the requirement of
> consensus for changing the DIS.

The Chairman stared at the ECMA cup in his left hand,
then at the ISO cup in his right hand. The Dormouse
scribbled on a piece of paper '29 for, 0 against, 2 abstain'
which correctly recorded the votes of the committee to use
the hastily contrived form, otherwise they would have been
there still well after Michaelmas, and their mothers would
be worried.

Meanwhile the Mad Hatter was disappearing through the
bushes at the bottom of the garden clutching a spreadsheet,
31 columns by 900 rows containing the true aggregate votes
of all members on all dispositions. The Mad Hatter knew that
this piece of paper must not fall into the right hands.

.

[ Reply to This | # ]

Inventing your own rules
Authored by: stegu on Thursday, March 06 2008 @ 03:29 PM EST

The practice of inventing voting rules during a meeting is dangerous and dubious. Allowing procedure to be changed at will by a meeting makes the assembly open to exploit.

Dictatorships have sprung from parliaments taken off guard and gradually being tricked into passing more and more extremist laws. All other comparisons aside, that is what happened in Hungary in the 1950's: A general left-inclined majority passed a law to ban the extremist right-wing party from attending. Then, the more strongly left-inclined parliament passed a vote to ban the second rightmost party, and so on until only the Communists were left.

Further examples of this kind of abuse may be found all over history and in modern time. I don't think ISO showed very good judgment in this particular case.

Having said that, this was only a vote to attach a set of rushed and restricted afterthoughts to a broken standard. More lipstick does not make the pig any prettier.

[ Reply to This | # ]

The Consensus and Resulting Vote
Authored by: Anonymous on Thursday, March 06 2008 @ 03:41 PM EST
What I got out of this is that the NBs at the BRM reached a consensus that the
original proposed-standard was generally in need of serious work, and that some
progress had been made toward fixing that original document, so they agreed that
the changed version was better than the original. That seems to be what the
vote was about. Microsoft and ECMA are spinning that to mean that the new
version is accepted as Good Enough, but that isn't what it means. That is what
the next vote is about.

Plainly, a document of this size should never have been considered for
"Fast-Track" anything. Not only is this document not consistent with
other ISO standard, it lacks consistency within itself, and the latter has only
been made worse by ECMA and BRM efforts to rectify the former. This is an
incomplete standard. It should be treated as such and rejected in the upcoming
vote, at least until it reaches a level of clarity by which it can be
implemented. Even Microsoft agrees that isn't likely any time soon, if ever.

[ Reply to This | # ]

Voting rules
Authored by: PolR on Thursday, March 06 2008 @ 03:55 PM EST
Checking the procedural rules of JTC1, there is a section 7 about meetings and section 7.7 about participation to meetings that includes this clause:
7.7.4 Each P-member has the right to be represented at the meeting by one or more delegates, but has only one vote. O-members and other TCs and organisations in liaison may nominate representatives who have the right to attend meetings and to participate in the discussion, but do not have the right to vote.
So we have a rule that state expressly that O-members don't have the right to vote at meetings. This should put a rest to all discussions on whether O-members were allowed to vote because the voting rules for meetings are different than general voting rules.

There is also a section 9 on voting. It starts with this clause:

9.1.1 All P-members have an obligation to vote (see 3.1). Decisions of JTC 1 and its SCs are made either by meeting or by correspondence, as appropriate. Each P-member has one vote which, for meeting votes, may also be cast by e-mail, facsimile or letter, or by proxy granted to another P-member. Proxy voting is valid only if the committee Secretariat has been informed in writing by the P-member granting the proxy in advance. A P-member may not cast a proxy vote on behalf of more than one other P-member. Votes by P-members in attendance may be cast only by the head of that delegation or an individual designated by the head of delegation.

NOTE: For a P-member not attending a meeting, written notification of a proxy must be provided to the committee Secretariat in advance of the meeting. For a P-member leaving a meeting, this written notification shall be provided by the Head of Delegation before the member leaves.

This clause explicitly reference meeting votes. I take this to mean section 9 applies equally to meeting votes and letter ballots. This should put a rest to arguments that meeting votes are not covered by section 9 because it is meant for letter ballots.

The difference between letter and in meeting votes is further explained in these two clauses:

9.1.4 In a meeting, except as otherwise specified in these directives, questions are decided by a majority of the votes cast at the meeting by P-members expressing either approval or disapproval.

9.1.5 For votes by correspondence (letter ballots) in JTC 1 and its SCs, except as specified elsewhere in these directives, questions are decided by a majority of the votes cast by P-members expressing either approval or disapproval. Letter ballots may be cast by web based balloting, e-mail, facsimile or, if absolutely necessary, by mail. Due account shall be taken of minority views.

This is keeping hitting on the same nail. There is no mention of O-members votes being counted in any way, and in meeting votes are explicitly mentioned.

There is also this clause:

9.1.7 JTC 1 and its SCs shall pay special attention to negative votes by P-members and shall attempt as far as possible to resolve the underlying differences and achieve the maximum level of approval.
This definitely has not been done. Some delegations has complained that the comment they were sent to discuss could even be put on the table. I think of Brazil and Greece IIRC.

I am referencing ISO/IEC JTC 1 Directives, 5th Edition, Version 3.0, dated 2007-04-05. It can be downloaded from this page. If you click on the proper link, you will get this document.

[ Reply to This | # ]

JTC1 9.5 combined voting procedures
Authored by: PolR on Thursday, March 06 2008 @ 04:11 PM EST
I just saw the update:
[Update 2008-03-06. This was the wrong clause. In-meeting Fast Track BRM voting is for resolving the comments of a constituency determined by the combined voting procedure (O-members + P-members) as per the JTC 1 Directives 9.5, and that is the understanding of the "normal JTC 1 procedures" in 13.8.]
So there is the combined voting clause 9.5:
9.5 Combined Voting Procedure The voting procedure which uses simultaneous voting (one vote per country) by the P- members fo JTC 1 and by all ISO member bodies and IEC national committees on a letter ballot is called the combined voting procedure. This procedure shall be used on FDISs, DISs, FDAMs, DAMs and FDISPs.
This is a voting procedure explicitly meant for letter ballots. Invoking this clause is rejecting the use of clauses that were written specifically for in-meeting votes and make them meaningless. See my other post above.

This interpretation of 9.5 as to be applicable to letter ballot only is consistent with the clause 9.6 right after:

9.6 FDIS/DIS/FDAM/DAM/FDISP Approval Criteria

For a FDIS/DIS/FDAM/DAM/FDISP to be approved, the count taken by ITTF shall meet the following criteria:

  • At least two-thirds of the P-members voting shall have approved;
  • Not more than one-quarter of the total number of votes cast are negative.
A P-member which has given appropriate notification that it will abstain from participation in specific work items (see 3.1.2) shall not be counted as a P-member when counting votes for drafts relating to such items.

Abstentions are excluded from the count.

[ Reply to This | # ]

What's behind the rules
Authored by: Anonymous on Thursday, March 06 2008 @ 04:12 PM EST

The purpose of the rules that Brown flouted is to ensure that the Fast Track procedure is not used when it isn't appropriate.

"Fast Track" is for standards where everybody agrees and there's really little or nothing to discuss. There's a consensus. There aren't thousands of points to discuss, there aren't even hundreds of points to discuss. There's just a handful of clarifications.

That's why, in the rules for Fast Track, it basically says that if it ever becomes apparent that there is significant disagreement, the Fast Track process must be stopped. That does not mean that the proposed Standard is being rejected. It just means it has to go through the normal process, that's all.

I'd like to ask Mr Alex Brown why it is so important to him that MSOOXML be rushed through a completely inappropriate process in violation of ISO rules?

[ Reply to This | # ]

ODF or PDF to HTML
Authored by: ausage on Thursday, March 06 2008 @ 04:56 PM EST
I will do anything PJ sends me.

[ Reply to This | # ]

So, what can be done?
Authored by: Peter Baker on Thursday, March 06 2008 @ 05:09 PM EST
I think there is an almost non-ISO level of consensus (cough :-) that Alex
Brown's interpretation of the rules (including but not limited to his assumed
authority to apparently invent /introduce ones on the spot) is subject to
question, even irrespective of motives.

My question is: so what?

Is there anything that can be done to revert this whole sorry mess and get back
to a functional ISO organisation, maybe even an improved one that no longer
needs to use a closed process to decide on open standards, one that is proud of
the quality of its deliberation?

Is there anything that can be done to lift MSOOXML out of ISO, not just because
of the damage it has caused but also because it is so blatantly obvious an ill
conceived, still hugely proprietary mess? It sickens me that resources are
wasted on something so obviously deficient it should have never even made it
into consideration, let alone fast track.

ISO has suffered the touch of Microsoft, which is a sort of reverse chrysopoeia
- it turns gold into lead. Not sure there's a cure for that, but the fact is
that the world needs ISO to work. It doesn't really need *Microsoft* to work,
though..

---
= P =

[ Reply to This | # ]

it doesn't matter.
Authored by: Alan Bell on Thursday, March 06 2008 @ 05:11 PM EST
I posted this on Alex's blog
well the job was a poisoned chalice from the start wasn't it! I expect lots of interesting announcements over the next few weeks as the Microsoft reps buzz about collecting air miles. There is obviously a bit of confusion about the status of the vote at the BRM with regards to P and O members. Personally I can't really see what difference it would make. The vote happened and a new text emerged, if only the P members voted then maybe a slightly different text would have emerged, the important point is that a text would emerge. If all the P and O members voted against all the undiscussed proposed dispositions then a new text based on the 50(or thereabouts) discussed ones would still have emerged. I have one question though, the rules are that if a new text is not agreed upon at the BRM then the fast track process is halted at that point and the submitters go home and take their substandard standard with them. How on earth would this end point of the BRM process flow chart ever be reached? As far as I can see as soon as one single disposition is accepted then there is a new text and the BRM can be described by the submitters as an "unqualified success" in that they are forcing the NBs to go through the time and effort of voting again. I think your description of the BRM as performing emergency surgery was quite apt, however it seems to me that there was never any risk of the patient dying under the knife.
he replied
@Alan
In-meeting Fast Track BRM voting is for resolving the comments of a constituency determined by the combined voting procedure (O-members + P-members) as per the JTC 1 Directives 9.5, and that governs the understanding of "normal JTC 1 procedures" in 13.8. This was explained to delegations last week.
You are right it would have been very unusual for the meeting not to have agreed any change to the text.
Please note "emergency surgery" wasn't my opinion - it was what I thought Andy Updegrove's might be!
so the fuss about which rules are being followed and should it have been P members or P+O members really doesn't matter. If only P members counted then a lot more of the issues on the paper ballots would have tied and been rejected. This would mean that Microsoft wouldn't get their 98% figure to bandy about but the resulting text wouldn't be much different (these were mostly fairly trivial non-controversial changes) but a text with some agreed modifications would have emerged from the BRM and the fast track process would not have stopped. As soon as one single disposition was accepted (like the missing close square brackets one for example) then the fast track process would not stop at the BRM. The bar is set incredibly low to allow the modified text to proceed to a vote. Everyone would have had to disapprove every single ECMA proposed disposition, and also not agree any other suggestion raised by a NB at the BRM (like the Greek suggestion regarding dates). Only if the text emerging from the BRM was identical to the text already voted on could the standard stop.
I am not neutral. I set up dis29500.org, I spoke at the OFE conference in Geneva. I set up and staffed the ODF showcase. I think picking apart the rules is interesting, but unnecessary. I also think that questioning the integrity of the convener(as some have started to do) is really unlikely to produce any juicy skeletons in the closet.

[ Reply to This | # ]

No resolution to create a revised text
Authored by: Anonymous on Thursday, March 06 2008 @ 05:14 PM EST
There are plenty of resolution to edit the text, but no resolution to revise and
publish it. The rules of the BRM and the agenda both required this. Otherwise
the text is still locked as previously voted upon. [Similar to a legislative
bill locked in committee, it stays there until reported out.] Since the
procedures don't allow a resumption of the BRM, and the fact appears to be that
no revised text of DIS 29500 was voted on to send out for vote, there is no new
issue and no need for a vote. In other words the BRM members should have to
vote that they want the text revised as discussed so it can be sent out for a
final vote. This was on the agenda.

As a point of order any member could bring it up and point out that the BRM did
not come to resolution on the issues as it didn't create a resolution to revise
the text and send it out. Thus, the fast track procedure was over and any
actions taken that appear to continue it are likely null and void.

[ Reply to This | # ]

The Edited Notes and the Resolutions from the BRM - Updated
Authored by: Alan Bell on Thursday, March 06 2008 @ 05:17 PM EST
again, from Alex Brown's blog . . .

Alan Bell
2008-03-06, 21:51
Alex,
when you described the notes of the meeting as 'edited' does that mean 'with
some typos fixed' or does it mean 'with some bits censored'. I am pretty
confident that the edits are on the typo end of the spectrum but it would be
good to have a confirmation that this is a full and true account of the meeting
and nothing of substance has been edited out. I am quite prepared to assume the
best, others are quite prepared to assume the worst.

Alan

Administrator (Alex Brown)
2008-03-06, 21:58
@Alan

I haven't done a side-by-side comparison but it just means "tidied
up"; the unedited drafts (for the end of each day) are available on the BRM
site and all NBs have access to them for comparison, so we'll hear fairly soon
I'm sure if there are juicy differences (hint: there aren't).

- Alex.

[ Reply to This | # ]

How about an AD in a major newspaper
Authored by: Anonymous on Thursday, March 06 2008 @ 06:34 PM EST
Something a bit like Mozilla´s community funded AD in the New York Times (If I remember correctly). It would need to be in a major European read newspaper. Possible text for AD ´ISO How about growing a backbone and not letting this travesity of ´standard´ pass.´

[ Reply to This | # ]

The Edited Notes and the Resolutions from the BRM - Updated
Authored by: tknarr on Thursday, March 06 2008 @ 07:22 PM EST

To be honest, I don't think the BRM voting procedures matter much in the overall picture. What matters is the vote on the proposed standard. In that, only P members get a vote. As the vote currently stands, not enough P members voted in favor for the standard to pass. The question now is whether the revised text from the BRM will convince a sufficient number to change their votes for the revised standard to pass. As I recall, the first vote fell far, far short of passing, so getting enough votes changed won't be a trivial task, especially given that all of Microsoft's new P members voted in favor and so can't do anything more and the long-term P members seem to be relatively annoyed at the antics and unlikely to do the perpetrator of the antics any favors.

[ Reply to This | # ]

Made up rules but...
Authored by: Anonymous on Thursday, March 06 2008 @ 08:21 PM EST
For me an important question is whether the NBs agreed to the rules of the
voting.

More explicitly, were NBs presented the option of letting O-members
participate?

According to the version of "option 4 prime" they agreed on the
"simple majority" rule. I am still in doubt about this but still my
main concern is that of O-members.

[ Reply to This | # ]

The Edited Notes and the Resolutions from the BRM - Updated
Authored by: Anonymous on Thursday, March 06 2008 @ 09:36 PM EST
Wfat I envision (cringe) is that, once M$ manages to cram this new
"standard" down everyone's throat, assuming that they do manage to so,
they will come up wit the (new??) argument that, with such a
"wonderful" (???), all-inclusive "standard", who needs that
old, tired, stupid ODF format standard, anyway?

Let's do everything in our power to prevent that from happening!

[ Reply to This | # ]

I don't get it
Authored by: Anonymous on Thursday, March 06 2008 @ 09:43 PM EST
Help me understand this:
A proposed standard is being processed. Rules say *all* issues must be resolved,
preferably by consensus.
This particular process, shoehorned into a standard working week, was too
complex to ever fit. As soon as the voting went to chunks, to 'get done in
time', the whole process negated it's stated purpose, and as such failed. The
result can only be that the standard can not be dealt with on these premises and
must be resubmitted to a more fitting process.
What else is there? Why all the fine-combing of rules, which just serves to
distract from the real issue:
IT COULDN'T BE RESOLVED, AND THEREFORE COULDN'T PASS.
End of story.

[ Reply to This | # ]

Rob Weir - notes on resolution are only a "slice" of moderate opinions
Authored by: stevenj on Friday, March 07 2008 @ 01:25 AM EST
In his blog, Rob Weir wrote (regarding the posted notes and resolutions):
James, those appear to be edited versions of the notes which were taken during the meeting. In particular, the "resolutions" document appears to be a list of the resolutions that were approved, stripping out the ones that either positively failed or died for lack of time to bring them to a vote.

There were a mix of NB views expressed. I'm not sure the meeting notes give a good flavor of that. For example, some NB's did not raise any points and just said "We are delighted with DIS 29500" when it was their turn. Since they did not propose any text changes, their view was not recorded in the resolutions. Similarly, those NB's who, in the view of the Convenor, had proposals that were not achievable within the time constraints of the BRM, these could not be brought up for discussion. So you won't see them in the meeting notes or resolutions. The net result is the resolutions are a slice of the more moderate opinions in the room. But the atmosphere was far more charged than these notes would suggest.

Which is not to say that there is anything wrong or dishonest about posting the resolutions. But they should not be understood as a substitute for minutes, if I understnad Rob correctly.

[ Reply to This | # ]

MS got the cart before the horse
Authored by: Anonymous on Friday, March 07 2008 @ 01:35 AM EST
If they had first gotten the Blue Screen Of Death approved as an ISO standard,
ISO would then have a standard way of resolving this mess that everyone would
recognize.

[ Reply to This | # ]

Sorting Rubbish
Authored by: Anonymous on Friday, March 07 2008 @ 02:41 AM EST
could describe the BRM itself, or my idle amusement with that Spreadsheet that "just turned up." Given the provenance and accuracy are not established, and the eventual result would be a 3 dimensional matrix of 32 NBs by 1027 proposals by 4 outcomes, and the result is compressed somewhat by the bulk voting of most NBs:
the "official" result is
15682 abstentions
9287 approved
4126 rejected
3769 not voted

To satisy the curiosity of those who may wish to persecute their NB for any perceived pecadillo I have sorted these, by eye, without the aid of any algorithm , firstly in descending order of Yes votes, towards ascending Abstain, then those with the courage to vote No, and finally the curious block who did not vote on many of the undiscussed items. Apologies for submitting this to the vagaries of geeklog

Country Yes No Abstain Didn't Vote
CI 1027 0 0
NO 1027 0 0
CL 1026 0 1
PL 1023 0 4
FI 1021 6 0
CZ 1020 3 4
GB 840 24 163
CH 678 2 347
BR 454 138 435

DK 156 0 871
DE 115 17 895
IT 32 2 933
PT 92 0 935
FR 62 0 965
KE 57 0 970
IL 44 2 981
BE 41 1 985
CN 0 26 1001
AU 19 5 1003
KR 6 9 1012
NZ 9 1 1017
EC 0 0 1027
IE 0 0 1027
NL 0 0 1027

ZA 152 875 0
US 61 966 0
IN 22 1005 0
MY 5 1022 0

CA 141 9 0 877
JP 93 10 0 924
GR 64 0 17 946
MX 0 3 2 1022

Some tried hard to do what they thought was best, some tried less hard, and some were obviously there only for the tea.

[ Reply to This | # ]

The Edited Notes and the Resolutions from the BRM - Updated
Authored by: ThrPilgrim on Friday, March 07 2008 @ 09:03 AM EST

At last I think I have found somthing more complicated than Mornington Crescent

[ Reply to This | # ]

The Edited Notes and the Resolutions from the BRM - Updated 2Xs
Authored by: Anonymous on Friday, March 07 2008 @ 01:07 PM EST
I've just had a little read of the ISO "Code of Ethics" I think that when read in the context of recent events it's a laugh a minute! Let me give you such gems as: "Ensuring fair and responsive application of the principles of due process, transparency, openness and impartiality" or "Monitoring ISO's integrity and protecting ISO's image" and "Applying ISO's authorised procedures properly and diligently". However don't take my word for it read it for yourself (PDF)

All the best

CPW

Hoist a petard anyone? (btw I saved a copy, just in case)

[ Reply to This | # ]

The Edited Notes and the Resolutions from the BRM - Updated 2Xs
Authored by: Stumbles on Friday, March 07 2008 @ 06:33 PM EST
Guess I can't call these guys corrupt. Never mind they seem to be changing rules
as they go along and as PJ noted seem to be enforcing only those rules that
favor Microsoft, changing rules midstream and generally at this point in to seem
be operating in a way that is HIGHLY questionable. I guess that doesn't mean
they are corrupt.

---
You can tuna piano but you can't tune a fish.

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )